VPNサイト拡張：ゲートウェイの先の戻り経路をたどる

支店からの通信は、到達を求められたアプリケーションをLANに含まないゲートウェイで終わる。サーバーは二つ目のデータセンターにあり、VPNが一度も設定しなかった内部リンクの向こう側にある。近い側のゲートウェイにもう一つプレフィックスを足しても、遠い側のゲートウェイが最後のルーターではなく暗号化の端点である以上、その場合は何も変わらない。経路には先方へのルート、遠い側のセキュリティ境界での受け入れ、そして宛先自身のネットワーク内での戻りの判断が必要である。

遠い側のゲートウェイは暗号化の端点である

ゲートウェイ間のIPsecは二つのセキュリティ装置の間の通信を保護し、内部アドレスはその区間を暗号化されて通過する。遠い側のゲートウェイの先では通常のルーティングが引き継ぎ、データセンター間に存在するポリシーも含まれる。したがって保護される区間は旅の一部であり、残りではない。そうでないと想定することが、健全なトンネルと到達不能なアプリケーションで設計が終わる理由である。

経路を三つの部分、つまり支店から近い側のゲートウェイへ、近い側から遠い側へ、遠い側からアプリケーションへと描く。各部分にはそれぞれの所有者と故障の仕方がある。

トンネルポリシーの両方向を読む

トンネルポリシーは通常、ローカル側の視点で書かれ、部分的な設定はその習慣から生まれる。両方のピアが、トンネル内で現れるとおりに支店の送信元と宛先を列挙しなければならず、設計が意図する変換も含める。近い側の端だけを更新すると、ルーティング障害に見える第二段階の不一致が生じる。どのルートに触れる前にも、二つのポリシー集合を比較する。

送信元と宛先はサイト名ではなくアドレスとして書く。ここでの曖昧さは後で不可解な非対称性として再び現れる。

先方へのルートを追加し、受け入れを確認する

遠い側のゲートウェイにはアプリケーションのサブネットへのルートが必要で、その間のすべてのルーターが支店の送信元を受け入れる必要がある。図が主張する内容ではなく、遠い側のゲートウェイが実際に何を持っているかを検証する。

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

通常のルーティングテーブルでは答えられない問いに対し、最初のコマンドは遠い側のゲートウェイがその送信元に対して選ぶ出口インターフェースと次のホップを報告する。トレースはパケットがどこで止まるかを示し、遠い側のゲートウェイの後での途切れはトンネルではなく内部トランジットを指す。予期しないアドレスはどこか計画外で変換が起きていることを意味するため、ルートが存在しても通信が消える場合は遠い側のゲートウェイでキャプチャし、到着する送信元アドレスを読む。ここでのアドレスはすべてプレースホルダーなので、実際の支店、トランジット、アプリケーションのサブネットに置き換える。

支店から試し、次に古い経路を再試験する

受け入れには遠い側のゲートウェイからの検査ではなく、実際の送信元が必要である。支店のホストから確認を実行し、以前から機能していた宛先も同じ試験に残す。

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

アプリケーションからの応答は先方への経路と戻り経路を同時に証明し、古い宛先へのpingは変更が既に機能していたものを壊していないことを証明する。アプリケーションが記録する送信元アドレスを取得するのは、そのアクセス規則と戻りルートがその値に一致しなければならないからである。支店がトンネルの前に変換する場合、ポリシーのアドレスとアプリケーションが見るアドレスは設計上異なるので、両方を記録する。鍵の更新やルーティング変更の後に試験を繰り返すのは、こうした経路が一度検証されると忘れられがちだからである。

三つの区間のそれぞれと、宛先ネットワーク内の戻りルートに所有者を割り当てる。所有者が四人いる経路は、その間の隙間で失敗する。