一つのWANインターフェースで拠点間VPNとリモートVPNを兼ねられるか

一つのパブリックアドレスは、拠点トンネルとモバイル利用者のプールを同時に扱えます。しかし、一つの共通の受け入れ規則を扱うことはできません。拠点のピアとモバイル利用者の違いは、何者を証明するか、その証明をどう検査するか、どのアドレスを受け取り、どのプレフィックスが応答してよいかです。外部アドレスを身元ではなく転送の詳細として扱えば、設計はずっと単純になります。

簡単な健全性テスト：ルーターに触れる前に、両方の受け入れ記録を書いてみてください。一つの照合条件で両方を覆わなければならないなら、ポリシーはすでに曖昧で、最初の症状はルーティングやファイアウォールの障害に見えますが、実際には身元の障害です。

設定前の二つの記録

拠点の記録は短く安定しています。ピアのアドレスまたは証明書名、事前共有鍵または証明書のトラストポイント、両側の保護サブネット、トンネルインターフェース、そして拠点向けのトラフィックをそのトンネルへ送る静的経路が並びます。各項目は一つの既知のピアと固定のプレフィックス集合に関するものです。

モバイルの記録はより広く、より個人的です。クライアントのプロトコルとポート、利用者や端末の認証方法、接続時に配布されるアドレスプール、そのプールが到達できるリソース、分割トンネルのプレフィックス、クライアントへ送られるDNSサーバー、そして第二要素が並びます。各項目は、一つのゲートウェイではなく、不明な人数の利用者についての問いに答えます。

この粒度の差こそが、二つの役割が分かれる理由そのものです。拠点プロファイルは、鍵が一つのサイトの一つの機器に属するため、一つの鍵を安全に信頼できます。全員に一つのグループ鍵を信頼させるモバイルプロファイルは利用者ごとの説明責任を崩し、それは通常、展開時ではなくインシデントの事後レビューで見つかります。

ピア照合と認証が分かれるところ

IOS XEでは、IKEv2プロファイルが交渉できないパラメーターと、ピアを選ぶための条件を保持します。つまり、拠点側とモバイル側は、同じインターフェースで終端していても、同じ暗号PKIを共有していても、それぞれ独自のプロファイルを必要とします。Ciscoはプロファイル・認証・照合の役割を次のIOS XE 17向けIKEv2設定ガイド。

拠点プロファイルは通常、遠隔アドレス、FQDN、証明書のサブジェクトといった狭い身元に一致します。match identity remote address 198.51.100.10 255.255.255.255のような行は一つのピアを固定し、サイトごとに保存した鍵を持つauthentication remote pre-shareで足ります。選択順で上位にある重複したワイルドカードが拠点のトラフィックを誤ったプロファイルへ引き込むことがあるため、ピア台帳が許す限り照合を具体的に保ってください。

モバイルプロファイルはアドレスを固定できないため、グループ、key-id、証明書のフィールドに一致し、実際の利用者チェックはAAAまたはプロファイルに付いた認可ポリシーへ渡します。この分離が重要なのは、ピア認証がクライアントにトンネル構築が許されるかを答え、利用者ごとの認可がどのプールとどのリソースを得るかを答えるからです。拠点の鍵を共通ログインとして使うと、二つ目の答えを捨ててしまいます。

転送と変換にも同じ分離が要ります

受け入れと到達性は別の問題です。IKEとIPsecの交換が成功しても、両者が鍵で合意したことが示されるだけで、クライアントが得たプールへの経路はできません。したがってリモートアクセスのプールには戻り経路が必要で、トンネルインターフェースを指す静的経路か、プールの集約を注入するルーティングプロトコルが要ります。拠点のプレフィックスは通常、サイトの残りを担うのと同じルーティングプロセスで届きます。

変換は、二つの役割が最もよく衝突する場所です。プライベートアドレスを保つ必要がある拠点間トラフィックには、その二つのプレフィックスに限定したNAT除外が両方向で必要です。モバイルクライアントも通常、トンネル内トラフィックの除外が必要ですが、インターネット向けのトラフィックは、分割トンネルでトンネルを迂回するか、NATの後にハブで出ます。トンネルから来るものすべてを除外するのが典型的な誤りで、本当に必要なトラフィックからも変換を奪ってしまいます。

除外規則は受け入れ規則と同じくらい狭く保ってください。プールの集約と拠点のプレフィックスが重なると、パケットが一つも破棄される前に戻り経路が曖昧になり、症状はきれいなトンネル障害ではなく、あるサイトが時々サブネットを失う形で現れます。

交差したポリシーを露呈する受け入れケース

四つのケースを作り、順に実行します。拠点のホストが拠点専用のリソースに到達します。モバイルクライアントが自分のプールのアドレスで同じリソースに到達します。モバイルクライアントが触れてはいけない拠点のプレフィックスを試します。拠点のピアがリモートアクセスのプールからアドレスを得ようとします。最後の二つは、通常の監視では静かに失敗するため、共有プロファイルを捕まえます。

次に、設定ではなくデータプレーンを確認します。show crypto ikev2 saとshow crypto ipsec saは、どのプロファイルとセレクターが各フローを運んだかを示し、show ip nat translationsとトンネルのカウンターは、戻り経路と除外が実際に一致したかを示します。トンネルインターフェースでの tracer やパケットキャプチャがループを閉じます。

観測した身元、プールのアドレス、選ばれたポリシーを各結果の横に書きます。すべてのケースが正確に一つの記録に対応し、どのケースも一時的な例外なしで通るとき、実行は完了です。