プロバイダー変更でサイトVPNのアドレスを振り直さない方法

支店がインターネットプロバイダーを変更しても、ファイルサーバーはアドレスを保ちます。これはルーテッド型サイトVPNでは当たり前の結果であり、トンネルの端点アドレスがアプリケーションのアドレスだと思い込んでいる人には意外に映ります。両者は設計の異なる層にあり、動いたのは片方だけです。二つを一つとして扱うと、プロバイダー移行がアドレスの振り直し計画になってしまいます。

独立して動く二つのアドレス計画

内側の計画は、アプリケーションが使うプライベートアドレスを記述します。10.55.8.20 の支店サーバー、そこへ経路を向ける本社のプレフィックス、そして戻りの経路です。外側の計画は、二つのゲートウェイが互いに到達する方法を記述します。ピアアドレス、待ち受けポート、インターネットを越える経路です。

プロバイダーの変更が触れるのは外側の計画です。それ自体は内側の計画の変更を要求しません。

二つの台帳を分けておくことが、アプリケーションがすでに自前で通信を暗号化していてもオーバーレイを動かす実務的な理由です。オーバーレイは外側の変動に耐える安定した内側のトポロジーを与えます。アプリケーションはアドレス、ファイアウォール規則、DNS レコードを保ちます。変わるのは転送の項目だけであり、はるかに小さなレビューで済みます。

外側のトンネルが内側の会話を運ぶ

ゲートウェイ間トンネルでは、外側の IP ヘッダーが二つのゲートウェイを宛先にします。内側のヘッダーは今も実際のアプリケーション端点を示します。RFC 7296 のゲートウェイ間の記述はこれを、トンネル端点を通じて通信を届ける通常のルーティングとして扱っています。

だからこそ、ゲートウェイの公開アドレスが変わっても支店サーバーは 10.55.8.20 を保てます。内側のパケットにはプロバイダーのアドレスがまったく含まれません。

この分離は設計上の性質であり、自動的な保証ではありません。代替回線が対応するトンネルを確立できない場合、あるいは内側の経路が再設定されない場合、アドレスが変わらなくてもアプリケーションは経路を失います。

プロバイダーの移行には今もチェックリストがある

外側のチェックリストは五項目です。ピアアドレスまたは維持している名前、待ち受け側と上流のフィルタリング、経路上の変換、期待するピアの ID、もう一方のゲートウェイで許可される設定です。どれも単独で失敗し得ます。管理を運ぶ回線を変える間は、別の復旧経路を用意してください。回線切り替えの最中に遠隔アクセスを断つのは、自分で起こす障害です。

そのあと、支店のプレフィックス、両方向の経路、保護ポリシー、そして実際のアプリケーションの流れを一つ確認します。認証されたばかりのトンネルは、古いプライベートサブネットを指す経路を直しません。

別の接続済みサイトとのアドレス重複は、独立した計画上の問題です。プロバイダーの変更がそれを生むわけではありませんが、移行はたいていそれが表面化する時です。

残らないもの — 公開元とセッション

安定したプライベートなサーバーアドレスは、安定した公開元ではありません。閲覧が新しいプロバイダーから直接出ていくなら、ウェブサイトには新しいプロバイダー側のアドレスが見えます。

そのアドレスを安定させるには、独自の可用性とポリシーを持つ意図的な出口設計が必要です。トンネルに無料で付いてくるものではありません。

確立済みのセッションも経路の変更を生き延びません。トンネルは数秒で張り直せても、古い経路に固定された長時間の接続は切れます。切り替えは再接続が許容できる時間帯に計画してください。特定のクライアントとそのタイムアウトを試していない限り、移行が目に見えないと主張してはいけません。

四つの確認で移行を検証する

変更後は四つを順に確認します。トンネルが意図したピアと確立していること、支店のプレフィックスへの内側の経路があること、ポリシーがアプリケーションの流れを許すこと、アプリケーションが応答することです。それぞれに専用のコマンドがあります。

Linux ゲートウェイでは、この三つがその一覧の中ほどを覆います。

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

転送アドレスは一つの台帳に、アプリケーションのアドレスは別の台帳に入れてください。実際に動いた項目だけを更新します。トンネルの外側アドレスが変わったからといって内部の依存関係を振り直すのは、避けられる作業です。