AWS Client VPN の断続的なアクセス：関連付けられた各サブネットを監査する

ある利用者は接続して社内アプリを開き、応答を得ます。同じエンドポイントにいる同僚は、同じ Wi-Fi につないだ同じ型のノート PC からタイムアウトします。このパターンは、関連付けられたサブネットが複数ある client VPN エンドポイントの特徴で、経路が等価ではありません。コンソールから外側へ順に確認します。二つのタブが、残りの調査に値するかを決めるからです。クライアントの設定にこれを説明するものはありません。

エンドポイントから始めて関連付けを一覧する

VPC コンソールで Client VPN endpoints を開き、エンドポイントを選んで Associations タブを読みます。各関連付けはアベイラビリティーゾーン内のサブネットで、接続が構築されるときにサービスが選んだサブネットにクライアントは着地します。サブネット ID と、それぞれが実際に使うルートテーブルを記録してください。この二つの一覧が、これから行う比較そのものです。

エンドポイントに関連付けが一つしか表示されないなら、この説は誤りで、クライアントのほうが疑わしい。

エンドポイントのルートテーブルを各関連付けと比較する

同じエンドポイントで Route table タブを開きます。そこにある各宛先 CIDR にはターゲットがあり、client VPN ではターゲットはゲートウェイではなく関連付けです。AWS は関連付けられた各サブネットに宛先エントリを要求するため、そのうち一つだけを対象にしたルートでは、アクセスがセッションの着地点に依存します。本当に必要な宛先を確認し、次にその承認ルールを確認します。ルートは経路を与え、ルールは誰が使えるかを決めるからです。

両方の層を表にすれば、障害を見落とすのは難しくなります。

多くのチケットでは、二行目が不具合のすべてです。エンドポイントのルートはあるので誰も先を見ず、パケットは一跳後に VPC の内部で消えます。

各サブネットを、実際に効いているルートテーブルまで追う

ルートテーブルの関連付けが明示されていないサブネットは、VPC のメインテーブルを継承します。実際に有効なテーブルを読み、名前が正しそうなテーブルを読まないでください。また、行のラベルではなく宛先とターゲットを比較します。

AWS の 断続的アクセスのガイド はこれを関連付けをまたぐルートの網羅と位置づけており、それが正しいモデルです。エンドポイントはパケットをサブネットまで届け、そのサブネットのテーブルがアプリケーションネットワークの在り処を依然として知っている必要があります。

欠けている行を、それを所有するテーブルで直します。稼働しているサブネットからルートテーブル全体をコピーすると、このサブネットには決して意図されていなかったインターネット、アプライアンス、分離の選択までコピーされ、その取引はたいてい最初の障害より悪くなります。

承認ルールを確認し、次に戻りの経路

承認ルールは宛先ごと、グループごとに存在し、ルートとは別に評価されます。どこにでもルートがあるのに利用者のグループ向けのルールがない宛先は、健全に見えるルートテーブルを持つブラックホールのように振る舞います。

戻りの経路にも同じ注意が必要です。peering 接続には、アプリの VPC からクライアント CIDR へ戻るルート、両端で通信を許可するセキュリティグループのルール、そしてそれを落とさないネットワーク ACL が要ります。片方向だけの到達性、つまり ping は通るのに TCP のハンドシェイクが通らない場合は、たいてい VPN ではなく ACL かセキュリティグループを示します。

エンドポイント自身のセキュリティグループは関連付けのエラスティックネットワークインターフェース上にあるため、クライアント CIDR からアプリのポートを許可するルールは、インスタンスだけでなく関連付けにも付ける必要があります。

一度の幸運な要求ではなく、再接続で確認する

分割トンネルでは、接続が確立されるときにエンドポイントのルートが送り込まれるため、変わったルート集合は接続したままのクライアントには決して届きません。サポート対象のクライアントで切断して再接続し、新しいルートが端末にあることを確認します。

最後に、接続ログをクライアントが受け取ったアドレスと突き合わせ、複数の関連付けに当たるまで十分に試験を繰り返します。修正後の一度の成功は一つの経路が動くことの証明にすぎず、チケットはもう一方の話でした。