AWS Client VPN に接続した際にクライアント端末のルートテーブルがどう変わるかをまとめてみた（macOS）
コンバンハ、千葉（幸）です。
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/1と128.0.0.0/1に分かれるのが常かは不明です。
やってみた
今回は以下の条件です。
| 項目 | 値 |
|---|---|
| スプリットトンネル | 有効 |
| クライアント IPv4 CIDR | 10.243.0.0/22 |
| 採番されたクライアントIPアドレス | 10.243.0.7 |
| クライアントVPNルートテーブルの宛先CIDR | 多数 |
「クライアント IPv4 CIDR」は一覧画面では「クライアントCIDR」として表示されます。
採番されたクライアント IP アドレスは「接続」タブから確認しました。
クライアント VPN のルートテーブルはこのように多くの宛先が指定されています。
接続前のルートテーブルの状況は以下の通り。クライアントデバイスがもともと持っている 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 の対象です。
過去の結果から確認する
試行例が一つだけだと心もとないので、過去のエントリから引っ張ってきます。
まずは以下のエントリからです。
スプリットトンネル有効の場合
以下の条件です。
| 項目 | 値 |
|---|---|
| スプリットトンネル | 有効 |
| クライアント 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 接続前後のクライアントデバイスのルートテーブルの差分が以下です。（左が接続後）
クライアント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 接続前後のクライアントデバイスのルートテーブルの差分が以下です。（左が接続後）
クライアント VPN ルートテーブル の宛先が追加されていないことが分かります。
過去の結果から確認する 2
もう一つ引っ張ってこれる例があったので引用します。とは言えあまり構成が変わらないので結果も変わり映えしません。
スプリットトンネル有効の場合
以下の条件です。
| 項目 | 値 |
|---|---|
| スプリットトンネル | 有効 |
| クライアント IPv4 CIDR | 172.16.0.0/16 |
| 採番されたクライアントIPアドレス | 172.16.0.130 |
| クライアントVPNルートテーブルの宛先CIDR | 10.0.0.0/16 |
AWS Client VPN 接続前後のクライアントデバイスのルートテーブルの差分が以下です。（左が接続後）
スプリットトンネル無効の場合
以下の条件です。
| 項目 | 値 |
|---|---|
| スプリットトンネル | 無効 |
| クライアント 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 接続時にクライアントデバイスのルートテーブルにどのような変更が加わるかをまとめてみました。
Windows 端末では試せていないので、macOS での例を記載しました。（そのうち誰かが書いてくれるんじゃないかな……という期待）
検証などで AWS Client VPN に頻繁に設定変更を加える場合、期待される動作をあらかじめ押さえておくことで不要な手戻りを避けることができるかと思います。お役に立てば幸いです。
以上、 チバユキ (@batchicchi) がお送りしました。
