ExpressRoute と VPN：どの障害ドメインをカバーしているのか
二本目の IPsec トンネルがカバーするのはエンドポイントであり、その下の回線ではない。各障害ドメインを整理し、暗号化なしのフォールバックを許容するかを決める。
ExpressRoute のプライベート ピアリング上を走る IPsec トンネルは、すでに存在するトランスポートに暗号化を追加する。二本目のトンネルはエンドポイントの可用性を高めるが、その両方の下にある通信事業者の経路には何の効果もない。ダッシュボードが緑のトンネルを二本示し、設計レビューが別の問いを投げかけるとき、この区別は失われやすい。この接続はどの障害を生き延びる必要があるのか。まずそれに答え、それからトンネルを数えるべきだ。緑のインジケーターの数は暗号化層の性質であり、障害ドメインの数は経路全体の性質だからだ。
緑のトンネルではなく、障害から始める
何かを描く前に四行書く。VPN エンドポイントまたはピア インスタンスの一つの障害、ローカル ルーターまたはファースト マイル接続の一つの障害、共有される ExpressRoute 経路の障害、そしてプライベート ピアリングがまだトラフィックを運んでいる間に IPsec が使えなくなる事態だ。各行は設計が守るべきものを名指しし、それぞれに別の仕組みが答える。
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft は、ExpressRoute のプライベート ピアリング上のプライベート IP によるサイト間 VPN と、インターネット経由のサイト間接続とのサポートされた共存を文書化している。その共存は別のアンダーレイ設計であり、プライベート トンネルのエンドポイントをもう一つ追加したからといって現れるものではない。
障害ドメイン 1：VPN エンドポイント
一つのゲートウェイ上の二本のトンネルは通常、同じ Azure 側リソースで終端するアクティブ/アクティブのペアだ。一本のトンネルや一つのインスタンスの問題には備えるが、そのリソースが使えなくなること、再構成されること、容量が尽きることには備えない。エンドポイントの冗長性とは、独自の経路と独自の構成を持つ二つ目のサポート対象エンドポイントと、そこへ到達できるルートのことだ。
図が示すものではなく、実際に何を展開したかを確認する。ポータルはこれらのリソースを、その関係を隠す形でグループ化するからだ：
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'両方のトンネルが一つのパブリック IP を持つ一つのゲートウェイを指しているなら、それは特定の限られた種類のエンドポイント冗長性だ。要件が求めているのがまさにそれである場合もあり、冗長接続と表現するのではなく、そのように書くべきだ。
障害ドメイン 2：ローカル経路と通信事業者
暗号化の下には物理的かつ商的な現実がある。顧客エッジ装置、クロスコネクト、プロバイダー ネットワーク、ピアリング拠点だ。ExpressRoute の可用性ガイダンス は、エンドツーエンドの冗長性が顧客側とサービス プロバイダー側のセグメントを含み、Microsoft 側だけではないことを明言している。ルーター、電源、ファースト マイル接続を共有する二つの論理経路は、その依存関係も共有したままだ。
ここで設計が誠実なレビューに落ちることが多い。同じ事業者の二回線が同じ建物に終端し、同じ発注の機器で動いていても、それは二つの障害ドメインではない。請求書が二枚ある一つの障害ドメインだ。
通信事業者への質問は文書で行う。これらの経路のどれがどこで分岐するのか、共有区間が障害になったときの文書化された挙動は何か。設計打ち合わせでの口頭の保証は、これから設計する障害には耐えない。
障害ドメイン 3：IPsec なしで生き残る経路
プライベート ピアリングと IPsec は、同じアプリケーション プレフィックスへの競合するルートを提供しうる。保護されたルートが消えたとき、残った直接の ExpressRoute ルートが、トンネルが提供していた暗号化層なしで、まだ使えることがある。それが許容できるかはポリシーの判断であり、最も多く暗黙のまま残される判断でもある。
ここでは暗号化の要件と可用性の要件が本当に衝突しうる。「生き残った経路はどれでも成功とみなす」は可用性についての表明であり、暗号化の問いに静かに「いいえ」と答えている。どちらが優先か、どのプレフィックスについてか、誰が承認したかを書き残す。
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table学習したルートを、期待していたプレフィックスと比較する。小さな管理作業を運ぶフォールバックは、その作業には十分でも、本番需要が必要とする容量にはまったく届かないことがある。だから容量の前提もルートと並べて記録する。
判定を一つではなく、三つの行として記録する
エンドポイントの冗長性、トランスポートの冗長性、災害復旧を設計記録の別々の項目として保ち、それぞれに独自の仕組み、独自の検証、独自の担当者を持たせる。インシデント レビューで、なぜゲートウェイの再起動には耐えたのにファイバー断には耐えなかったのかと問われたとき、三行なら一文で答えられる。「冗長」のチェックボックス一つでは答えられない。
次に、安く試せる行を試す。トンネルを一本落として、トラフィックが移り、再び暗号化されることを確認する。ルートを一本撤回して、残った経路が意図したものかを確認し、さらにそれがまだ暗号化されているかを確認する。シミュレートできなかった障害は文書化する。テストしていない行は前提であり、そう表示すべきだからだ。
有用な成果物は短い表と、行ごとの一文だ。行に仕組みがなければ、それが所見であり、設計レビューで見つけるほうが、両方のトンネルが決して生き延びられなかった通信事業者の障害の最中に見つけるより、はるかに安い。