[SoftEther VPN] なぜ SecureNAT を ON にしたらつながるようになったのか？

iPhone 5 と CentOS 間の L2TP/IPsec で上手く通信できない原因は VPN クライアントと VPN サーバーの IP アドレスの割り当てがなされていなかったことに主な原因がありました。

SecureNAT ＝仮想 DHCP サーバー＋仮想 NAT

これをまず確認しておきましょう。

VPN (L2TP/IPsec) の原理を考えてみると、まず VPN クライアントは VPN サーバーと L2TP/IPsec のトンネルを張ります。このトンネルを張る時に使われる IP アドレスはグローバル IP です。

VPN クライアントは iPhone 5 で
VPN サーバーは自宅に構築した CentOS 上で稼働させている SoftEther VPN サーバー

です。

iPhone 5 は、プロバイダー（ソフトバンク）のグローバル IP を使用し、
SoftEther VPN サーバー側は、自宅のインターネットプロバイダーのグローバル IP を使って

L2TP/IPsec トンネルが張られます。

ポイントは、このグローバル IP アドレスのセットがトンネルを張るために使用されるもので、トンネルを通っていく実際の通信には他の IP アドレスが使うためにもう 1 つ IP が必要ということです。

さきほど VPN クライアントと VPN サーバーの IP アドレスの割り当てが原因だったと書きましたが、この IP アドレスは上記 L2TP/IPsec のトンネルを張るために使われるグローバル IP のセットのことではありません。

実際に VPN 通信するためには、もう１個別の IP アドレスが必要でした。ここがしっかりと理解できていませんでした。このもう１個の IP 設定がなかったために VPN 通信ができなかったわけですが、SecureNATを ON にすることで、もう１個の IP アドレスが VPN クライアントに設定され、正常に通信できるようになりました。

だから、L2TP/IPsec で通信させるためには、

トンネルを張るためのグローバル IP アドレスと、
トンネルを張った後の実際の VPN 通信を行うための IP アドレス

のセットが必要になるということです。トンネルを貼っただけで終わったら意味が無いですよね。その後に通信することが目的ですから。

SecureNAT の仮想 DHCP サーバーがON になると、SoftEther VPN サーバー上で DHCP サーバーが稼働しはじめます。この DHCP サーバーはデフォルトでは 192.168.30.1 の IP アドレスを使用し、DHCP クライアント（当方の場合、iPhone 5 ）に対して、192.168.30.0/24 のアドレス帯の IP を渡します。この IP の受け渡しを行う時に L2TP/IPsec のトンネルが使われます。

仮に iPhone 5 に 192.168.30.10 の IP が割り振られたとしましょう。仮想 DHCP サーバーからこの IP が割り振られた時に、デフォルトゲートウェイのアドレスも配布されます。これは仮想 DHCP サーバー自身、つまり 192.168.30.1 になっています。

Table of Contents

実際の通信が行われる様子は？

iPhone 5 で Safari を起動してヤフーのページを閲覧するときを例に説明します。

iPhone 5 はデフォルトゲートウェイである 192.168.30.1 に対して HTTP リクエストを送信します。
HTTP リクエストを受け取った 192.168.30.1 = SoftEther VPN サーバーは仮想 NAT 機能を使って送信元アドレスを変換（おそらく OS の持つ IP アドレス）して、OS（当方の環境では CentOS ）のデフォルトゲートウェイ（当方の環境ではヤマハの RTX1100 ）にパケットをルーティングします。
CentOS から転送されてきた HTTP リクエストのパケットは送信元 IP アドレスが CentOS のもの（プライベート IP アドレス）の為、RTX1100 は送信元 IP アドレスをプロバイダーのグローバル IP アドレスに変換してインターネット側に転送します。
上記 3 で転送された HTTP パケットはインターネットの中でヤフーの Web サーバまで転送されていきます。
ヤフーの Web サーバまで HTTP リクエストが到達すると、今度はそのレスポンスが iPhone 5 まで帰って来ます。