Y_Yamashitaのブログ

勉強したことのアウトプット・メモが中心。記事の内容は個人の見解であり、所属組織を代表するものではありません。

AWS Client VPNとDHCPオプションセットのDNS設定はどちらが優先されるのか？

AWS Client VPN AWS Amazon VPC

最近、AWS Client VPNのDNS設定について色々と調べていました。その際、「VPCに疑似クライアントを用意して、DNS設定を色々いじって検証してみようかな」と考えたのですが、そこでふと、「VPCではDHCPオプションセットでDNSの設定をしているから、その設定が影響して上手く検証できないのでは。。？」と思い至りました。そのため、まずはDHCPオプションセットと、AWS Client VPNのDNS設定の力比べをしてみることにしました。

通常、VPCのリソースから、異なるVPCのAWS ClientVPNエンドポイントにVPN接続することはあまり無いと思います。そのため、DHCPオプションセットとClient VPNのDNS設定が戦う事も無いでしょう。生息地の違うトラとライオンが戦うことがないのと同様です。 今回の記事は、そんな夢のカード(？)を色々な条件で戦わせてみた記録となります。

ザックリ前提知識

AWS Client VPNにはDNSサーバーの設定があり、VPN接続したクライアントが名前解決に使用するDNSサーバーを指定することが出来ます。
一方で、VPCにはDHCPオプションセットという項目があり、VPC内のリソースが名前解決に使用するDNSサーバーを指定することが出来ます。
そのため、VPC内のリソースがAWS Client VPNにVPN接続した場合、2つの異なる設定でDNSサーバーを指定されることになります。その際にどちらが優先されるのかを確認するのが、本記事の主旨です。

はじめに結論

夢のカードとか言いながらいきなり結論を書いてしまいますが、DNS設定については、以下の順で優先されました。

  1. OS上の設定
  2. DHCPオプションセット
  3. AWS Client VPN

残念ながら、AWS Client VPNのDNS設定は最弱のようでした。DHCPオプションセットの方が優先されるため、VPCでClient VPNのクライアント側を疑似するのは少々やりにくかったです。

動作検証

ここからは、真面目に動作検証の内容をお届けします。

構成概要

構成概要は以下です。

  • クライアントVPN VPCと疑似オンプレVPCを用意します。
  • クライアントVPN VPCにAWS Client VPNを用意します。
  • 疑似オンプレVPCにEC2 (Amazon Linux2023) を用意し、openvpnをインストールして、VPN接続を行います。
  • 双方のVPCにALBを設置して、固定レスポンスを返すように設定します。
  • プライベートホストゾーンを2つ用意し、それぞれのALBのCNAMEレコードを設定します。（今思えば、別にエイリアスレコードで良かった。。）
  • 疑似クライアントが、プライベートホストゾーンのDNS名を使って、双方のALBに同時にアクセスできるようにすることを目指します。

その他の前提条件

Client VPNではスプリットトンネルをオンにします。オフにすると、全ての通信がVPNに向いてしまい、疑似オンプレVPCのALBにアクセスできなくなってしまうためです。 また、どちらのVPCでも、enableDnsHostnames と enableDnsSupport の両方を trueにします。プライベートホストゾーンを使用するのに必要なためです。

DNS設定パターン毎の検証結果

ここからは、DHCPオプションセット、Client VPN、OSのDNS設定を変えたり、プライベートホストゾーンを関連付けるVPCを変えたりしながら、名前解決の挙動がどう変わるのか確認していきます。

パターン1（DHCPオプションセット：Default、Client VPN：DNS設定なし、OS：Default）

パターン1は全てデフォルトの設定です。Client VPNのデフォルト設定では、DNS設定は無しになっています。その場合、クライアント端末は、VPN接続前に利用していたDNSサーバーをそのまま利用します。

つまり、疑似クライアントは、疑似オンプレVPCのRoute 53 Resolverを利用することが想定されます。 そのため、2つのプライベートホストゾーンを両方とも疑似オンプレVPCと関連付けます。

どちらのALBも、デフォルトのDNS名（internal-xxxx.ap-northeast-1.elb.amazonaws.com）に加えて、プライベートホストゾーンに設定したDNS名（alb.yamashita-test-20250429-xxxxx.com）でもアクセス出来ることが期待されます。

それでは、疑似クライアントでVPN接続を行います。接続後も操作が出来るように、末尾に&をつけてバックグラウンドで動作させます。

[ssm-user@ip-10-0-0-29 openvpn]$ sudo openvpn --config clientvpn-test.client.com.ovpn &
[1] 26902
[ssm-user@ip-10-0-0-29 openvpn]$ 2025-04-29 13:13:06 OpenVPN 2.6.12 x86_64-amazon-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2025-04-29 13:13:06 library versions: OpenSSL 3.2.2 4 Jun 2024, LZO 2.10
2025-04-29 13:13:06 TCP/UDP: Preserving recently used remote address: [AF_INET]54.168.48.30:443
2025-04-29 13:13:06 Socket Buffers: R=[212992->212992] S=[212992->212992]
2025-04-29 13:13:06 UDPv4 link local: (not bound)
2025-04-29 13:13:06 UDPv4 link remote: [AF_INET]54.168.48.30:443
2025-04-29 13:13:06 TLS: Initial packet from [AF_INET]54.168.48.30:443, sid=c3d1dcab bc14a0f7
2025-04-29 13:13:06 VERIFY OK: depth=1, CN=clientvpn-test
2025-04-29 13:13:06 VERIFY KU OK
2025-04-29 13:13:06 Validating certificate extended key usage
2025-04-29 13:13:06 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2025-04-29 13:13:06 VERIFY EKU OK
2025-04-29 13:13:06 VERIFY X509NAME OK: CN=clientvpn-test.server.com
2025-04-29 13:13:06 VERIFY OK: depth=0, CN=clientvpn-test.server.com
2025-04-29 13:13:06 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2025-04-29 13:13:06 [clientvpn-test.server.com] Peer Connection Initiated with [AF_INET]54.168.48.30:443
2025-04-29 13:13:06 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2025-04-29 13:13:06 TLS: tls_multi_process: initial untrusted session promoted to trusted
2025-04-29 13:13:07 SENT CONTROL [clientvpn-test.server.com]: 'PUSH_REQUEST' (status=1)
2025-04-29 13:13:07 PUSH: Received control message: 'PUSH_REPLY,route 172.16.0.0 255.255.255.0,route-gateway 192.168.0.1,topology subnet,ping 1,ping-restart 20,echo,echo,echo,ifconfig 192.168.0.2 255.255.255.224,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
2025-04-29 13:13:07 OPTIONS IMPORT: --ifconfig/up options modified
2025-04-29 13:13:07 OPTIONS IMPORT: route options modified
2025-04-29 13:13:07 OPTIONS IMPORT: route-related options modified
2025-04-29 13:13:07 OPTIONS IMPORT: tun-mtu set to 1500
2025-04-29 13:13:07 net_route_v4_best_gw query: dst 0.0.0.0
2025-04-29 13:13:07 net_route_v4_best_gw result: via 10.0.0.1 dev ens5
2025-04-29 13:13:07 ROUTE_GATEWAY 10.0.0.1/255.255.255.224 IFACE=ens5 HWADDR=06:ce:04:36:56:ff
2025-04-29 13:13:07 TUN/TAP device tun0 opened
2025-04-29 13:13:07 net_iface_mtu_set: mtu 1500 for tun0
2025-04-29 13:13:07 net_iface_up: set tun0 up
2025-04-29 13:13:07 net_addr_v4_add: 192.168.0.2/27 dev tun0
2025-04-29 13:13:07 net_route_v4_add: 172.16.0.0/24 via 192.168.0.1 dev [NULL] table 0 metric -1
2025-04-29 13:13:07 Initialization Sequence Completed
2025-04-29 13:13:07 Data Channel: cipher 'AES-256-GCM', peer-id: 0
2025-04-29 13:13:07 Timers: ping 1, ping-restart 20
2025-04-29 13:13:07 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt

[ssm-user@ip-10-0-0-29 openvpn]$

問題なく接続できました。この状態で、名前解決とアクセス確認を行います。

[ssm-user@ip-10-0-0-29 openvpn]$ nslookup alb.yamashita-test-20250429-vpnvpc.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
alb.yamashita-test-20250429-vpnvpc.com  canonical name = internal-clientvpnalb-1301670922.ap-northeast-1.elb.amazonaws.com.
Name:   internal-clientvpnalb-1301670922.ap-northeast-1.elb.amazonaws.com
Address: 172.16.0.75
Name:   internal-clientvpnalb-1301670922.ap-northeast-1.elb.amazonaws.com
Address: 172.16.0.38

[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ nslookup alb.yamashita-test-20250429-onpre.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
alb.yamashita-test-20250429-onpre.com   canonical name = internal-onpremalb-1015627341.ap-northeast-1.elb.amazonaws.com.
Name:   internal-onpremalb-1015627341.ap-northeast-1.elb.amazonaws.com
Address: 10.0.0.77
Name:   internal-onpremalb-1015627341.ap-northeast-1.elb.amazonaws.com
Address: 10.0.0.61

[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ curl http://alb.yamashita-test-20250429-vpnvpc.com
This is Client VPN side ALB.
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ curl http://alb.yamashita-test-20250429-onpre.com
This is on-premises side ALB.
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$

名前解決、アクセスともに出来ました。

パターン2（DHCPオプションセット：Default、Client VPN：172.16.0.2、OS：Default）

続いて、DHCPオプションセットとOS設定はデフォルト設定、Client VPNは172.16.0.2（クライアントVPN VPCのRoute 53 Resolver）を設定しました。動作検証前は、「VPN接続前は10.0.0.2を参照して、VPN接続後は172.16.0.2を参照するようになるのでは？」と思っていました。そのため、プライベートホストゾーンをクライアントVPN VPCと関連付けました。

VPN接続後は、クライアントVPN側のRoute 53 Resolverを使ってくれそうなイメージ

それでは、VPN接続したうえで、名前解決とアクセス確認を行います。（ここからは、VPN接続のログは省略します）

[ssm-user@ip-10-0-0-29 openvpn]$ nslookup alb.yamashita-test-20250429-vpnvpc.com
Server:         10.0.0.2
Address:        10.0.0.2#53

** server can't find alb.yamashita-test-20250429-vpnvpc.com: NXDOMAIN

[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ nslookup alb.yamashita-test-20250429-onpre.com
Server:         10.0.0.2
Address:        10.0.0.2#53

** server can't find alb.yamashita-test-20250429-onpre.com: NXDOMAIN

[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ curl http://alb.yamashita-test-20250429-vpnvpc.com
curl: (6) Could not resolve host: alb.yamashita-test-20250429-vpnvpc.com
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ curl http://alb.yamashita-test-20250429-onpre.com
curl: (6) Could not resolve host: alb.yamashita-test-20250429-onpre.com
[ssm-user@ip-10-0-0-29 openvpn]$

VPN接続後も、引き続きDHCPオプションセットの設定が優先されて、疑似オンプレVPCのRoute 53 Resolverにクエリを投げています。そのため、名前解決に失敗し、アクセスも出来なくなっています。

なお、この状態でもALBのデフォルトのDNS名は名前解決できます（ALBのDNS名はパブリックに名前解決可能なため）。試しに名前解決とアクセスを試みます。

[ssm-user@ip-10-0-0-29 openvpn]$ nslookup internal-OnPremALB-1015627341.ap-northeast-1.elb.amazonaws.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
Name:   internal-OnPremALB-1015627341.ap-northeast-1.elb.amazonaws.com
Address: 10.0.0.61
Name:   internal-OnPremALB-1015627341.ap-northeast-1.elb.amazonaws.com
Address: 10.0.0.77

[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ nslookup internal-ClientVPNALB-1301670922.ap-northeast-1.elb.amazonaws.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
Name:   internal-ClientVPNALB-1301670922.ap-northeast-1.elb.amazonaws.com
Address: 172.16.0.38
Name:   internal-ClientVPNALB-1301670922.ap-northeast-1.elb.amazonaws.com
Address: 172.16.0.75

[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ curl http://internal-clientvpnalb-1301670922.ap-northeast-1.elb.amazonaws.com
This is Client VPN side ALB.
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ curl http://internal-onpremalb-1015627341.ap-northeast-1.elb.amazonaws.com
This is on-premises side ALB.
[ssm-user@ip-10-0-0-29 openvpn]$

問題なく名前解決とアクセスが出来ました。VPN接続自体は出来ており、ネットワークの疎通性はあることが確認できました。

というわけで、パターン2の実際の動作は下図のようになりました。どうやら、Client VPNのDNS設定よりも、DHCPオプションセットのDNS設定の方が優先されるようです。

DNSサーバーが切り替わらず、名前解決に失敗

パターン3（DHCPオプションセット：172.16.0.2、10.0.0.2 Client VPN：172.16.0.2、OS：Default）

今度は、DHCPオプションセットでも172.16.0.2をDNSサーバーに設定しました。ただし、このままだとVPN接続前に全く名前解決が出来なくなりそうなので、セカンダリDNSサーバーとして10.0.0.2も設定しました。これならば、DNS接続後にクライアントVPN側のRoute 53 Resolverで名前解決できるのではないでしょうか？

これならいけるのでは？

期待に胸を膨らませつつ、名前解決とアクセス確認を行ってみます。

[ssm-user@ip-10-0-0-29 openvpn]$ nslookup alb.yamashita-test-20250429-vpnvpc.com
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
Server:         10.0.0.2
Address:        10.0.0.2#53

** server can't find alb.yamashita-test-20250429-vpnvpc.com: NXDOMAIN

[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ nslookup alb.yamashita-test-20250429-onpre.com
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
Server:         10.0.0.2
Address:        10.0.0.2#53

** server can't find alb.yamashita-test-20250429-onpre.com: NXDOMAIN

[ssm-user@ip-10-0-0-29 openvpn]$

あれ、DNSサーバーにアクセスできないですね。。VPN接続に失敗しているのでしょうか？試しにALBのデフォルトDNS名でも試してみます。

[ssm-user@ip-10-0-0-29 openvpn]$ nslookup internal-OnPremALB-1015627341.ap-northeast-1.elb.amazonaws.com
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
Name:   internal-OnPremALB-1015627341.ap-northeast-1.elb.amazonaws.com
Address: 10.0.0.61
Name:   internal-OnPremALB-1015627341.ap-northeast-1.elb.amazonaws.com
Address: 10.0.0.77
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out

[ssm-user@ip-10-0-0-29 openvpn]$ nslookup internal-ClientVPNALB-1301670922.ap-northeast-1.elb.amazonaws.com
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
Name:   internal-ClientVPNALB-1301670922.ap-northeast-1.elb.amazonaws.com
Address: 172.16.0.38
Name:   internal-ClientVPNALB-1301670922.ap-northeast-1.elb.amazonaws.com
Address: 172.16.0.75
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out
;; communications error to 172.16.0.2#53: timed out

[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ curl http://internal-clientvpnalb-1301670922.ap-northeast-1.elb.amazonaws.com
This is Client VPN side ALB.
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ curl http://internal-onpremalb-1015627341.ap-northeast-1.elb.amazonaws.com
This is on-premises side ALB.
[ssm-user@ip-10-0-0-29 openvpn]$

172.16.0.2のDNSサーバーにはアクセスできないので、代わりにセカンダリDNSサーバーが応答します。ただ、クライアントVPN VPCのALB自体にはアクセスできているので、VPN接続が出来ていないわけでは無さそうです。これはどうしたことでしょうか。

ここで、疑似クライアントのifconfigとルートテーブルを見てみます。

[ssm-user@ip-10-0-0-29 openvpn]$ ifconfig
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9001
        inet 10.0.0.29  netmask 255.255.255.224  broadcast 10.0.0.31
        inet6 fe80::4ce:4ff:fe36:56ff  prefixlen 64  scopeid 0x20<link>
        ether 06:ce:04:36:56:ff  txqueuelen 1000  (Ethernet)
        RX packets 3200  bytes 1102944 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2876  bytes 358412 (350.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 12  bytes 1020 (1020.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 1020 (1020.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.0.130  netmask 255.255.255.224  destination 192.168.0.130
        inet6 fe80::fab2:db4b:7012:869a  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 4  bytes 405 (405.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14  bytes 832 (832.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[ssm-user@ip-10-0-0-29 openvpn]$ ip route
default via 10.0.0.1 dev ens5 proto dhcp src 10.0.0.29 metric 512
10.0.0.0/27 dev ens5 proto kernel scope link src 10.0.0.29 metric 512
10.0.0.1 dev ens5 proto dhcp scope link src 10.0.0.29 metric 512
10.0.0.2 dev ens5 proto dhcp scope link src 10.0.0.29 metric 512
172.16.0.0/24 via 192.168.0.129 dev tun0
172.16.0.2 via 10.0.0.1 dev ens5 proto dhcp src 10.0.0.29 metric 512
192.168.0.128/27 dev tun0 proto kernel scope link src 192.168.0.130
[ssm-user@ip-10-0-0-29 openvpn]$
[ssm-user@ip-10-0-0-29 openvpn]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ip-10-0-0-1.ap- 0.0.0.0         UG    512    0        0 ens5
ip-10-0-0-0.ap- 0.0.0.0         255.255.255.224 U     512    0        0 ens5
ip-10-0-0-1.ap- 0.0.0.0         255.255.255.255 UH    512    0        0 ens5
ip-10-0-0-2.ap- 0.0.0.0         255.255.255.255 UH    512    0        0 ens5
ip-172-16-0-0.a ip-192-168-0-12 255.255.255.0   UG    0      0        0 tun0
ip-172-16-0-2.a ip-10-0-0-1.ap- 255.255.255.255 UGH   512    0        0 ens5
ip-192-168-0-12 0.0.0.0         255.255.255.224 U     0      0        0 tun0
[ssm-user@ip-10-0-0-29 openvpn]$

172.16.0.0向けのルートはVPNトンネルに向いていますが、172.16.0.2のネクストホップは10.0.0.1になっています。

10.0.0.1はVPCルーターのアドレスです。VPCでは、ネットワークアドレス+1のアドレスがVPCルーター用として予約されています。VPC内のリソースが他リソースと通信する場合は、VPCルーターを経由して通信を行います。（普段はあまり意識することはありませんが）

そして、DHCPオプションセットで設定したDNSサーバーと通信する際は、Client VPNのトンネルではなく、VPCルーターに通信が向くようになっていました。そのため、DNSサーバーにクエリが到達せず、名前解決が出来なくなっていました。

まとめると、下図のような挙動になりました。VPCルーターからは172.16.0.2に到達できず、セカンダリDNSの10.0.0.2はプライベートホストゾーンを名前解決できず、結局名前解決には失敗しました。

DHCPオプションセットを変えても、DNSクエリがVPNトンネルに入らず失敗

パターン4（DHCPオプションセット：設定なし Client VPN：172.16.0.2、OS：Default）

さて、どうにもDHCPオプションセットの壁を越えることができないため、いっそDHCPオプションセットを無しにしてみます。これならどうでしょうか。それ以前に、DHCPオプションセットを無しにした状態で、セッションマネージャーに接続できるのでしょうか。

今度こそいけるのでは？

とりあえず試してみます。

[ssm-user@ip-10-0-0-26 openvpn]$ nslookup alb.yamashita-test-20250429-vpnvpc.com
Server:         169.254.169.253
Address:        169.254.169.253#53

** server can't find alb.yamashita-test-20250429-vpnvpc.com: NXDOMAIN

[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$ nslookup alb.yamashita-test-20250429-onpre.com
Server:         169.254.169.253
Address:        169.254.169.253#53

** server can't find alb.yamashita-test-20250429-onpre.com: NXDOMAIN

[ssm-user@ip-10-0-0-26 openvpn]$

セッションマネージャーでの接続は出来ましたが、名前解決には失敗しました。そしてDNSサーバーのアドレスが「169.254.169.253」になっています。

実はこのアドレスもRoute 53 Resolverのアドレスです。VPC に DHCP オプションセットが設定されていない場合、Nitro System上に構築されたEC2インスタンスでは、169.254.169.253 をデフォルトのドメインネームサーバーとして設定します。
詳細は以下公式ページを参照ください。

docs.aws.amazon.com

docs.aws.amazon.com

疑似オンプレVPCはプライベートホストゾーンと関連付けていないため、名前解決はできませんでした。

ここで、再び疑似クライアントのルートテーブルを見てみます。

[ssm-user@ip-10-0-0-26 openvpn]$ ip route
default via 10.0.0.1 dev ens5 proto dhcp src 10.0.0.26 metric 512
10.0.0.0/27 dev ens5 proto kernel scope link src 10.0.0.26 metric 512
10.0.0.1 dev ens5 proto dhcp scope link src 10.0.0.26 metric 512
169.254.169.253 via 10.0.0.1 dev ens5 proto dhcp src 10.0.0.26 metric 512
172.16.0.0/24 via 192.168.0.161 dev tun0
192.168.0.160/27 dev tun0 proto kernel scope link src 192.168.0.162
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ip-10-0-0-1.ap- 0.0.0.0         UG    512    0        0 ens5
ip-10-0-0-0.ap- 0.0.0.0         255.255.255.224 U     512    0        0 ens5
ip-10-0-0-1.ap- 0.0.0.0         255.255.255.255 UH    512    0        0 ens5
169.254.169.253 ip-10-0-0-1.ap- 255.255.255.255 UGH   512    0        0 ens5
ip-172-16-0-0.a ip-192-168-0-16 255.255.255.0   UG    0      0        0 tun0
ip-192-168-0-16 0.0.0.0         255.255.255.224 U     0      0        0 tun0
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$

やはり、169.254.169.253のネクストホップはVPCルーター(10.0.0.1)になっていますね。VPNトンネルには通信は向いていませんでした。

まとめると、パターン4の実際の動作は下図のようになりました。パターン2とほとんど同じですね。

これでもダメなのか。。。

パターン5（DHCPオプションセット：設定なし Client VPN：172.16.0.2、OS：172.16.0.2）

というわけで、最終手段として、OSのDNS設定を直接編集します。

以下の記事の内容に従い、/etc/systemd/resolved.conf を編集します。

repost.aws

[ssm-user@ip-10-0-0-26 openvpn]$ sudo vim /etc/systemd/resolved.conf
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$ sudo cat /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
DNS=172.16.0.2
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=yes
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$ sudo systemctl restart systemd-resolved.service
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$ sudo tail /etc/resolv.conf
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 172.16.0.2
nameserver 169.254.169.253
search .
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$


名前解決とアクセスをしてみます。

[ssm-user@ip-10-0-0-26 openvpn]$ nslookup alb.yamashita-test-20250429-vpnvpc.com
Server:         172.16.0.2
Address:        172.16.0.2#53

Non-authoritative answer:
alb.yamashita-test-20250429-vpnvpc.com  canonical name = internal-clientvpnalb-41888842.ap-northeast-1.elb.amazonaws.com.
Name:   internal-clientvpnalb-41888842.ap-northeast-1.elb.amazonaws.com
Address: 172.16.0.61
Name:   internal-clientvpnalb-41888842.ap-northeast-1.elb.amazonaws.com
Address: 172.16.0.69

[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$ nslookup alb.yamashita-test-20250429-onpre.com
Server:         172.16.0.2
Address:        172.16.0.2#53

Non-authoritative answer:
alb.yamashita-test-20250429-onpre.com   canonical name = internal-onpremalb-1107595459.ap-northeast-1.elb.amazonaws.com.
Name:   internal-onpremalb-1107595459.ap-northeast-1.elb.amazonaws.com
Address: 10.0.0.69
Name:   internal-onpremalb-1107595459.ap-northeast-1.elb.amazonaws.com
Address: 10.0.0.59

[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$ curl alb.yamashita-test-20250429-vpnvpc.com
This is Client VPN side ALB.
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$ curl alb.yamashita-test-20250429-onpre.com
This is on-premises side ALB.
[ssm-user@ip-10-0-0-26 openvpn]$
[ssm-user@ip-10-0-0-26 openvpn]$


問題なく出来ました。ルートテーブルも見てみます。

[ssm-user@ip-10-0-0-26 bin]$ ip route
default via 10.0.0.1 dev ens5 proto dhcp src 10.0.0.26 metric 512
10.0.0.0/27 dev ens5 proto kernel scope link src 10.0.0.26 metric 512
10.0.0.1 dev ens5 proto dhcp scope link src 10.0.0.26 metric 512
169.254.169.253 via 10.0.0.1 dev ens5 proto dhcp src 10.0.0.26 metric 512
172.16.0.0/24 via 192.168.0.1 dev tun0
192.168.0.0/27 dev tun0 proto kernel scope link src 192.168.0.2
[ssm-user@ip-10-0-0-26 bin]$
[ssm-user@ip-10-0-0-26 bin]$
[ssm-user@ip-10-0-0-26 bin]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ip-10-0-0-1.ap- 0.0.0.0         UG    512    0        0 ens5
ip-10-0-0-0.ap- 0.0.0.0         255.255.255.224 U     512    0        0 ens5
ip-10-0-0-1.ap- 0.0.0.0         255.255.255.255 UH    512    0        0 ens5
169.254.169.253 ip-10-0-0-1.ap- 255.255.255.255 UGH   512    0        0 ens5
ip-172-16-0-0.a ip-192-168-0-1. 255.255.255.0   UG    0      0        0 tun0
ip-192-168-0-0. 0.0.0.0         255.255.255.224 U     0      0        0 tun0
[ssm-user@ip-10-0-0-26 bin]$

172.16.0.2がVPCルーターに向くこともなく、172.16.0.0/24がすべてVPNトンネルに向いていますね。

というわけで、VPN接続先のDNSサーバーを参照させるのに大変苦労してしまいましたが、何とか最終的に上手くいきました。

はじめからこうすれば良かったんや。。。

終わりに

以上、夢の対戦の実況中継でした。何とかClient VPNのDNS設定を勝たせようと、色々と策を講じましたが、どれも通用しませんでした。結局、第3勢力のOS設定が最強でしたし。
冗談はさておき、今回の検証は実務で使うような構成ではないので、正直あまり役立つ知見にはならなかったかもしれません。それでも、DHCPオプションセットやVPCルーターの挙動など、普段あまり意識しない細かい動きを理解する事が出来たので、個人的には良い勉強の機会になりました。

おまけ

今回の検証にあたり、色々と外部の記事を参考にさせていただきました。それらの記事を紹介します。たぶんこの項目が本ブログで一番役立つと思いますw

VPCルーターについては以下のNRIネットコムさんの記事で分かりやすく説明されていました。

tech.nri-net.com

Amazon Linux 2023のDNS設定の変更については、以下のクラメソさんの記事で大変詳しく懇切丁寧に説明されていました。

dev.classmethod.jp

AWS Client VPNのDNS設定の仕様については、以下のクラメソさんの記事が非常に分かりやすかったです。

dev.classmethod.jp

dev.classmethod.jp

AWS Client VPN全般の仕様については、以下のクラメソさん、サバワさんの記事が非常に丁寧で分かりやすかったです。

dev.classmethod.jp

dev.classmethod.jp

blog.serverworks.co.jp

今回のブログは以上です。少しでも参考になることがあれば幸いです。