AWS Client VPN の DNS：サブネットではなく VPC リゾルバーを使う

エンドポイントは 10.0.8.0/24 にあるので、リゾルバーは 10.0.8.2 でなければならない。これは最もよく聞く推論だが、二重に間違っている。Route 53 Resolver は VPC のプライマリ IPv4 範囲プラス二で応答し、10.0.0.0/16 の VPC では 10.0.0.2 になる。エンドポイントがどのサブネットを使うかは関係ない。二つ目の誤りはもっと静かだ。正しいアドレスをエンドポイントに入れても、クライアントの OS がそれを尋ねるとは限らない。どちらの誤りも同じ症状を生む。名前解決があるクライアントでは動き、別のクライアントでは失敗する。

誤解はサブネットの関連付けから始まる

関連付けはクライアント接続用のエラスティックネットワークインターフェースがどこに置かれるかの話であり、どのリゾルバーアドレスが存在するかの話ではない。エンドポイントのサブネットはクライアントに VPC 内のアドレスを与えるが、それぞれが独自のリゾルバーを持つわけではない。

この二つの考えを切り離せば、計算は謎ではなくなり、トラブルシューティングはクライアントへ移る。これらの事例の大半は実際そこへ行き着く。

プライマリ VPC 範囲からアドレスを計算する

VPC のプライマリ IPv4 CIDR を取り、ネットワークアドレスに二を足す。10.0.0.0/16 なら 10.0.0.2、172.31.0.0/16 なら 172.31.0.2 になり、セカンダリ範囲を持つ VPC でもリゾルバーはプライマリ側に残る。その VPC 内の 10.0.8.0/24 のサブネットでは動かない。エンドポイントに触れる前にアドレスを VPC ID の隣に書いておくこと。この数値は接続ではなく VPC の性質だからだ。

VPC はリンクローカルアドレス 169.254.169.253 でも応答する。このアドレスは VPC 内部からは到達できるが、トンネルの反対側にいるノート PC にとって一般的に経路が通る宛先ではない。

つまり有効なリゾルバーアドレスは二つあり、どちらもサブネットプラス二ではない。

エンドポイント設定がすること、しないこと

Client VPN エンドポイントには DNS サーバーの項目があり、コンソールが VPC リゾルバーの選択肢を出す場所では同じ考えを埋める。設定すると、接続確立時にサービスがクライアントへ渡す値が変わる。しかし管理されていない OpenVPN クライアントがその値をどう扱うかは変わらない。クライアントは結局 OS に適用しなければならないからだ。「Mac では動くが Linux 機では動かない」はこのずれから来る。

Linux では リゾルバーの統合は接続マネージャーが持つのであり、利用者ではない。/etc/resolv.conf を手で編集すると、そのアドレスが一つのセッションで動くことだけが証明され、再接続で消える。直したはずの事例が翌朝また戻るのはそのためだ。

接続後に確認するのはクライアント上の有効なリゾルバーであり、エンドポイントの設定画面ではない。

スプリットトンネリングは正しいリゾルバーを無効にしうる

スプリットトンネリングではトンネルに流した経路だけが使われる。リゾルバーアドレスが経路で覆われていなければ、問い合わせはローカルインターフェースから出て自宅のルーターが答える。エンドポイントのアドレスは正しいままで、名前解決は失敗し続ける。リゾルバーの経路を追加して、もう一度試す。

重複するローカル範囲は同じ結果をより厄介な形で生む。問い合わせには答えが返るが、それは間違ったサーバーからのものだ。

Amazon DNS アドレス用にセキュリティグループを開けない

名前解決がタイムアウトしたときの衝動は、リゾルバーアドレスへの UDP 53 を許可するルールを足すことだ。AWS は、セキュリティグループとネットワーク ACL が Amazon DNS の通信を、独自の DNS インスタンスへの通信のようには絞り込まないと文書化している。それらのルールを開けても VPC リゾルバーには何も変わらず、理由なく境界を広げるだけだ。自分で運用するリゾルバーは別の話で、独自のルールが本当に必要になる。

設計に両方が現れるなら、どのルールを編集する前にも、クライアントが実際どちらを向いているかを確認する。

経路を検証し、それから別のものを測る

公開名を解決し、VPC に関連付けられたプライベートホストゾーンに登録された非公開名を解決し、その間にクライアントの有効なリゾルバーを読む。この順序で「リゾルバーアドレスが間違い」「ゾーンが関連付けられていない」「クライアントが設定を無視した」を切り分けられる。それぞれ直し方は違い、どれもスループットの問題ではない。

名前解決の成功は持続的な転送速度について何も語らない。報告するときはこの二つの話を分けておく。