ピア接続されたVPCへ到達するAWS Client VPNとbastionの比較

一つのClient VPNエンドポイントは、関連付けられたVPCとピア接続されたVPCに到達でき、それを正当化するためにbastionは必要ない。検討に値する選択は、トラフィックがどこで持ち主を変えるかである。関連付けサブネットに着地してピア接続を越えるエンドポイントルートか、ピア接続されたVPC内でセッションを終わらせるホストか。どちらの経路も機能し、壊れる場所が異なる。したがって判断はAWSが何を許すかではなく、所有権と監査の問題である。以下は私が両者をどう選び分けるかと、ルーティング経路を成立させる四つの項目だ。

二つの経路、一つのエンドポイント、異なる所有者

ルーティング経路では、クライアントのトラフィックがエンドポイントに届き、関連付けサブネットにあるClient VPNネットワークインターフェースのアドレスへ変換され、AからBへのピア接続を越えてそのサブネットを出る。VPC BはVPNセッションを終端しない。VPC Aからの通常のトラフィックとして見えるため、戻りルートはクライアントプールではなくVPC Aを指す。

bastion経路では、クライアントはまずホストに届く。Aにあるbastionは最後のホップを依然としてピア接続の向こう側に置くので、ピア接続の作業は残り、セッションが一つ増える。Bにあるbastionもクライアントからの経路を必要とし、その経路が同じエンドポイントルートなら、ルーティング設計にホップが一つ加わるだけだ。bastionが作業を減らすのは、すでに存在し、すでに承認され、その背後のものがネットワーク境界ではなくセッション境界を必要とする場合に限られる。

四つの項目がルーティング経路を成立させる

AWSはこのシナリオをClient VPNのhow-it-worksページで文書化しており、実際には二つか三つのチームが所有する四つの項目に帰着する。範囲は例示である。ピア範囲は一意でなければならず、戻り範囲は計画と一致しなければならない。

ルートと許可は別の統制だ。対応する承認ルールのない正しいエンドポイントルートはクライアントに何も与えない。エンドポイントがルーティングできない宛先に対する承認ルールは、黒い穴を与えるだけだ。両方が同じ範囲を指す必要がある。

エンドポイントルートはエンドポイント自身のVPC内のサブネットを指し、決してピア接続を指さない。VPCのルートテーブルはピア接続を指し、決してインスタンスやインターフェースを指さない。両者の間で値をコピーしても警告なしに保存され、何もルーティングしない。

関連付けサブネットがクライアントの送信元を変換するため、BはクライアントプールではなくVPC Aへ戻るルートを持つ必要がある。クライアント範囲をピア接続の向こうへ送るのは対称に見え、レビューも通るが、Bはクライアントを送信元とするパケットを決して見ないので静かに失敗する。

セキュリティグループと許可の最後の一米

ルーティングはパケットをBへ運ぶが、決めるのはBだ。同一リージョンのアクティブなピア接続では、BのセキュリティグループがClient VPNの関連付けに適用されたグループを参照でき、ルールを狭く保ちアドレス変更にも耐える。グループ参照が使えない場合は、0.0.0.0/0へ広げるのではなく関連付けサブネットの範囲を明示的に許可する。広げるとルーティングの誤りが説明のつかないタイムアウトに変わる。

次に、ルーティングが決して触れないものを確認する。両方のサブネットのネットワークACL、アプリケーションの許可リストやトークンの対象、そしてDNSだ。ピア接続はプライベートホストゾーンを複製しないので、ノートPCは解決できないアドレスへの有効なルートを保持しうるし、ピア接続は証明書に信頼を加えない。エンドポイントをBに答えるリゾルバーへ向け、プライベート名と証明書が一致することを確認する。

bastionが正直な答えとなる場合

私は意図してbastionを選ぶための三つの引き金を保持している。ピア接続されたVPCが、あなたの範囲に戻りルートを追加しない、あるいはグループ参照を受け入れないチームのものだ。アクセスをセッションごとに承認または記録する必要があり、アプリケーションがそれを自分で担えない。あるいは最後のホップがBの内側に残る必要がある。サービスがそこだけで解決され、TLSの同一性が内部名に固定されているからだ。

いずれもピア接続が非推移的であるという事実の回避ではない。非推移性はBのリソースができることを制限する。Aがピア接続している第三のVPCへのトランジットとしてAを使うことはできない。VPN利用者が直接ピア接続されたVPCへ到達できないという意味では決してなく、その誤読を避けるために作られたbastionは理由なくパッチを当てるホストになる。

逆の誤りは時間とともに高くつく。すでに存在する一つのbastionに全チームを通し、そのセキュリティグループ、ルートテーブル、パッチ適用の窓が本番の依存になっていると気づく。ホストがどの引き金に仕えているかを書き留め、引き金が消えたら引退させる。

Transit Gatewayと複数の関連付けが計算を変える

エンドポイントがサブネットではなくTransit Gatewayに直接接続されている場合、モデルが変わる。クライアントは関連付けサブネットのインターフェースアドレスへ変換されなくなり、ゲートウェイのルートテーブルがクライアント範囲とピア接続されたVPCへ至る接続の両方を運ぶ必要がある。規模が大きくなるとより清潔だが、作業は四つの項目からゲートウェイルートテーブルへ移る。

複数の関連付けは確認を倍にする。エンドポイントルートはエンドポイントのものだが、どの関連付けサブネットも実際のピア次ホップを持つルートテーブルを必要とする。ある関連付けではセッションが成功し、別の関連付けに戻り経路がないことがあるので、それぞれを試す。

破損を素早く見つける検証順序

これらを順に実行する。各手順は次が失敗している間も成功しうるし、クライアントのタイムアウトはどれが壊れたかをほとんど語らない。

1. クライアントからアプリケーション名を解決し、アドレスがピア範囲内にあることを確認する。
2. 接続し、セッションを終えた関連付けのエンドポイント接続ログを読む。
3. その関連付けサブネットで、ルートテーブルがピア範囲をアクティブなピア接続へ向けていることを確認する。
4. Bのリソースサブネットで、インターフェース範囲の戻りエントリと一致するグループルールを確認する。
5. 許可された操作を一つと、到達不能のままでなければならないリソースを一つ試す。後者がデバッグの残骸を捕まえる。
6. split-tunnelのルート変更の後は必ず再接続する。稼働中のトンネルは新しいルートセットを取り込まない。

覚えておく価値のある症状が二つある。応答なしでBに届くSYNは、ほぼ常に戻りルートの欠落だ。完了してからリセットされる接続は、たいていグループ、ACL、アプリケーションのいずれかだ。どちらもエンドポイントログに原因として現れないので、四つの項目をそれぞれの所有者と並べて保持する。

三つの引き金がどれも当てはまらなければ、ルーティング経路を完成させ、その四つの項目を記録する。一つでも当てはまるなら、bastionはその境界のためだけに残し、エンドポイントルートは手前にセッションを必要としないサービスへ残す。