AWS–Azure サイト間 VPN：まず戻りルートを書く
クラウド間のトンネルが接続しても、各ワークロードのサブネットが遠端のプレフィックスへ経路を持たなければ意味がない。計画を順に進め、その後でサービスを試す。
トンネルは上がる。IKE は一致する提案と到達可能なピアアドレスだけを必要とするからだ。そこで失敗するのは戻り経路である。AWS のワークロードはトンネルへパケットを送るが、Azure 側では 10.10.0.0/16 にどう応答するかを誰も知らない、あるいは Azure のルートがワークロードのサブネットで使われないテーブルにある。どちらのコンソールも触る前にルート計画を書き、トンネルは作業で最も退屈な部分にする。
ステップ 1：アドレス計画を凍結する
具体的な値で作業する。AWS のワークロードは 10.10.0.0/16 内の 10.10.1.20 にあり、10.20.0.0/16 内の 10.20.1.30 の Azure サービスへ TCP 443 を必要とする。両範囲は重なってはならず、受け入れ試験はトンネルではなくサービス対である。
他の何よりも先にこの四つの事実を書き留める。以降の手順はすべてそれに照らして確認される。
ステップ 2：両端を所有するゲートウェイを名指しする
AWS Site-to-Site VPN は仮想プライベートゲートウェイでもトランジットゲートウェイでも終端でき、両者は別のルーティング所有者だ。Azure はマネージドの VPN Gateway と、別に顧客が自ら運用する VM ベースのアプライアンスを提供する。どちらの組み合わせかを記録する。次のホップは組み合わせごとに違う。
マネージドゲートウェイの場合、推測したプライベートアプライアンスのアドレスを指すルートをコピーしない。アプライアンスの場合、クラウド側のルート伝播がゲスト OS を設定すると考えない。実際には設定しない。
ここを誤ると、完全に見える計画ができあがり、決して応答しないアドレスへパケットを送ることになる。
ステップ 3：各ワークロードが実際に使うルートを書く
以下の各境界は別々の検索であり、その一つにあるルートはパケットのルートではない。トンネルを稼働させる前に、自分の値で表を埋める。
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS では、BGP やトンネルが健全になった後でもワークロードのサブネットのルートテーブルは自分で更新する。ルーティングの概要もそれを接続の一部とみなす。Azure では、ユーザー定義ルートのテーブルは仮想ネットワークではなくサブネットに関連付けられるので、有効なルートは VNet のブレードではなくワークロードの NIC で確認する。
マネージドの Azure ゲートウェイはゲートウェイ伝播で遠端のプレフィックスを学習でき、UDR はその判断を上書きできる。UDR は理由があるときに追加し、反射的に足さない。追加する場合は、アプライアンスのアドレスをでっち上げず、ゲートウェイが VPN 経路のために公開する次ホップを指す。その後で NIC の有効なルートを読み直す。判断は実際にそこで行われるからだ。
ステップ 4：スコープを突き合わせる
BGP では、双方が広告する内容と相手が実際に学習した内容をプレフィックスごとに比べる。静的ルーティングでは、設定した遠端の範囲とステップ 3 で書いたワークロードのルートを比べる。
暗号について合意した IKE の関係は、どちらかが 10.10.0.0/16 や 10.20.0.0/16 を学習した証拠ではない。計画した /16 ではなく単一の /24 を広告したまま、二つのトンネルが上がっていることもある。プレフィックスはトンネルの状態ではなくルーティングテーブルで確認する。不一致は後になって、動くサブネットと決して応答しないサブネットとして現れる。
ステップ 5：実際の送信元からサービスを試す
想定したフローを AWS のセキュリティグループとネットワーク ACL、Azure の NSG、経路上のアプライアンスのフィルタで許可する。そのうえで 10.10.1.20 から承認済みのサービスアドレスとポートへ接続を一本開き、応答が同じ送信元に戻ることを確認する。
クラウドのセキュリティグループも NSG もステートフルなので、戻りパケットが拒否されるのはルーティングの症状であり、逆方向のルールを書き忘れたのではない。
どのゲートウェイからの ping も何も決めない。ゲートウェイのアドレスへの ICMP はコントロールプレーンの経路を試すだけで、ワークロードが必要とする転送された TCP サービスを試すものではない。
切り戻しと記録
ルートの所有者をトンネルの識別子の隣に記録し、変更前のルートテーブルを保存する。変更を外す必要があるときは、トンネルを解体する前にワークロードのルートを削除し、もう存在しない次ホップを指すサブネットを残さない。
そうすれば、後日のサブネット移設や spoke の接続には更新すべき場所が一つに定まり、決して所有していなかったルートの責任を負う稼働中のトンネルを残さずに済む。