VPNクライアントは接続するのにインターネットがない：三つの欠けた部品

pingに応答するトンネルでも、転送・変換・転送ルールは必要です。クライアントを再編集する前に、三つのうち何が欠けているかを見極めましょう。

クライアントはアドレスを取得し、サーバーはpingに応答し、それでもすべてのページがタイムアウトします。多くの人はこの時点でクライアントプロファイルを編集し始めますが、それはたいてい無駄な作業です：トンネルが上がったら、サーバーはルーターのように振る舞わなければなりません。パケットが出て応答が戻るには三つの条件が同時に成り立つ必要があり、どれが欠けていても症状は同じです。

動いているトンネルに出口がない理由

カーネルはインターフェース間でパケットを転送する必要があり、これはほとんどのLinuxディストリビューションで既定では無効です。外の世界が応答できるアドレスへトラフィックを変換する必要があります（ただし、上流のルーターがすべてトンネルのサブネットへの戻り経路をすでに知っている場合は別です）。ファイアウォールの転送経路は、応答を含めて両方向のトラフィックを許可しなければなりません。

これらはそれぞれ独立に直せるので、それが罠です。変換ルールなしで転送を有効にすると、パケットはプライベートな送信元のまま戻り経路なしで出ていきます。転送ルールなしで変換を追加すると、カーネルは一段階あとでパケットを落とします。

だからクライアントではなく三つの層を各々試し、結果が意味を持つように一度に一つだけ変えましょう。

転送は永続化が必要なカーネルのスイッチ

変更する前に現在の値を確認し、設定してから、変更が反映されたことを確かめます。

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

最初のコマンドは現在の値を示し、二番目は実行時に設定し、三番目は書き込みが機能したことを証明します。実行時の値は次回の再起動で消えるので、設定を変えていないのに保守後に動いていたセッションが壊れることがあります。

/etc/sysctl.d/ 配下のファイルで永続化し、確認のために再起動するのではなくそのファイルを適用します。FreeBSDでは同等のものが net.inet.ip.forwarding で、永続化には rc.conf の gateway_enable=YES を使います。転送が無効だと報告する機器は、「パケットは届くのに何も戻らない」という報告の一群を説明します。再構築されたカーネルや交換された機器イメージが誰にも告げずに元に戻すことがあるため、アップグレードのたびに設定も確認してください。

masquerade か固定の変換アドレスを選ぶ

外側のアドレスが動的な場合は、masquerading が最も単純で正しい形です。トンネルのサブネットを送信元、外側のインターフェースを出口として指定します。

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

公開アドレスが固定なら、その正確なアドレスへの送信元変換のほうが予測しやすく、監査も容易です。

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

二番目の形には、後で変わるハードコードされたアドレスがトンネルを動かしたままインターネット接続を静かに止めてしまうという保守の罠があります。masquerade を使うか、プロバイダーに移動させられるたびにルールを更新してください。インターフェースも重要で、上流のトンネルを共有するルーターは物理WANではなくそのトンネル経由で変換しなければなりません。

フィルターテーブルが三番目の関門

転送も変換も正しいのに、パケットがフィルターテーブルで死ぬことがあります。ufw はよくある犯人で、転送ポリシーが DROP で出荷され、その一つの設定がトラフィックを殺している間、残りの設定は完全に正しく見えることがあります。それを上げるのはチェックボックスではなく、意図的なセキュリティ判断です。

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

最初のルールはトンネルから外への新しいトラフィックを許可し、二番目は戻りの応答だけを許可します。どちらもトンネルのサブネットと意図した宛先に絞ってください、さもないとトンネルインターフェースでの包括的な許可が認証できる誰にでもVPNを開かれた出口にしてしまいます。

ブリッジされたトンネルには別の答えが要ります。アドレスは物理ポートではなくブリッジに属するので、インターフェースを従属させると以前のアドレスが外れ、ブリッジ自身がアドレスを得るまでホストは到達不能に見えます（それには dhclient br0 が使えます）。その障害はVPNの問題に見えて、実は第二層の問題です。ファイアウォールに触る前にブリッジ自身のアドレスを確認してください、フィルターの変更では送信元アドレスを失ったホストは直せないからです。

ページがまったく読み込まれないときの見方

サーバーのトンネルアドレスに ping して、トンネルが存在することを確かめます。次にクライアントから公開アドレスへ traceroute を実行し、どこで止まるかを読みます：サーバーで止まればパケットは届いているのに転送も変換もされていません、サーバーの先で止まれば問題は上流にあり手の届く範囲ではありません。

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

最初のコマンドはトンネルがサーバー自身までトラフィックを運ぶことを証明し、二番目はパケットが外へどこまで届くかを示します。トンネルアドレスで終わる経路はサーバー側の転送か変換を指し、一ホップ先で止まる経路はプロバイダーか上流ルーターの戻り経路を指します。

サーバー側では、クライアントがページを読み込む間、外側のインターフェースを観察します。プライベートな送信元アドレスで出ていくトラフィックは変換が欠けている証拠で、応答がまったくないのは転送経路か上流の戻り経路が落としている証拠です。

リモートのクライアントがサーバーのLAN上のホストにも到達する必要があるなら、LANにはトンネルのサブネットへの戻り経路が要ることを忘れないでください。これは変換ではなく経路制御であり、インターネット経路がようやく動いたあとに最も忘れられる手順です。

関連記事