EC2のアベイラビリティーゾーン間：VPNの前にルーティングを確認する

二つのEC2インスタンスの間にVPNソフトウェアを導入する前に、一つの問いに答えてください。同じVPC内にあるでしょうか。同じなら、プライベートな経路はすでに存在し、ゾーンをまたぐ配置はそれを変えません。この状況での作業の大半は、各サブネットが実際にどのルートテーブルを使っているかを確認し、そのうえで障害がそもそもルーティングの問題だったのかを突き止めることです。この問いに対して、トンネルはたいてい誤った答えです。

確認 1：同じVPCか、別々のVPCか

VPCはリージョン単位でアベイラビリティーゾーンにまたがり、各サブネットは必ず一つのゾーンに属します。一つのVPCの異なるゾーンにある二つのインスタンスも、同じプライベートルーティングドメインの内側にあります。

別々のVPCは、リージョンやゾーンラベルを共有しているという理由だけでプライベート経路を得ることはありません。その場合は、サポートされた接続と、独自のルートおよびアクセス許可の作業が必要であり、別の判断になります。

確認 2：サブネットのルートテーブルが示す内容

構成を実際の値で書き出します。VPC 10.60.0.0/16 にサブネット 10.60.1.0/24 と 10.60.2.0/24 があるとき、インスタンス 10.60.1.10 と 10.60.2.20 にはVPCのローカルルート経由の経路が与えられます。

次に、最初に見つけたテーブルだけでなく、両方のサブネットに関連付けられたテーブルを確認します。より具体的な検査用ルートやアプライアンスルートが基本ルートを上書きすることがあり、ローカルルートのターゲット自体も新しい構成では置き換えられる可能性があります。コンソールのどこかにローカルルートが見えるからといって、両方のワークロードがそれを使っている証拠にはなりません。

VPCが実際に割り当てるプライベートアドレスと名前を使ってください。プライベートアドレスが10で始まる必要はなく、記憶から作ってしまうことが、動作している環境を誤診する原因になります。

確認 3：ルーティングか、認可か

ルーティングはパケットをターゲットのネットワークインターフェイスまで届けるだけです。ターゲットのセキュリティグループが送信元とサービスを許可し、送信元の外向きルールが要求を許可し、ネットワークACLがある場合は双方向を許可する必要があります。ACLはステートレスだからです。

その先にはゲストのファイアウォール、リスナーのバインド、アプリケーション自身のIDがあります。どれも、ルーティングが完璧に届けた要求を拒否できます。

受け入れ確認は実際のアプリケーション操作でなければなりません。pingの成功はアプリケーションへのアクセスを許さず、TLS名と資格情報が正しいことも証明しません。pingが遮断されたからといって、すべてのプライベートサービスが停止しているとは限りません。

確認 4：別の接続は本当に必要か

VPNが設計に含まれることはありますが、理由が明示される場合に限ります。このVPCをオフィスに接続する、ノートパソコンを参加させる、オーバーレイの要件を満たす。その理由は、同じVPC内の通常の通信とは異なります。

VPCが何でないかも覚えておいてください。家庭のイーサネットセグメントの延長ではありません。ブロードキャストによる検出に依存するアプリケーションには、別途評価すべき要件があります。それはルーティングの不具合ではなく、設計の欠落です。

確認 5：暗号化の問い

プライベートアドレスと許可ルールは、アプリケーション層の暗号化保護について何も語りません。データにエンドツーエンドの保護が必要なら、それはサービスが実際にサポートするプロトコルとIDモデルからもたらされます。

設計メモでは、ネットワーク層とアプリケーション層の主張を分けてください。混ぜてしまうと、誰も実装していない保護をレビューが主張する結果になります。

記録すべきこと

両方のサブネットID、それぞれに関連付けられたルートテーブル、セキュリティグループの参照、そしてテストしたアプリケーション操作を記録します。これは四つの事実であり、この経路に関する今後の議論の大半を決着させます。

ゾーンの配置だけではVPNを追加すべきとは決して言えませんし、プライベートな要求がなぜ失敗したのかも決して説明しません。