インフラエンジニアにとって、拠点を跨ぐVPN構築は避けて通れない道です。しかし、NATが絡んだり対向機器との相性があったりと、一筋縄ではいかないことも多いもの。
今回は、私が実務で行った「AIを副操縦士にしたIPsec VPN構築」の全プロセスを公開します。
※パブリックな生成AIにIPアドレス等情報を入力するのは機密情報流出のリスクがあります。
環境があれば社内のクローズな生成AIを活用したり、社内のポリシー、倫理に従った利用をしましょう。
1. 思考の整理：まずは「ふわっと」した相談から
今回久しぶりにIPsecを設定するため、何を準備したら良いんだっけからスタートしました。
パラメーターが完全に決まっていない段階で、私はAIに以下のプロンプトを投げました。
プロンプト： 自拠点FortiGateからインターネットを経由してグローバルIPアドレス同士でIPsec接続をしたい。 手元のクライアント端末からはDNSで名前解決し解決されたIPアドレスを利用してIPsec先のサーバーへアクセスしたい。 解決されたIPアドレスは宛先のIPアドレスへNATする想定だが、必要となる設定、検討すべき点をステップバイステップで確認して。
これにより、「ネットワーク構成の可視化」「NATの役割」「対向との合意事項」など、設計時に漏らしがちなチェックリストを瞬時に手に入れることができました。
出力内容
1. 事前確認（設計フェーズ）
- ネットワーク構成図を用意する（自拠点のパブリックIP / LAN ネットワーク / 対向拠点のパブリックIP / 対向の内部サーバ IP / 名前解決結果の IP）。
- 対向側（ピア）も FortiGate か他社機器か、IPsec の設定（Phase1/2 のプロポーザル、PSK または証明書）を確認。
- DNS 名が解決する IP が「対向のグローバルIP（＝公開用IP）」で、その IP を FortiGate で DNAT（宛先 NAT）して対向内部IP にする必要があるのかを確定。
- サブネットの重複がないか確認（両側で同一サブネットだとルーティング／NATが複雑に）。
- NAT-T（UDP 4500）, ESP（IPプロトコル50）, IKE（UDP 500） の通信が通ることを確認（ISP による制限がないか）。
2. 推奨アーキテクチャ（高レベル）
- route-based IPsec (tunnel interface) を使う：トンネルに対する静的ルートを設定してトラフィックをトンネルへ誘導。
- 内部クライアントが名前解決で得る「グローバルIP」を、FortiGate が DNAT（VIP）で対向の内部IP（暗号化対象）に変換する。変換後の宛先IP がトンネルのルートに一致するようにする。
- DNAT（VIP）は内部→トンネルへ流す「ヘアピン／内部向けDNAT」相当の処理になるため、適切なファイアウォールポリシーを用意する。
3. 実装手順（具体的）
IPsec（route-based） の設定
Phase1 (IKE) を設定
Remote Gateway: 対向のグローバルIP（またはFQDN）
Authentication: Pre-shared-key（または証明書）
IKE version/proposals: 対向と一致させる（例: IKEv2 / aes256-sha1 / dh-group14）
NAT Traversal: 有効（ピアのいずれかが NAT 経路を通る可能性があれば）
Phase2 を設定
Encryption/Auth: 対向と一致
Mode: tunnel
Local/Remote selectors: route-based を使うなら広め（0.0.0.0/0 等）か、対向と合意した範囲
「use tunnel interface」を選択して tunnel interface を作る（例: vpn_tun1）
パラメータ決定
これらの出力から必要なパラメータ、接続先との合意事項を整理しました。
（※IPアドレスや設定値は実際のものとは違います。）
Local Gateway:：XXX.XXX.XXX.XXX
Remote Gateway:：YYY.YYY.YYY.YYY
Authentication:：Pre-shared-key ******
IKE version/proposals:： IKEv2 / aes256-sha256 / dh-group14
NAT Traversal:：有効
Local 仮想ネットワーク：172.16.0.0/24
Remote 仮想ネットワーク：10.0.0.0/24
クライアント端末セグメント：192.168.0.0/24
接続先サーバー仮想IPアドレス：192.168.100.100
接続先サーバー実IPアドレス：10.0.0.10
2. 実装フェーズ：AIが書き出したFortiOS用コンフィグ
設計の合意が取れた後、AIにパラメータを与え、具体的な実装手順を出力させました。
GUIとCUIバージョンで出力させましたが、GUIでは設定できない項目があるようだったので最終的にCUIでまとめました。
主要な設定項目
①アドレスオブジェクトの作成
ポリシー作成などに必要になるアドレスオブジェクトを作成します。
今回はLAN_NETがクライアント端末セグメント、”REMOTE_NET”はアクセス先のサーバーセグメントとして一応作成しました。
config firewall address
edit "LAN_NET"
set subnet 192.168.0.0 255.255.255.0
next
edit "REMOTE_NET"
set subnet 10.0.0.0 255.255.255.0
next
end②SNATの設定
クライアントがトンネルインターフェースへ出ていく時のIPアドレスを設定します。
config firewall ippool
edit "POOL_A"
set type overload
set startip 172.16.0.2
set endip 172.16.0.2
next
end② VIP（Destination NAT）設定
クライアントが参照するサーバーの仮想IPを対向の実IPへ変換する設定です。
config firewall vip
edit "VIP_A"
set extip 192.168.100.100
set mappedip 10.0.0.10
set extintf "internal"
next
end③ Phase1/Phase2の設定
Route-based VPNを採用し、セレクタを設定します。
phase1-interfaceの設定
config vpn ipsec phase1-interface
edit "P1-TO-PEER"
set interface "wan1"
set ike-version 2
set remote-gw YYY.YYY.YYY.YYY
set psksecret "******"
set nattraversal enable
set proposal aes256-sha256
set dhgrp 14
next
endphase2-interfaceの設定
config vpn ipsec phase2-interface
edit "P2-TO-PEER"
set phase1name "P1-TO-PEER"
set proposal aes256-sha256
set pfs disable
set encapsulation tunnel
set src-subnet 192.168.0.0 255.255.255.0
set dst-subnet 10.0.0.0 255.255.255.0
set tunnel-interface "vpn_tun1"
set comments "Route-based Phase2"
next
end④トンネルインターフェース作成（IF に IPアドレス を割当て）
config system interface
edit "vpn_tun1"
set vdom "root"
set ip 172.16.0.1 255.255.255.255
set type tunnel
set allowaccess ping
set comments "Tunnel IF for IPsec to PEER"
next
end⑤静的ルート（対向ネットワークを vpn_tun1 に向ける)
config router static
edit 0
set dst 10.0.0.0 255.255.255.0
set device "vpn_tun1"
next
end⑥Firewall ポリシー：internal → vpn_tun1（DNAT + SNAT）
ポリシーは VIP を宛先に指定し、IPPoolによる SNAT を有効にする
config firewall policy
edit 200
set name "LAN_to_REMOTE_via_VPN"
set srcintf "internal"
set dstintf "vpn_tun1"
set srcaddr "LAN_NET"
set dstaddr "VIP_A"
set action accept
set schedule "always"
set service "ALL" # 実際は必要最小限に絞るのが良い
set nat enable
set ippool enable
set poolname "POOL_A"
set comments "LAN to REMOTE via VPN"
next
end⑦検証用コマンドのリストアップ
設定して終わりではなく、AIに「どのコマンドで確認すべきか」まで出力させました。
#Phase1/Phase2 設定確認
show vpn ipsec phase1-interface
show vpn ipsec phase2-interface
#トンネルインターフェース確認
show system interface vpn_tun1
#ルート確認
get router info routing-table all
#トンネル状態
diagnose vpn tunnel list
diagnose vpn ike gateway list
#セッション確認（SNAT後のIPを検索）
diagnose sys session list | grep 172.16.0.2
#パケットキャプチャ 例（クライアント→仮想IP を送った際）
diagnose sniffer packet internal 'host 192.168.100.100 ' 4
#トンネル側で実際に送られる inner headers を確認
diagnose sniffer packet any 'host 172.16.0.2 or host 10.0.0.10 ' 43. 振り返り：AIを実務で使う「最大のメリット」
今回の経験を通じて感じた、インフラSEがAIを活用するメリットは3点です。
- 「知らない単語」をその場で潰せる
わからない用語やパラメータを、瞬時に文脈に合わせて解説してくれる。 - 対向担当者への「依頼事項」を整理できる
「何を伝えたら相手が設定しやすいか」をリスト化してくれるため、コミュニケーションコストが劇的に下がった。 - 論理的な切り分けの「壁打ち」
トラブル時、パニックになりがちな頭を「可能性の高い順」に整理してくれる安心感は計り知れません。
まとめ
今回、久しぶりにIPsecVPNの設定を行いましたが、もう忘れてしまっている概念やパラメータ、用語を生成AIは補完、説明しながら設定完了まで導いてくれました。
ただ、やはり出力のまま設定してもうまくいかないこともあり、理解していないと設定の不備による脆弱性や後にトラブルを生みかねません。
「設定」「手順」の作成はAIでもできますが、「なぜその設定が必要か」を判断し、予期せぬ挙動を現場で解決するのはエンジニアの仕事です。
AIを「優秀な後輩」あるいは「副操縦士」として迎えることで、40代からのエンジニアライフはもっとクリエイティブで、楽しいものになると確信したプロジェクトでした。
編集後記
ふと気づくと観葉植物は新芽を出し始め、メダカも水面に上がってきて活発に動くような季節になりました。
毎日パソコンとにらめっこは疲れるので、趣味やプライベートを引き続き充実させつつ、仕事は効率的にこなしていきたいですね。
次回は、IPsec設定時のデバッグ、トライブル解決について書いてみたいと思います。
コメント