AWS Site-to-Site VPN：外向き・内向きと LAN プレフィックス

一つの AWS VPN で三つのアドレス役割が混同されます。外向きピア、内向きの /30 リンク、保護された LAN プレフィックスです。ダウンロードした設定で確認してください。

AWS Site-to-Site VPN のほとんどの失敗はアドレスの失敗で、しかもパケットが動く前に起きます。トンネルの外向きアドレスは IPsec ピアに届き、内向きアドレスは両者の間のルーティングリンクを作り、保護プレフィックスはそのリンクの目的そのものです。役割を一つ取り違えるだけで、トンネルは上がるのに何もルーティングされません。以下は BGP カスタマーゲートウェイで私が使っている「読む・確かめる・設定する」の順序で、値は記憶ではなくダウンロードしたデバイス設定から取ります。

三つのアドレス役割、一つのトンネル

外向きアドレスはパブリックで IPsec ピアのものです。AWS 側はトンネルごとに一つ、あなた側はカスタマーゲートウェイの到達可能な識別子で、実際の NAT 構成に合わせて調整します。内向きアドレスはプライベートで、論理リンクのものです。AWS はこれを 169.254.0.0/16 から取った /30 として文書化しています。保護プレフィックスは、そのリンク越しにルーティングして広告する VPC、オンプレミス、トランジットのネットワークです。

LAN プレフィックスをトンネルインターフェースのアドレスに割り当てるのが、この失敗の典型的な形です。インターフェースは設定済みに見え、LAN は広告されず、向こう側にはその経路がありません。トンネル自身の内向き ping は通るのに、アプリケーション名はすべてタイムアウトします。トンネルオプションのリファレンスには内向き CIDR の制約が載っており、どのアドレス範囲から取る必要があるかも含まれます。

値はダウンロードした設定から読む

接続から自分のデバイスモデル専用の設定をダウンロードし、そのアドレステーブルを真実の源として扱います。コンソールもトンネルごとに同じ値を示します。外向き IP、内向き CIDR、AWS 側の BGP ピアアドレスです。二つのトンネルは別々のオブジェクトで、外向きエンドポイントも内向き /30 も別々ですが、どちらも同じ保護ネットワークを運びます。

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

ダウンロードしたファイルとライブのコンソールが食い違うなら、ファイルが古いのです。アドレスを手で編集するのではなく再ダウンロードしてください。内向きの組とピア側に設定したネイバーが食い違うと、BGP は静かに失敗します。

正しいアドレスを載せてリンクを作る

Linux ゲートウェイではトンネルは VTI か XFRM のインターフェースで、内向きの /30 はそのインターフェースに載せます。トンネルが二つならインターフェースも二つ、BGP ネイバーも二つで、AWS のエンドポイントごとに一つです。AWS がダウンロード設定に印字する慣例では、仮想プライベートゲートウェイが各内向き /30 の最初のアドレス、あなたのカスタマーゲートウェイが二番目のアドレスになるので、高いほうを取り、低いほうとピアを張ります。ここに LAN アドレスは要りません。

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

お使いのデバイスモデルのファイルが逆の組み合わせを印字するなら、その数値を使い、規則は守ってください。インターフェース上のアドレスが自分側、ピアアドレスが AWS 側です。これを逆にするとトンネルは Established に達しません。設定したネイバーが、自分のインターフェースがすでに持っているアドレスだからです。

mark と VTI キーは、IKE デーモンが子 SA をインターフェースに結び付けるために使う値と揃えてください。揃っていないと、トラフィックはトンネルに届いても降りるインターフェースがありません。MTU は他のサイトから数値を写すのではなく、経路と IKE デーモン自身の設定に照らして確認します。

経路を確認する前に BGP を確認する

IPsec が上がったことは、ピアがセキュリティアソシエーションで合意したことだけを証明します。BGP セッションは内向きリンク上の別の交渉なので、ネイバーの状態とプレフィックスカウンタを読み、広告するつもりだった内容と比べます。

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

Established なのに受信プレフィックスがゼロなら、トンネルではなくポリシーか広告の問題です。同じ確認を二つ目のトンネルでも繰り返してください。一つ目が動くことはアドレスが妥当だという意味で、二つ目が設定済みだという意味ではありません。

ルーティングされたパケットを追い、そこで止める

セッションがプレフィックスを運ぶようになったら、ゲートウェイから両方向の経路を試します。送信元アドレス、ネクストホップ、そして通信を許可するセキュリティポリシーです。BGP セッションが上がっていても、アプリケーションが必要とする特定のプレフィックスがフィルタされ、集約され、あるいは誤ったインターフェースへ向いていることがあります。

Reachability Analyzer は AWS 側のツールで、送信元、宛先、経路を受け取り、サポート対象の構成でどのコンポーネントが遮断したかを報告します。VPC からカスタマーゲートウェイのアドレスまでの経路を試すのに使い、アプリケーションホストからは使いません。構成を解析するだけで、オンプレミスのファイアウォールを通してパケットを送るわけではないので、その判定は自分のインターフェースカウンタやパケットキャプチャとは切り離して扱ってください。

トンネルごとに、外向きの組、内向きの /30、広告するプレフィックスを一つの表に記録します。その表があるからこそ、次の変更がレビュー可能になります。

関連記事