VGW の BGP 広告と VPC ルートテーブル:何が何を変えるのか

VPC サブネットのルートテーブルに欠けているプレフィックスと、カスタマールーターに欠けているプレフィックスは別々の障害であり、AWS のルートテーブル内で修復されるのはそのうちの一方だけです。仮想プライベートゲートウェイは自分の VPC に関連付けられた CIDR ブロックを広告し、サブネットのルートテーブルはワークロードが応答をどこへ送るかを決めます。 二つ目を一つ目を変える手段として扱うこと が、この診断で最も多い誤った分岐です。以下のチェックを順番に実行し、二つの方向を切り離しておいてください。

どのテーブルを読む前にも、アタッチメントの名前を確認する

サイト間 VPN は仮想プライベートゲートウェイかトランジットゲートウェイのどちらかで終端し、リソース ID がどのルーティングモデルが適用されるかを決めます。まずそれを読みます: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'。その答えで、次に調べるテーブルが VPC ルートテーブルなのか、トランジットゲートウェイのルートテーブルなのかが分かります。

VPN がトランジットゲートウェイに接続されているなら、VPC ルートテーブルをコントロールプレーンとして扱うのはやめてください。そこでは VPC のテーブルはゲートウェイのアタッチメントを指し、関連付けと伝播はトランジットゲートウェイのルートテーブルで行われます。二つの見方を混ぜると、間違った対象について自信過剰な結論が出ます。

AWS からオフィスへの方向は広告です

VGW アタッチメントの場合、ゲートウェイは自分の VPC に関連付けられた CIDR ブロックを BGP 経由でカスタマーゲートウェイに広告します。個別のサブネットルートを追加したり、ルートをピア VPC やアプライアンスに向けたりしても、別の関連付け CIDR が増えるわけではなく、その広告にも現れません。オフィスでプレフィックスが欠けているなら、どのルートテーブルを編集する前にも、受信したルートの一覧を VPC の関連付けと比較してください。

単純なルールには例外があるので、適用範囲を限定してください。VPN CloudHub の構成ではカスタマーゲートウェイ間でサイトプレフィックスを再広告でき、トランジットゲートウェイは独自の伝播ルールに従います。VGW が自分の VPC だけを広告するというのは便利な既定であって、出会うすべてのトポロジーを覆う法則ではありません。

オフィスから AWS への方向は伝播と選択です

逆方向では VGW がオフィスのプレフィックスを学習しますが、それだけではワークロードは動きません。サブネットのルートテーブルでアタッチメントの伝播を有効にするか、同じ宛先への静的ルートを持たせる必要があります。一つのプレフィックスに両方がある場合、静的ルートが勝ち、最長プレフィックス一致はどちらよりも先に実行されます。

推測せずにオリジンを読んでください: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'。オリジンが EnableVgwRoutePropagation のエントリは BGP から来たものです。オリジンが CreateRoute のエントリは人間が入力したもので、誰かが削除するまで勝ち続けます。

二つの方向を切り離しておくランブック

何かを変える前に、AWS 側で四つの事実を記録します。アタッチメントの種類、関連付けられた VPC の CIDR、問題のプレフィックスに対するサブネットルートのオリジン、そしてトンネルと BGP の状態です。同じ describe 呼び出しはトンネルごとの受け入れルート数を含む VgwTelemetry を返し、AWS がそもそもルートを受け入れたかどうかが分かります。次にそれを、カスタマー側のデバイスが実際にインストールした内容と比較します。BGP にあって転送テーブルにないプレフィックスは、ローカルインポートか最良パスの問題であり、AWS のルートテーブルの問題ではありません。

サブネットのテーブルにプレフィックスがまったくないなら、伝播を有効にするか静的ルートを追加し、変更が即時だったと決めつけるのではなく伝播間隔の後に同じクエリを読み直してください。プレフィックスがあってトラフィックがまだ失敗するなら、コントロールプレーンはそのままにしてデータパスに移ります。

そこにいる間に変えてはいけないもの

欠けたプレフィックスを一つ直すために無関係なルートテーブルの伝播を切り替えたり、欠けた CIDR を一つ覆い隠すためにデフォルトルートを追加したりしないでください。どちらも影響範囲を広げ、次の診断を難しくします。編集は、問題のワークロードサブネットを担当するテーブルだけに限定してください。

データパスはこれらすべてとは別です。セキュリティグループはステートフルで、ネットワーク ACL はそうではなく、ホストのファイアウォールや非対称な戻りパスは、ルーティングが正しく届けたトラフィックを落とすことがあります。広告された集約はその中のすべてのサービスを許可するわけでもないので、アドレスがたまたま BGP 広告に現れるかどうかに頼るのではなく、ポリシーの境界でアクセスを制限してください。

すべてのルートテーブルクエリの変更前と変更後を変更記録に保存してください。変更で状況が悪化したら、以前のルートに戻し、同じクエリで確認してください。検証できないロールバックは単なる推測です。