AWS Client VPN の分割トンネル：公開すべきルートの選び方

コンソールには分割トンネルの切り替えがあるため、判断はチェックボックスに見える。そうではない。実際にクライアントへ届くのはエンドポイントが公開したルート集合であり、その一覧が、どのプライベートプレフィックスがトンネルを使うか、一般的なインターネット通信をローカルに残すか AWS から出すか、どのリゾルバーとまだ通信できるかを決める。三つの問いが設計を決め、いずれも接続が成功したまま誤って答えることができる。

分割トンネルのフラグは宛先一覧ではない

AWS は分割トンネリングを、接続確立時にエンドポイントのルートをクライアントのルートテーブルへ追加するものと説明している。プライベート VPC へのルートはトンネルをその宛先に限定し、それ以外はクライアントの通常の経路を通る。デフォルトルートは別の指示であり効果も別である。だからこそ 分割トンネルのドキュメント は、このモード向けに構成したエンドポイントで 0.0.0.0/0 を公開しないよう警告している。公開すると接続を広げるどころか壊すことが多い。エンドポイントのルートテーブルがポリシーであり、クライアントのルートテーブルは確認できる結果である。

エンドポイントのルートテーブルとクライアントにインストールされたルートを併せて読む。ラベルは意図を語り、ルートは実際に起きることを語る。

判断の一つ目：一般的なインターネット通信をローカルに残すべきか

閲覧に利用者自身の回線を使わせるなら、業務に必要なプライベート宛先だけを公開してそこで止める。フルトンネルの解説にあったからという理由でインターネットルートを足してはならず、追加ルートが安全性を高めるとも考えない。経路が変わるだけでポリシーは増えず、想定していない遅延を払うことになる。

インターネット通信を AWS から出したいなら、文書化されたインターネットアクセスの構成を作る。エンドポイントのルート、認可ルール、関連付けたサブネットの経路、セキュリティポリシー、そして機能する上流の出口である。デフォルトルートだけではそのどれも用意できない。

判断の二つ目：どのプライベートプレフィックスを、誰の認可で公開するか

実際の作業に必要な最小の宛先集合を公開し、関連付けた各サブネットがそこへルーティングできることを確認する。エンドポイントのルート先とサブネットの VPC ルーティングは別の層であり、片方にあるルートはもう片方の証拠にならない。認可はさらに別である。宛先に到達できても、クライアントのグループに許可するルールがなければ拒否される。

成功した一度のセッションは一つの経路しか証明しない。関連付けた各サブネットを確認する。後から追加されたサブネットの関連付けこそ、欠けたルートが潜む場所だからだ。

宛先に名前で到達する必要がある場合、次の問いはルートではなく名前解決であることに注意する。

判断の三つ目：どのリゾルバーがトンネルに従うか

クライアントは VPN 経由でしか到達できない DNS サーバーを受け取ることがあり、そのリゾルバーは自分のアドレスが認可されたルートの内側にあるときだけ機能する。両方を検証する。リゾルバーのアドレスが公開ルートに従っていること、そしてサーバーがアプリの問い合わせる名前に応答することである。アドレスでは成功するのにホスト名で失敗する要求は、ルーティングではなく命名の問題を示しており、その状態でトンネルを調べても午後が無駄になる。

公開名は接続前と同じように解決されるべきであり、これは何を公開するかに正確であるべきもう一つの理由である。

ルート集合を変え、それから両方の世界を検証する

AWS は、分割トンネルのエンドポイントでルートを変更するとクライアント接続がリセットされると記している。それを踏まえて変更を計画する。適用し、対応クライアントで再接続し、編集前に適用された状態を信じるのではなく、インストールされたルートを読み直す。古い適用状態は、正しい変更が壊れて見える最もよくある理由である。

設計を受け入れるのは、プライベート資源と公開宛先がどちらも意図どおりに、名前でもアドレスでも、実際に支えるアドレスファミリー上で振る舞うときだけである。認証が通るトンネルと、正しく分割するトンネルは同じではない。

ルート一覧を根拠と並べてランブックに書き、次の人が意図的な除外と忘れた除外を見分けられるようにする。