前回に引き続き、AnsibleによるFortigateのポリシー設定のお話です。
だんだん「普段だとエラーチェックで弾かれる設定をAPIで叩いたのち、再起動してどうなるかを試す」のが楽しくなってきています。
Ansible関連の実践記事一覧はこちら。
現在のポリシー設定情報の取得
色々とポリシー系のモジュールを眺めてみましたが、基本的にfortios用の現在のモジュールには、「設定変更」用のモジュールしか存在せず、「設定取得」用のモジュールはなさそうです…
唯一の設定取得用のfortios_configモジュールはpyFGなので今のところ動かせてません…
FortigateのAPIそのものはGETメソッドには対応しており、例えばログインした状態で以下のようにURLにアクセスすることで、指定されたエンドポイントの情報をJSON形式で取得することが可能なようです。
■ポリシー全体の情報を取得
htttp[s]://<fortigate_ip_address>/api/v2/cmdb/firewall/policy
■単一のポリシー情報を取得
htttp[s]://<fortigate_ip_address>/api/v2/cmdb/firewall/policy/1
■出力例
{
"http_method":"GET",
"revision":"39.0.0.661485498.1572955273",
"results":[
{
"q_origin_key":1,
"policyid":1,
"name":"",
"uuid":"ee645184-fec9-51e9-d467-0b6fb1a24d6d",
"srcintf":[
{
"q_origin_key":"internal",
"name":"internal"
}
],
"dstintf":[
{
"q_origin_key":"wan1",
"name":"wan1"
}
],
"srcaddr":[
{
"q_origin_key":"all",
"name":"all"
}
],
"dstaddr":[
{
"q_origin_key":"all",
"name":"all"
}
],
(略)
"action":"accept",
"send-deny-packet":"disable",
"firewall-session-dirty":"check-all",
"status":"enable",
"schedule":"always",
"schedule-timeout":"disable",
"service":[
{
"q_origin_key":"HTTP",
"name":"HTTP"
},
{
"q_origin_key":"HTTPS",
"name":"HTTPS"
},
{
"q_origin_key":"DNS",
"name":"DNS"
}
],
(略)
ポリシーの並び順
Policy IDには関係なく、上から順に登録されるようです。
ポリシーの順序の入れ替え
モジュールは見当たりませんでした。 CLIだとこれだけなんですけどね…
ポリシー要素の複数オブジェクトの指定
モジュールのリファレンスにも「list形式」とあったので、以下のように宣言したところ、問題なく複数サービス指定のポリシーになりました。(前回と共通する部分は省略)
service:
- name: "HTTP"
- name: "HTTPS"
- name: "DNS"
ポリシーのEnable/Disableの切り替え
ポリシーの削除と同じように、指定したPolicy IDだけを宣言し、status: "disable"にすることで実施可能でした。
tasks:
- name: Configure Firewall Policy (Disable)
fortios_firewall_policy:
host: "{{ host }}"
username: "{{ username }}"
password: "{{ password }}"
vdom: "{{ vdom }}"
ssl_verify: "{{ ssl_verify }}"
state: "present"
firewall_policy:
policyid: "1"
status: "disable" #有効化するときはstatus: "enable"
↓実行結果
初期定義以外のオブジェクトが使えるか
当たり前ですが、宣言されてさえいれば利用が可能でした。↑の画像の「HOGE_TCP999」はカスタムサービスオブジェクトです。
「名無しポリシー許可」無効状態での名前無しポリシーの設定
Fortigateのポリシーには、いつからか初期設定で名前の設定が必須になりました。これを無効化(=名無しポリシーを許可)できるスイッチが「Allow Unnamed Policies」の有効化です。
名無しポリシー禁止の状態で、Ansible のPlaybook(前回のものと同じ)を実行してみましたが、特にエラーもなく正常終了しました。
また、その状態で再起動も試してみましたが、特に設定が消えるようなことはありませんでした。
やはり、CLI/WebUIでエラーチェックがかかる設定も、REST APIだと設定可能なようです。要注意ですね…
感想
モジュールリストを眺めていて薄々感じてはいましたが、最初のほうにも書いたようにfortios用のモジュールは「設定変更」用のものしかなく、一部の例外(fortios_facts)を除いては「情報取得」用のものはなさそうです。
これまで、もくもく会で実施してきたコンテンツや環境は、どれだけ恵まれた状態だったのかを痛感しました…
また、一部分だけをSSH用のコマンドを実行する形でPlaybook化して実装する、などしたときにも、fortiosapiが利用するlocalコネクションプラグインではつらそうだなあと感じました。
いきなりモジュールを試すのもいいですが、地力をつけるためにも色々と基礎から勉強をせねばな、と改めて感じました。
https://tenko.hatenablog.jp/entry/2019/11/06/211923
バックアップ日時: 2026年11月11日