境界線は消えた、だが「トンネル」は生きている：SD-WANとSASEを繋ぐIKEv2の深淵
「境界防御は死んだ」。そう叫ばれて久しいですが、現場のエンジニアとして言わせてもらえば、境界が消えたのではなく「境界がクラウドに抽象化された」というのが正しい認識でしょう。
SASE（Secure Access Service Edge）の時代、我々が管理すべきは物理的なファイアウォールから、クラウド上のPoP（Point of Presence）へとシフトしました。SD-WANルーターからSASE PoPへ張られるIPsecトンネル。一見、自動設定で済むブラックボックスに見えますが、ひとたび通信が不安定になれば、それは「魔法」ではなく、冷徹な UDP 500/4500 のパケットのやり取りに過ぎません。
今回は、この制御プレーンの心臓部である IKEv2 に焦点を当て、実務でハマりやすい罠とデバッグの極意を紐解いていきます。
—
1. IKEv2のセッション確立：パケットの「挨拶」を知る
IPsecのトンネルが確立されるとき、何が起きているのか。SASE PoPとの通信において、IKEv2（RFC 7296）は以下のステップでネゴシエーションを行います。
1. IKE_SA_INIT: 暗号化アルゴリズムの合意。ここで鍵交換を行い、以降の通信を暗号化するための「秘密の道」を作ります。
2. IKE_AUTH: 認証。デジタル証明書や事前共有鍵（PSK）を用いて、「お前は本当に許可された拠点ルーターか？」を確認します。
実務で最も多いトラブルが、このフェーズでの「提案拒否（NO_PROPOSAL_CHOSEN）」です。SASEベンダー側の推奨設定と、手元のルーターの設定（AES-GCMやDiffie-Hellmanグループ）が微妙にズレているだけで、トンネルは一生繋がりません。
現場のTips：UDP 4500への切り替え（NAT-T）
SASE環境では、拠点ルーターがNAT配下にいることが一般的です。その場合、IKE_SA_INIT の直後に NAT-T（NAT Traversal）が発動し、通信は UDP 500 から UDP 4500 へと切り替わります。もしファイアウォールで UDP 500 しか許可していないと、認証フェーズで突然通信が途絶え、「なぜか繋がらない」という泥沼にハマります。
—
2. 監視の生命線：Keepalive（DPD）の設計思想
トンネルが確立しても、クラウド側はいつルーターが死んだのか分かりません。ここで登場するのが DPD（Dead Peer Detection）です。
SASEポータル側は、設定された間隔で R-U-THERE メッセージを投げます。これに対する R-U-THERE-ACK が返ってこなければ、SASEは即座にセッションを破棄します。
実務における設定の勘所:
- 短すぎると: インターネットの瞬断でトンネルが再構築ループに陥り、CPU負荷が跳ね上がります。
- 長すぎると: 障害発生時に「通信不能」と判断されるまで数分かかり、ユーザーからの「ネットが遅い！」というクレームが止まりません。
一般的には、Hello 間隔を 10 秒、Retry を 3 回程度に設定するのが、安定稼働と検知速度のバランスが良い「落とし所」です。
—
3. 実践：SD-WANルーターの設定例（Cisco IOS-XE風）
現場でよくある構成を例に、設定ファイルを覗いてみましょう。
! IKEv2 ポリシーの定義
crypto ikev2 proposal SASE_PROP
encryption aes-gcm-256
prf sha256
group 19 ! ECP256 推奨
!
! SASE PoP への接続設定
crypto ikev2 profile SASE_PROFILE
match identity remote fqdn pop-tokyo.sase-provider.com
authentication remote pre-share key 0 秘密の鍵
authentication local pre-share key 0 秘密の鍵
dpd 10 3 periodic ! 10秒毎に確認、3回失敗でダウン判定
!
! トンネルインターフェース
interface Tunnel100
ip address 10.255.0.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 203.0.113.10 ! SASE PoPのIP
tunnel protection ipsec profile SASE_IPSEC_PROFILE—
4. デバッグの武器：Pythonで監視スクリプトを書く
トラブルシューティングの際、パケットキャプチャ（Wireshark）を回すのも一手ですが、運用者としては「今、本当にトンネルが生きていて、遅延がないか」をAPI経由で監視したいものです。
SASEポータルが提供するAPIを活用し、トンネル状態を確認するシンプルなスクリプトの断片を紹介します。
import requests
# SASEポータルのAPIエンドポイント
API_URL = "https://api.sase-provider.com/v1/tunnels/status"
HEADERS = {"Authorization": "Bearer YOUR_API_TOKEN"}
def check_tunnel_health():
try:
response = requests.get(API_URL, headers=HEADERS, timeout=5)
response.raise_for_status()
data = response.json()
# 拠点ごとのトンネル状態をチェック
for tunnel in data['tunnels']:
if tunnel['status'] != 'up':
print(f"警告: {tunnel['name']} がダウンしています！")
else:
print(f"正常: {tunnel['name']} (Latency: {tunnel['latency']}ms)")
except Exception as e:
print(f"監視スクリプト実行失敗: {e}")
if __name__ == "__main__":
check_tunnel_health()—
最後に：ネットワークエンジニアの誇り
IKEv2 のネゴシエーションが成功した瞬間のログ。SA_INIT が完了し、AUTH が通り、Tunnel インターフェースが up になる。この一連の流れを、コマンドライン越しに眺めるのが、我々ネットワークエンジニアの密かな喜びです。
SASEやゼロトラストという華やかなワードの裏側には、何十年も変わらない、しかし極めて堅牢なプロトコルの戦いがあります。ツールやクラウドに依存するだけでなく、パケットがどこで、なぜ止まっているのかを追える「勘」と「技術」を、これからも磨き続けていきましょう。
皆さんのネットワークが、今日も安定してパケットを運び続けますように。
コメント