マネージドVPNのインターネット出口は実際どこから抜けるのか
「インターネット込み」という言葉は、公開トラフィックがどこから出るのか、誰がそれをフィルタリングするのか、障害後に何が残るのかを何も語りません。経路をたどり、そのうえで二つの障害ケースを書き出してください。
そのトラフィックがプロバイダーのネットワークをどこで離れるのかを提案書が示すまで、支店の公開トラフィックを誰がフィルタリングしているのかは言えません。マネージドVPNに同梱されたインターネット接続は二つ目のサービスであり、独自のゲートウェイ、独自のアドレス変換、独自のエスカレーション待ち行列を持つ経路を通ります。ほとんどの契約はプライベート側を詳細に記述し、公開側は一文に任せています。以下の確認は、その一文を弁護できる図に変えます。
サイトごとに公開宛先を一つたどる
支店のホストを選び、公開宛先を一つたどり、プロバイダーに属する最後のアドレスとインターネットに属する最初のアドレスを記録します。その二つのアドレスの間のホップが出口であり、パケットを送ったサイトの近くにあることはほとんどありません。何が出て行くかを決めるフィルターはまさにその機器が持っているので、遷移を行う機器を特定してください。請求書の上で同じに見える二つの支店でも別の都市の別のゲートウェイから出ていることがあるので、二つ目のサイトから同じ追跡を繰り返し、出口アドレスを比較します。
変換はあなたが一度も描かなかったホップで起きているかもしれないので、宛先が実際に見る送信元アドレスも記録してください。観測した答えを図に描いた答えの隣に書き、その差が最初のインシデントの出どころです。あるサイトの出口アドレスを答えられないプロバイダーの技術者は、すでに設計について有用なことを教えてくれています。
三つの出口構成と、それぞれが何を集中させるか
自社で運用する中央出口は公開トラフィックを自社のゲートウェイへ引き寄せ、フィルタリングポリシーとログを手元に置く一方、すべてのサイトの負荷を一本の回線に集中させます。プロバイダー運用の出口はポリシーとログを契約の境界の向こうへ移し、運用を単純にするのと同じ動きで可視性を奪います。サイトごとの出口は公開トラフィックをローカルに保ち、同一に保たねばならないポリシーの面を増やします。
| Arrangement | Blast radius of one failure | Address a partner allowlists |
|---|---|---|
| Central exit you operate | Every site, through one circuit and one team | Your own exit pool |
| Provider-run exit | Their shared gateway and its change window | Their NAT pool, often shared |
| Exit at each site | One branch, one local device | Each site's local address |
一覧をメニューとして扱う前に、プロバイダーが実際に提供するのは三つのうちどれかを尋ね、サイトが新しい回線なしに相互へ移れるかを尋ねてください。移行に関する答えは、契約上のものを単なる技術的なものから切り分けます。パートナーが許可リストに何を載せるべきかはそれで決まるので、送信元変換を誰が持つかも記録してください。共有ゲートウェイは共有容量を意味し、ときに共有の評判も意味するため、パートナーがあなたのアドレスをどう扱うかが変わります。共有ゲートウェイは同じ瞬間に他の顧客にサービスを提供しているので、容量も独自の問いを持つべきです。
フィルタリング、変換、暗号化の所有者は別である
経路は到達性を確立するだけで検査については何も語らないので、両者を別の所有者を持つ別の問いとして扱ってください。広告される既定経路ごとに、フィルタリングする機器、認証する機器、変換する機器、検査する機器を挙げ、それぞれを誰が管理するかを挙げてください。プライベートサービスがある境界でトンネルを終える一方で公開出口は別の境界で終わることがあるため、プロバイダーの経路分離は暗号化がどこで終わるかを示しません。変換がプロバイダー境界で起きるのか、共有ゲートウェイで起きるのか、自社の出口で起きるのか、またセッションログが存在するのか、どれだけ保持されるのかを尋ねてください。四つの仕事に一つの当事者を挙げる契約はたいてい三つを文書化しないまま残すので、答えの中の所有者を数えてください。
広い既定経路 プライベートルーティングコンテキストへインポートされた ことも、インポートは無害な便宜ではなく意図された合意だから、同じ検証に値します。 RFC 4364 の第11節 はBGP/MPLS VPN向けのインターネットアクセス構成をいくつか取り上げ、VPNコンテキストとプロバイダーの既定転送コンテキストの間の経路交換を、まさにその種の合意として扱っています。公開トラフィックが誤ってプライベート経路を取るのを何が防ぐのかを尋ね、答えはスライドではなく経路ポリシーの隣で受け取ってください。
署名前に合意すべき二つの障害ケース
契約に、インターネット出口を失う場合とプライベート接続を一つ失う場合の二つのテストを書き込みます。それぞれについて、動作を続ける必要のある内部リソース、ローカルのインターネットサービス、管理経路を列挙します。中央の制御を迂回する経路はきれいな停止よりも悪いので、遮断されたままにすべき代替経路を列挙します。両方のテストをプロバイダーに渡し、検出と通知を含む期待結果を書面で求めてください。
同じ検査をパイロットサイトから実行し、その書面の答えと比較します。両者が一致しない箇所では、契約はあなたが買ったものとは別のネットワークを記述しています。二つのコマンドでよくある場合は押さえられ、一つは公開宛先がたどる経路を、もう一つはそれが見るアドレスを示します。
traceroute -n 203.0.113.10
curl -s https://example.net/ip可用性の約束は、サービスの名前ではなく、測定したセグメントに結び付けてください。ローカル回線、プロバイダーのバックボーン、共有ゲートウェイは、それぞれ別の義務と別のエスカレーション体制を負います。L2VPN、L3VPN、MPLSという文字は転送の仕組みを表すもので、端から端までの保証ではありません。
提案書の形容詞より証拠が勝つ
冗長、安全、回復力があるといった言葉は、設計ではなく意図を表します。代わりに機器の一覧、出口の場所、変換の方式、通知の経路を求めてください。その四つを出せるプロバイダーには設計がありますが、出せないプロバイダーにあるのはスライドです。答えはメールのやり取りではなくサービスの文書に残し、契約が変わるたびに見直してください。
プロバイダーがゲートウェイを統合するにつれ出口構成は静かに動くので、三年前の図は負債です。パートナーが未知の送信元アドレスを報告してきたとき、それがあなたの設計から来たのか、誰も告知していない変更から来たのかを数分で言えるべきです。形容詞ではなく、その能力こそが最初の障害を生き延びます。