AWS NATゲートウェイでGREとESPが通らない理由

トンネルは失敗し、セキュリティグループはすでに全トラフィックを許可しており、結論はAWSがVPNをブロックしているというものだ。AWSは何もブロックしていない。マネージドNATゲートウェイが転送するのは文書化された外部プロトコルの集合であり、ネイティブGREやネイティブESPはそこに含まれない。だから追加したルールでゲートウェイがそれらを運ぶようにはならない。許可ルールと転送能力は別のものであり、変更できるのはそのうち片方だけだ。

ルール集合はプロトコル集合ではない

セキュリティグループは、どのトラフィックがインスタンスを離れてよいかを決める。NATゲートウェイは、何を変換して転送できるかを決める。二つ目の制限が当てはまるとき、許可的なルールは、人がファイアウォール問題と誤読する症状をそのまま生む。パケットはインスタンスを離れ、制御のやり取りは完了することさえあり、相手には何も届かない。

AWSのNATゲートウェイのプロトコル仕様は、マネージドサービスの対象をTCP、UDP、ICMPとして列挙している。これがサポートされる集合のすべてだ。別のIPプロトコルに対する許可ルールでこれを広げることはできない。ルールはゲートウェイの転送経路に到達するはるか前に評価されるからだ。

この区別が重要になるのは、二つの失敗がクライアント側からは同一に見え、修正方法はまったく異なるからだ。

PPTPはポートテストが嘘をつく理由を示す

PPTPは、何も証明しないポートチェックの最も明快な旧例だ。ポート1723でTCPの制御接続を開き、その後トンネルデータをGRE（IPプロトコル47）で運ぶ。プロトコル47はTCPポート47ではなく、両者は数字を共有している以外に何の関係もない。

1723への接続を試してハンドシェイクの完了を見た運用者は、経路が機能していると結論する。しかしデータチャネルは一パケットも通らない。ゲートウェイに提供できるGREサポートがないからだ。これは古いプロトコルの要件の解釈であり、何年も前に廃れたPPTPを導入する助言ではない。

同じ論理は、制御チャネルがTCPかUDPでデータ経路がそうでないあらゆるプロトコルに当てはまる。

IPsecはUDPとしてのみ生き残る

IPsecは、答えが平然とした「いいえ」ではなく条件付きになるケースだ。AWSはNATゲートウェイ経由のIPsecについて、NATトラバーサルをサポートされる構成として文書化している。NAT-Tが折衝されればESPはUDPの中にカプセル化され、ゲートウェイはプロトコル50ではなく通常のUDPを見る。

UDP 4500を許可しても、エンドポイントがNATトラバーサルを使うようになるわけではない。すでにその形になっているパケットを許可するだけだ。クライアント自身の折衝出力からどのカプセル化が選ばれたかを確認し、受信側で相手がそれを受け入れたかを確認する。ネイティブESP向けに設定された二つのエンドポイントは、ルール集合が何と言おうとネイティブESPを送り続ける。

TCPやUDPベースのVPNは文書化された転送集合に適合し、それでもルーティング、フィルタリング、認証の理由で失敗しうる。集合に適合することは必要であって、十分ではない。

ポリシーを広げる前に経路を確認する

ワークロードサブネットの実際の経路とその次のホップの正体をまず確認する。直接のパブリック経路、NATインスタンス、マネージドNATゲートウェイ、トランジットゲートウェイ経由のプライベート経路は四つの異なる設計であり、ここで説明するマネージドサービスはそのうち一つだけだ。

次に、試したエンドポイント、アドレスファミリー、外部プロトコル、プロトコルにポートがある場合はそのポートを記録する。成功したブラウザ要求ではなく、クライアントの診断とネットワーク所有者のフロー観測を使う。ブラウザ要求はTCPとUDPが動くことしか証明しない。その後、フローの両方向についてセキュリティグループ、サブネットACL、ゲストファイアウォール、サービスポリシーを見直す。

サービスが運べない転送を補うために全トラフィックを開けてはいけない。ルール変更では直らず、インシデントの後も残る。

転送が適合しない場合

外部プロトコルがサポート集合の外にあるなら修正はアーキテクチャ側であり、経路が運べる転送を選ぶか、必要なものを運ぶ先へ出口を移す。OpenVPNのUDP、WireGuardのUDP、TLSベースのトンネルはいずれも文書化された集合に適合する。特定のプロトコルを通す必要があり、運用コストが許容できるなら、顧客管理のNATインスタンスが選択肢になる。

受信VPNサーバーのホストは別の答えを持つ別の問題だ。NATゲートウェイは送信の変換を提供し、一般的な受信ポート転送は提供しない。したがってその背後にあるサーバーは、独自の条件で設計された承認済みの公開入口を必要とする。

作業順序は、外部プロトコルを特定し、次のホップを確認し、文書化された集合と比較し、それからアーキテクチャか転送を変える。別のポート番号でGREがTCPになるわけではなく、許可ルールを一つ増やしても完了した制御のやり取りが機能するデータチャネルにはならない。