AWS Client VPN に接続した際にクライアント端末のルートテーブルがどう変わるかをまとめてみた(macOS)

netstat -nr -f inet を何かと叩くあまねくみなさんへ。

コンバンハ、千葉(幸)です。

AWS Client VPN に接続した場合、netstat -nr -f inetで端末のルートテーブルを眺めることがあるかと思います。

接続前と接続後にどういった変化があるかを、備忘を兼ねてまとめてみました。

環境

  • macOS
  • AWS VPN Client 1.2.4

まとめ

以下のルートが増える。

# Destination Gateway
1 採番されたクライアントIPアドレス 採番されたクライアントIPアドレス
2 採番されたクライアントIPアドレスを含む/27のCIDR(※1) 採番されたクライアントIPアドレス

(※1)/27 で固定かは不明です。試した例ではすべて/27でした

スプリットトンネル有効の場合

#1,2に加えて以下が増える。

# Destination Gateway
3 クライアントVPNルートテーブルの宛先CIDR(※2) #2のDestinationの先頭のホストのIPアドレス

(※2)試した範囲では0.0.0.0/0は追加されませんでした。端末により挙動が異なる可能性はあります

スプリットトンネル無効の場合

#1,2に加えて以下が増える。

# Destination Gateway
4 クライアントVPNエンドポイントのグローバルIPアドレス クライアントデバイスのデフォルトゲートウェイ
5 0.0.0.0/1 #2のDestinationの先頭のホストのIPアドレス
6 128.0.0.0/1 #2のDestinationの先頭のホストのIPアドレス

0.0.0.0/0でなく0.0.0.0/1128.0.0.0/1に分かれるのが常かは不明です。

やってみた

今回は以下の条件です。

項目
スプリットトンネル 有効
クライアント IPv4 CIDR 10.243.0.0/22
採番されたクライアントIPアドレス 10.243.0.7
クライアントVPNルートテーブルの宛先CIDR 多数

「クライアント IPv4 CIDR」は一覧画面では「クライアントCIDR」として表示されます。

採番されたクライアント IP アドレスは「接続」タブから確認しました。

AWS_Client_VPN_Client_IP

クライアント VPN のルートテーブルはこのように多くの宛先が指定されています。

AWS_Client_VPN_Route_Table

接続前のルートテーブルの状況は以下の通り。クライアントデバイスがもともと持っている IP アドレスは192.168.0.14で、デフォルトゲートウェイは192.168.0.1です。

$ netstat -nr -f inet
Routing tables

Internet:
Destination        Gateway            Flags           Netif Expire
default            192.168.0.1        UGScg             en0
127                127.0.0.1          UCS               lo0
127.0.0.1          127.0.0.1          UH                lo0
169.254            link#6             UCS               en0      !
192.168.0          link#6             UCS               en0      !
192.168.0.1/32     link#6             UCS               en0      !
192.168.0.1        90:f3:5:ee:a2:bb   UHLWIir           en0   1174
192.168.0.10       0:fc:8b:6b:f4:9e   UHLWI             en0    981
192.168.0.14/32    link#6             UCS               en0      !
224.0.0/4          link#6             UmCS              en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI            en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI            en0
255.255.255.255/32 link#6             UCS               en0      !

AWS Client VPN に接続した後のルートテーブルは以下です。

$ netstat -nr -f inet
Routing tables

Internet:
Destination        Gateway            Flags           Netif Expire
default            192.168.0.1        UGScg             en0
10.63/16           10.243.0.1         UGSc            utun3
10.243/27          10.243.0.7         UGSc            utun3
10.243.0.7         10.243.0.7         UH              utun3
127                127.0.0.1          UCS               lo0
127.0.0.1          127.0.0.1          UH                lo0
169.254            link#6             UCS               en0      !
172.16/24          10.243.0.1         UGSc            utun3
172.16.8/24        10.243.0.1         UGSc            utun3
172.22/24          10.243.0.1         UGSc            utun3
172.27/24          10.243.0.1         UGSc            utun3
172.28/24          10.243.0.1         UGSc            utun3
172.29/24          10.243.0.1         UGSc            utun3
172.30/24          10.243.0.1         UGSc            utun3
172.31/24          10.243.0.1         UGSc            utun3
192.168.0          link#6             UCS               en0      !
192.168.0.1/32     link#6             UCS               en0      !
192.168.0.1        90:f3:5:ee:a2:bb   UHLWIir           en0   1145
192.168.0.10       0:fc:8b:6b:f4:9e   UHLWI             en0    862
192.168.0.14/32    link#6             UCS               en0      !
192.168.0.23       link#6             UHLWI             en0      !
224.0.0/4          link#6             UmCS              en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI            en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI            en0
255.255.255.255/32 link#6             UCS               en0      !

差分を比較すると以下の通りです。#3 では広範囲を囲っていますが、#1と#2に被らずかつ赤くハイライトされている部分のみが#3 の対象です。

AWS_Client_VPN_diff

過去の結果から確認する

試行例が一つだけだと心もとないので、過去のエントリから引っ張ってきます。

まずは以下のエントリからです。

スプリットトンネル有効の場合

以下の条件です。

項目
スプリットトンネル 有効
クライアント IPv4 CIDR 172.31.0.0/16
採番されたクライアントIPアドレス 172.31.0.130
クライアントVPNルートテーブルの宛先CIDR 192.168.0.0/16、0.0.0.0/0、8.8.8.8/32

AWS Client VPN 接続前後のクライアントデバイスのルートテーブルの差分が以下です。(左が接続後)

AWS_Client_VPN_Example-8040831

クライアントVPNルートテーブルの宛先として0.0.0.0/0が指定されていても、クライアントデバイスのルートテーブルには反映されません。

スプリットトンネル無効の場合

以下の条件です。

項目
スプリットトンネル 無効
クライアント IPv4 CIDR 172.31.0.0/16
採番されたクライアントIPアドレス 172.31.0.34
クライアントVPNルートテーブルの宛先CIDR 192.168.0.0/16、0.0.0.0/0、8.8.8.8/32

AWS Client VPN 接続前後のクライアントデバイスのルートテーブルの差分が以下です。(左が接続後)

AWS_Client_VPN_example

クライアント VPN ルートテーブル の宛先が追加されていないことが分かります。

過去の結果から確認する 2

もう一つ引っ張ってこれる例があったので引用します。とは言えあまり構成が変わらないので結果も変わり映えしません。

スプリットトンネル有効の場合

以下の条件です。

項目
スプリットトンネル 有効
クライアント IPv4 CIDR 172.16.0.0/16
採番されたクライアントIPアドレス 172.16.0.130
クライアントVPNルートテーブルの宛先CIDR 10.0.0.0/16

AWS Client VPN 接続前後のクライアントデバイスのルートテーブルの差分が以下です。(左が接続後)

AWS_Client_VPN_Example-8041295

スプリットトンネル無効の場合

以下の条件です。

項目
スプリットトンネル 無効
クライアント IPv4 CIDR 172.16.0.0/16
採番されたクライアントIPアドレス 172.16.0.130
クライアントVPNルートテーブルの宛先CIDR 10.0.0.0/16

AWS Client VPN 接続前後のクライアントデバイスのルートテーブルの差分が以下です。(左が接続後)

AWS_Client_VPN_Example-8041837

法則がわかりました。

終わりに

AWS Client VPN 接続時にクライアントデバイスのルートテーブルにどのような変更が加わるかをまとめてみました。

Windows 端末では試せていないので、macOS での例を記載しました。(そのうち誰かが書いてくれるんじゃないかな……という期待)

検証などで AWS Client VPN に頻繁に設定変更を加える場合、期待される動作をあらかじめ押さえておくことで不要な手戻りを避けることができるかと思います。お役に立てば幸いです。

以上、 チバユキ (@batchicchi) がお送りしました。

参考