DNS と AWS クライアント VPN エンドポイントとの連携のしくみを把握したいです。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

新しいクライアント VPN エンドポイントを作成する際、DNS サーバーの IP アドレスを指定します。「DNS Server IP address」パラメータに IP アドレスを指定するには、AWS マネジメントコンソール、create-client-vpn-endpoint AWS CLI コマンド、または CreateClientVpnEndpoint API を使用します。既存のエンドポイントを変更するには、コンソール、modify-client-vpn-endpoint コマンド、または ModifyClientVpnEndpoint API 操作を使用します。

「"DNS Server IP address」パラメータを設定する

高可用性を実現するには、DNS サーバーの IP アドレスを 2 つ指定します。プライマリ DNS サーバーに到達できない場合、クライアントはクエリをセカンダリ DNS サーバーに再送信しようとします。

注: プライマリ DNS サーバーが SERVFAIL で応答した場合、DNS 要求はセカンダリ DNS サーバーに再送信されません。

エンドユーザーがクライアント VPN エンドポイントに接続した後に、指定した DNS サーバーの両方にアクセスできることを確認します。DNS サーバーに到達できない場合、DNS リクエストは失敗し、接続の問題が発生する可能性があります。

「DNS Server IP address」パラメータは省略可能です。DNS サーバーが指定されていない場合は、エンドユーザーのデバイスに設定されている DNS IP アドレスを使用して DNS クエリを解決します。

Client VPN DNS サーバーが AmazonProvidedDNS または Amazon Route 53 Resolver のインバウンドエンドポイントである場合は、次のことを考慮してください。

• Amazon Virtual Private Cloud (Amazon VPC) に関連付けられている Route 53 プライベートホストゾーンのリソースレコードを解決できること。
• Private DNS が有効になっている場合、VPN インターフェイスの予約からアクセス可能な Amazon RDS のパブリックホスト名は、プライベート IP アドレスに変換されること。これは、Amazon VPC インターフェイスエンドポイントからアクセス可能な AWS サービスエンドポイント名にも当てはまります。
• 関連する VPC で DNS Resolution と DNS Hostnames が有効になっていることを確認してください。

クライアント VPN エンドポイントは、送信元の NAT を使用して関連する Amazon VPC 内のリソースに接続します。

トンネルタイプ別の DNS の動作

クライアントデバイスがクライアント VPN トンネルを確立すると、DNS Server IP address パラメータがフルトンネルまたはスプリットトンネルに適用されます。

• フルトンネル: クライアントは、VPN トンネル経由のすべてのトラフィックのルートを追加します。DNS クエリを含むすべてのトラフィックは、トンネルを経由してルーティングされます。Amazon VPC に DNS サーバーへのルートがない場合、ルックアップは失敗します。
• スプリットトンネル: クライアントは、クライアント VPN のルートテーブルからのルートのみを追加します。DNS トラフィックを VPN 経由でルーティングするには、DNS サーバーの IP アドレス用のルートをクライアント VPN のルートテーブルに追加します。

次の例は、Windows 環境と Linux 環境の両方に適用されます。Linux では、例ではクライアントが汎用ネットワークマネージャーを使用していることを前提としています。

シナリオ 1: DNS サーバーの IP アドレスが指定されていないフルトンネル

例 1:

• エンドユーザークライアントの IPv4 CIDR: 192.168.0.0/16
• クライアント VPN エンドポイント VPC の CIDR: 10.123.0.0/16
• ローカル DNS サーバーの IP アドレス: 192.168.1.1
• DNS サーバーの IP アドレスパラメータは無効になっており、DNS サーバの IP アドレスは指定されていません

DNS サーバーの IP アドレスパラメータは無効になっているため、エンドユーザーのホストマシンはローカル DNS サーバーを使用してドメイン名を解決します。

このクライアント VPN エンドポイントはフルトンネルモードに設定されています。すべてのトラフィックを VPN 経由で (utun1 から 0/1) 送信するために、クライアントは仮想アダプタを指すルートを追加します。ただし、エンドポイントが DNS サーバーの設定をプッシュしないため、DNS トラフィックは VPN 経由で送信されません。代わりに、クライアントはローカル DNS サーバーアドレス (en0 経由の 192.168.1.1/32) の静的ルートを使用します。ドメイン名をローカルで解決した後、解決した IP アドレスへのアプリケーショントラフィックは VPN トンネルを通過します。

$ cat /etc/resolv.conf | grep nameservernameserver 192.168.1.1
$ netstat -nr -f inet | grep -E 'utun1|192.168.1.1'0/1                192.168.0.1        UGSc           16        0   utun1
192.168.1.1/32     link#4             UCS             1        0     en0
(...)

$ dig amazon.com;; ANSWER SECTION:
amazon.com.        32    IN    A    176.32.98.166
;; SERVER: 192.168.1.1#53(192.168.1.1)
(...)

例 2:

• エンドユーザークライアントの IPv4 CIDR: 192.168.0.0/16
• クライアント VPN エンドポイント VPC の CIDR: 10.123.0.0/16
• ローカル DNS サーバーはパブリック IP として構成されています (8.8.8.8)
• DNS サーバーの IP アドレスパラメータは無効になっており、DNS サーバの IP アドレスは指定されていません

この例では、クライアントは 8.8.8.8 のパブリック DNS サーバーを使用します。en0 経由の 8.8.8.8 への静的ルートは存在しないため、DNS リクエストは VPN トンネルを通過します。クライアント VPN エンドポイントがインターネットにアクセスできない場合、DNS サーバーに到達できず、クエリがタイムアウトします。

$ cat /etc/resolv.conf | grep nameservernameserver 8.8.8.8
$ netstat -nr -f inet | grep -E 'utun1|8.8.8.8'0/1                192.168.0.1      UGSc            5        0   utun1

$ dig amazon.com(...)
;; connection timed out; no servers could be reached

シナリオ 2: 「DNS サーバー IP アドレス」パラメータが有効になっているスプリットトンネル

例

• クライアントの IPv4 CIDR: 192.168.0.0/16
• クライアント VPN エンドポイントの Amazon VPC CIDR: 10.123.0.0/16
• DNS サーバーの IP アドレスパラメータは有効になっており、10.10.1.228 と 10.10.0.43 (Route 53 リゾルバーのインバウンドエンドポイント) に設定されています
• リゾルバーエンドポイントは、トランジットゲートウェイから接続された Amazon VPC (10.10.0.0/16) に配置されています
• Amazon VPC には Route 53 プライベートホストゾーン (example.local) があります
• DNS 解決と DNS ホスト名が有効になっています

このクライアント VPN は split-tunnel モードで設定されています。クライアント VPN ルートテーブルには、次のものが含まれます。

$ netstat -nr -f inet | grep utun1(...)10.10/16           192.168.0.1        UGSc            2        0   utun1 # Route 53 Resolver inbound endpoints VPC CIDR
10.123/16          192.168.0.1        UGSc            0        0   utun1 # Client VPN VPC CIDR
(...)

この例では、DNS サーバー IP アドレスパラメータが有効になっています。10.10.1.228 と 10.10.0.43 が DNS サーバーとして設定されています。クライアントが VPN トンネルを確立すると、DNS サーバーのパラメータがエンドユーザーのホストマシンにプッシュされます。

$ cat /etc/resolv.conf | grep nameservernameserver 10.10.1.228 # Primary DNS server nameserver 10.10.0.43 # Secondary DNS server

クライアントマシンは、VPN トンネルを経由してクライアント VPN VPC に送信される DNS クエリを発行します。次に、DNS リクエストはトランジットゲートウェイ経由で Route 53 Resolver のインバウンドエンドポイントに転送されます。ドメイン名が IP アドレスに解決されると、アプリケーショントラフィックも VPN トンネルを通過するようになります。このフローは、解決された宛先 IP アドレスがクライアント VPN エンドポイントのルートテーブル内のルートと一致する限り維持されます。

この構成では、エンドユーザーは標準の DNS 解決を使用する外部ドメイン名を解決できます。Route 53 Resolver のインバウンドエンドポイントを含む Amazon VPC に関連付けられた、プライベートホストゾーン内のレコードも解決できます。

$ dig amazon.com;; ANSWER SECTION:amazon.com.        8    IN    A    176.32.103.205
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig test.example.local # Route 53 private hosted zone record ;; ANSWER SECTION:
test.example.local. 10 IN A 10.123.2.1
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig ec2.ap-southeast-2.amazonaws.com # VPC interface endpoint to EC2 service in Route 53 Resolver VPC;; ANSWER SECTION:
ec2.ap-southeast-2.amazonaws.com. 60 IN    A    10.10.0.33
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com # EC2 instance public DNS hostname running in Route 53 Resolver VPC;; ANSWER SECTION:
ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com. 20 IN A 10.10.1.11
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)