PiVPN のハンドシェイクは成功するのにページが止まる：MASQUERADE を確認する

スマートフォンではトンネルが接続済みと表示され、クライアントもプライベートアドレスを報告しているのに、最初のページは読み込みの途中で止まったままです。この組み合わせを見ると、多くの人が暗号設定や CPU 温度を疑いますが、実際にはそこに問題はありません。トンネルは立ち上がり、ネゴシエーションは完了していますが、失敗しているのはその次の段階、サーバーがクライアントのパケットをインターネットへ渡そうとする部分です。パケットがたどる経路をそのまま追えば、食い違いはたいてい NAT テーブルの一行に現れます。

クライアントが到達できるものとできないものから始める

接続中のクライアントから、公開インターネット上にあるページを読み込み、即座に失敗するのか途中で止まるのかを確認します。次に VPN サーバー自身のプライベートアドレスにあるリソースを開き、二つの結果を比べます。

公開サイトがタイムアウトする一方で ping に応答するトンネルアドレスは、転送や変換の問題の兆候であり、壊れたハンドシェイクではありません。クライアント自身のステータスパネルでは区別できません制御チャネルが上がっていることしか分からないからです。サーバー側でトンネルのインターフェースを次で確認してください：ip -br addr show tun0 そして、クライアントに割り当てられたアドレスが設定したプール内にあることを確認します。プールとクライアントのアドレスが食い違う場合はまずそこを直してください、以下のルールはすべてプールに一致するからです。

次に、公開アドレスへ到達するのにサーバーがどのインターフェースを使うかを尋ねます。ip route get 203.0.113.9 は選択されたデバイスと送信元を最初の行に出力します。そのデバイス名を書き留めてください、NAT ルールに必要な値はこれです。

パケットが出ていくかどうかを決めるルールを読む

MASQUERADE がパケットを書き換えるのは、そのパケットがルールに書かれたインターフェースから出ていくときだけです。有線デバイスに限定されたルールは Wi-Fi から出る通信には何の効果もなく、パケットは上流ルーターまでプライベートな送信元アドレスを保ちます。そのルーターにはトンネルのプールへ戻る経路がないため応答を破棄し、クライアントには開いてすぐ切れる接続が見えます。症状の大きさは、最初の応答が必要になるまでにページのどこまで届くかで決まります。

ライブテーブルを一覧し、MASQUERADE という語を探すだけでなく出力インターフェースの列を読みます。整形された一覧より、追加形式の出力のほうが比較しやすいです：

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

かつて Ethernet を使い、今は Wi-Fi を使っている Raspberry Pi では、古い名前がほぼすべての原因です。インストーラーはセットアップ時に存在したデバイスを記録し、保存されたルールセットが起動のたびにそれを再現します。ほかを変更する前に、ルート検索で得たデバイスとルール内のデバイスを比べてください。一致していればインターフェースは問題ではなく、最後の節のカウンターへ進むべきです。違っていれば、修正は永続化ファイルの一語の編集です。

保存されたルールセットを直す（実行中のものだけではなく）

ライブテーブルだけを編集しても次の再起動までしか持ちませんが、それでも問題が解決したと錯覚するには十分です。起動時に戻ってくるルールは、ファイアウォールの永続化パッケージが再読み込みするファイルにあります。Debian ベースの Pi イメージでは、そのファイルは通常 /etc/iptables/rules.v4。

触る前にコピーを取り、MASQUERADE 行の出力インターフェースを記録したデバイスに置き換えます、たとえば -o wlan0 の代わりに -o eth0。クライアントのプールが変わっていない限り、送信元の範囲はそのままにします。再読み込みして、ルールが正しいデバイスを指すことを確認します：

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

隣り合う二つの設定は忘れがちです。sysctl net.ipv4.ip_forward は 1 を報告する必要があり、上流ルーターがプライベートな送信元アドレスを自分でフィルタしていないことも必要です。

ルールが効いていることを証明し、それからまだ遅い部分を切り分ける

カウンターだけがルールが一致したことの正直な証拠です。詳細一覧を実行し、クライアントでダウンロードを始めて、もう一度実行します。ルール横のパケットとバイトの列は増えるはずで、ゼロのままのルールは一致していません。カウンターが動いてもページが失敗するなら、送信元の範囲を実際のプールと次で比べてください：grep -n "^server " /etc/openvpn/server.conf。カウンターが動きページも読み込めるのにスループットが低いなら、変換は完了しており、残る問題は別の場所です。

同じクライアントから二つの転送を比べます、一つはローカルネットワーク上のホストへ、もう一つはトンネル経由で同じホストへ。どちらも遅い場合は VPN ではなく Pi の上流リンクか Wi-Fi リンクを示します。トンネル経由だけが遅い場合は MTU と再送を示し、これらは次のコマンドで調べられます：ip -s link show tun0暗号設定を変える前に確認してください。

実験を取り消すには、コピーを戻して再読み込みし、元のルールとカウンターが戻ったことを確認します。次回の上流変更で同じ食い違いが再発見されるので、出口デバイスと再読み込みコマンドをサーバーのメモに書いておきます。間違ったデバイスを指すルールは、通信が必要になるまで見えないままです。