VPN Gateway でSSL-VPN を使用する#3 ネットワークの話

以前に書いた“VPN Gateway でSSL-VPN を使用する#3 ネットワークの話”をInternational サイトを前提に書き直しました。テストも再度実施しています。

Alibaba Cloud VPN Gateway についてネットワーク視点で色々と確認した結果をまとめました。 1つはリモートネットワーク側からローカルネットワークへ通信できるのか、その時のリモート側のIPアドレスはどう見えるのか。 2つ目はスプリットトンネルされるのかどうかの確認です。あとはMTUなど。

1. Alibaba Cloud からVPNクライアントへの通信

前回は日本サイト契約のAlibaba Cloud VPN Gateway で行ったテストをInternational サイトのVPN Gateway で再度確認していきます。

確認したいことは通信の起点がAlibaba Cloud ECS の場合にその通信が許可されるのか、されないのか、です。

前回までの記事でAlibaba Cloud VPN Gateway のSSL-VPN機能を利用することで、オンプレミスのクライアントからAlibaba Cloud 上のECSへ通信出来ることはすでに確認出来ています。

今回は逆方向の通信を確認します。

  1. ECS からVPNクライアントへのPing
  2. VPN クライアントでのパケットの見え方

1.1. ECS からVPN クライアントへのPing

Alibaba Cloud ECS 上のUbuntu からVPNクライアントへPing を実行します。

1.1.1. VPNでアサインされたIPアドレス宛のPing

まずはVPNから割り当てられた”192.168.1.10″への通信をテストします。

応答があります。 当たり前では?と思われるかもしれませんが、VPN サーバの仕様によっては既定でこの方向の通信をブロックすることもあるので今回確認しました。

1.1.2. Real IP アドレス宛のPing

参考までにVPNクライアントのReal IP (Windows 10 が実際のもっているIPアドレス)とPublic IP (Windows 10 からインターネットにアクセスする際のIP。ISPからルータに付与されたIP)への通信もテストしてみます。

まずは、Real IP 宛のPingからテストします。 応答はありません。

試しにAlibaba Cloud のVPC のroute table に192.168.0.0/24 (オンプレミス側の物理PCの実IPのサブネット)のルートを追加します。 これでVPC の vRouter は192.168.0.0/24 宛てのパケットをVPN Gateway に転送します。

Alibaba Cloud ECS からVPNクライアントの実IP(192.168.0.49)へPing を実行します。 結果、通信は行えませんでした。

パケットキャプチャでもパケットも届いていないのでおそらくVPN Gateway のところで192.168.0.0/24 宛てのパケットのルートを判断できず、VPC のvRouter に戻し、その繰り返しで “Time to live exceeded” になっています。

(以下のスクリーンショットのNo.1-6のICMPはVPNで割り当てた 192.168.1.10宛てのものでこちらは応答があるのが正しい動き)

1.2. VPN クライアントでのパケットの見え方

VPN クライアント側でパケットキャプチャを行い、IPアドレスのSource がどのIPアドレスとなっているのか確認します。 VPN GatewayでSource NATがかかるとVPN Gateway がもつIPアドレスになりますし、NATされなければECS のもつプライベートIPアドレスになるはずです。

VPN クライアント側から見える送信元IPアドレスは 172.24.203.118 です。 これは Alibaba Cloud のVPC 上のECS のプライベートIPアドレスです。 つまり、途中でNATなどで変換されることなくVPN クライアントとECSは通信を行うことが確認できました。

2. VPN 接続中のスプリット

SSL-VPN でトンネルを確立後、Alibaba Cloud 宛ての通信は、トンネル側にルーティングされることはわかっています。 それ以外の通信はどうなるのか確認します。

2.1. ルートテーブルの確認

まずは”route print” コマンドでVPNクライアント側のルートテーブルを確認します。

上記から

  • Alibaba Cloud 宛て(172.24.0.0/16)は 192.168.1.9 (VPN Gateway のもつIPでしょう)へルーティング
  • VPN Gateway から割り当てられるクライアント用のサブネット(192.168.1.0/24)宛ての通信も 192.168.1.9 (VPN Gateway のもつIPでしょう)へルーティング
  • それ以外はもともとのReal IP のDefault の192.168.0.1 へルーティング

となることがわかります。

従って、VPN トンネルを確立した状態でもスプリットしてインターネットにアクセスすることが出来るということです。

2.2. 通信テスト

インターネット宛ての通信はVPN トンネルを通らずにスプリットして直接アクセスすることになるのか確認します。

APNIC のサイト https://wq.apnic.net/static/search.html にアクセスすると、送信元のIPアドレスを表示してくれます。 118.83.XXX.XXX と私が使用しているISP のグローバルIPアドレスであることが確認できます。

2.3. Alibaba Cloud 側の設定

どの宛先がVPN トンネルに向かうのか、Alibaba Cloud VPN Gateway のLocal Network で定義します。

試しに Local Networkに”10.0.0.0/8”を追加します。

一度、VPNを切断し、接続します。(一度切断しないとルーティングは変わらず)

VPN クライアント側のルーティングを確認します。 追加した”10.0.0.0/8″はVPN Gateway(192.168.1.9)へルーティングするようになりました。

この設定の使いどころは、Alibaba Cloud 側で複数のVPC を接続しているケースです。 今回はリージョン間を接続する Cloud Enterprise Network やExpress Connect の環境が手元に無いためテストは行いませんが、以下のように上海リージョンのVPC のCIDR が”10.0.0.0/8″ の場合、VPN Gateway 側のローカルネットワークに”10.0.0.0/8″ を追加することで上海まで通信することが可能になります。

2.4. スプリットしたくない場合

すべての通信をAlibaba Cloud 側にルーティングしたい場合、一般的なVPNの場合、VPNクライアント側の機能や設定になります。

クライアント側での設定方法を探したのですが見つからず。

単純に考えると Alibaba Cloud VPN Gateway 側のLocal Network に定義したサブネットがVPN クライアント側のルート テーブルに追加されることから、Alibaba Cloud 側でLocal Network に0.0.0.0/0 を定義出来ればいけそうですが、そのような定義は出来ず。

あとは0.0.0.0/0 を使わずにすべてのグローバルIPアドレスを指定していくとどうなるか。 試しにVPN Gateway の SSL Server 設定でLocal Network に8.8.8.8/32 を定義します。

VPN クライアントを再接続して、ルートテーブルを確認します。 宛先ネットワークに”8.8.8.8/32″ でGateway は 192.168.1.5 のルートがVPNクライアント側に追加されました。

VPN クライアントから 8.8.8.8 へPing を実行します。 パケットキャプチャではVPNトンネルインターフェースにパケットを転送していることがわかります。

なお、8.8.8.8 へのPing の応答はありませんがこれは正しい動作です。 Alibaba Cloud 側では宛先 8.8.8.8 を処理する方法というかルートが無いためです。 VPN Gateway はパブリックIPを持っていますがそのIPアドレスでインターネット上のホストと通信するわけではありません。 VPC のvRouter としてもこのテスト環境では宛先8.8.8.8 を扱うルートをもっていないためです。  この話は色々と考えなければならないこと、どこを出口とするのか、があるのでこの記事ではここまでとします。

3.MTU

VPN Tunnel を通過できるMTU を確認しました。1500 です。 まあ IPsec ではなくTCP上のSSL/TLS なので当たり前といえば当たり前の結果ではあります。Pingによる確認結果は以下の通りです。

“-l” で1473を指定し、”-f” でDon’t Fragment を指定した場合のPing 実行結果は以下の通り。

サイズを1472 に指定した場合の結果は以下の通り。

4. まとめ

今回、以下のことがわかりました。

  • Alibaba Cloud 側からVPN クライアント側への通信は制限されていない
  • Alibaba Cloud とVPN クライアントはNATされずにそれぞれが持つプライベートIPアドレスで通信する
  • ルーティングを適宜変更(実際にはVPN Gateway のローカルネットワークの追加)することで直接接続していないAlibaba Cloud のVPC へも接続出来る
  • 基本はスプリットする動作でVPN Gateway で定義したLocal Network 宛ての通信のみをVPN Tunnel に転送する動作
  • VPNクライアントのReal IPアドレスのセグメントとVPNから割り当てるセグメントを同じにすると正しく通信できない(画面等での紹介していませんが確認済)

以上