AWS VPN のローカル CIDR とリモート CIDR：どちらがどちらか

Site-to-Site VPN のオプションを開くと、ローカルとリモートというラベルの付いた二つの CIDR 欄が目に入り、ローカルだと思うアドレス、つまり VPC に手を伸ばしたくなります。これは API の意味とは逆です。接続オプションでは、LocalIpv4NetworkCidr が顧客ゲートウェイ側を指し、RemoteIpv4NetworkCidr が AWS 側を指します。接続は顧客ゲートウェイから構築されるからです。コンソールは決してこれを口に出さず、もっともらしい入れ替えを拒否するものもありません。

コンソールのラベルではなく API 呼び出しから始める

接続オプションのリファレンスを一度最後まで読み、どのオプションも顧客ゲートウェイの視点で書かれていることに気づいてください。これは命名の偶然ではありません。トンネルは、あなたの側でそれを終端する機器から見えるとおりに記述されます。つまりローカルはゲートウェイの背後のネットワーク、リモートは AWS ゲートウェイの背後のネットワークです。IPv4 の欄も IPv6 の欄も同じ規則に従います。

何か入力する前に、二つのラベルを付箋に書きます。顧客側、AWS 側。そのうえで自分のアドレスを当てはめます。

役割を添えた実例

オンプレミスのプレフィックスが 10.20.0.0/16、VPC のプレフィックスが 10.60.0.0/16 だとします。オプションは役割が示すとおりに読め、オンプレミスの範囲はローカル欄に入ります。

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

同じ組をピア機器を設定する人に渡すと、罠が作動します。多くのファイアウォールでは、ローカルはトンネルが終端するインターフェース、リモートは遠端を意味し、AWS 側とは逆の対応になります。二人とも正しいまま、決して確立しないトンネルができあがります。二つの語彙が別の端点を指しているからです。

どちらの機器にも触れる前に、ピア側の用語で紙の上で演習を繰り返します。両方の CIDR と両方のラベルを添えて。

既定値は設計ではない

同じリファレンスは、IPv4 の両方の欄の既定値として 0.0.0.0/0 を挙げ、IPv6 にも同様の値があります。既存の接続でその値を見ても、欄が絞られなかったというだけで、インターネットへの出口が設定されたわけではありません。経路の配布、サブネットのルートテーブル、セキュリティ制御が実際に通せる通信を決めます。CIDR の値は、トンネルがどの範囲を選ぶ用意があるかだけを表します。

したがって、狭い値を既定値に置き換えるのは、トンネルが不調なときに使える互換性の小技ではありません。セレクタを広げるだけで、ほかの層はそのままです。

ピア機器は別の視点を使う

AWS 側が明確になったら、残る混乱の大半はピアの設定にあります。ローカルネットワークとリモートネットワークを尋ねる機器は、自分のインターフェースをローカルと呼びます。だから VPC の範囲はそのリモート欄へ、オンプレミスの範囲はそのローカル欄へ入ります。代わりに通信セレクタを組で尋ねる機器なら、両方向を明示的に書くことになり、ラベルよりも組み合わせが重要になります。

機器の欄の名前ではなく、欄のヘルプを読みます。ベンダーは同じ二つの語を三つの異なる概念に使い回します。

そのうえで両方のフェーズのトンネル状態を確認します。セレクタの不一致は通常、第二フェーズの失敗として現れ、第一フェーズは平然と確立したままです。

オプションは文書ではなく変更として扱う

稼働中の VPN で接続オプションを編集するとサービスが中断し得ます。作業時間帯、戻し値、影響を受ける人の記録を備えた保守作業として扱ってください。まず現在のオプションを、両方の CIDR 欄とトンネルのオプションを含めて控えます。そうすれば切り戻しは貼り付けで済み、作り直しにはなりません。

変更後は AWS 側とピア側の両方から確認します。各範囲の送信元がもう一方の範囲の宛先に届くことを、両方向で確かめます。片側からの ping 一回では、一つのセレクタしか証明できません。

最後に、役割を書き出したうえで接続の文書を更新します。次に触る人が、ローカルとは自分の側だということをもう一度発見せずに済むように。