二重NATとVPN:クライアントは動くが、サーバーは動かない
アドレスを変換するルーターが二台あっても、外向きのVPNクライアントはほとんど止まりません。その背後でサーバーを運用するのは難しく、外側の層がキャリアグレードNATの場合はなおさらです。
ルーターが別のルーターの背後にあり、WANアドレスはプライベートなのに、VPNクライアントは接続できます。二重NATがトンネルを壊すと考える人には意外ですが、変換が最も得意なのはまさに外向きの接続です。同じ二つの層の背後でVPNサーバーを運用するのが、たいてい失敗するケースです。何かを変える前に、接続の向きを図にしてください。
まず接続の向きを図にする
内側のルーターのステータス画面を開いてWANアドレスを書き留め、公開サービスが示すアドレスと比べます。両者が違えば、ルーターとインターネットの間に少なくとも一台の変換装置があります。WANアドレスが 100.64.0.0/10 の範囲に入るなら、外側の変換装置はプロバイダーのものであり、あなたは制御できません。この二つの事実が、以降の手順のどれが機能し得るかを決めます。
curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1
二重NATは二重VPNではありません。変換はアドレスとポートを書き換えるだけで、二本目の暗号化トンネルを加えるわけでも、何かを暗号化するわけでもありません。この二つを区別することが重要なのは、対処法がまったく異なり、片方は設定画面ではなくプロバイダーとの対話を必要とするからです。
外向き:クライアントが問い合わせ、変換装置が対応付ける
外向きのトンネルはあなたのマシンからのパケットで始まるので、各変換装置は対応付けを作り、応答を戻せます。プロトコル、ポート、アイドルタイマーが、その対応付けが役に立つだけの時間存続するかを決めます。ほとんどの家庭用ルーターは設定なしでこれを処理します。
実際に起きる不具合は、ルーターの台数ではなく、タイムアウトとプロトコル対応の問題であることがほとんどです。数分の沈黙の後に切れるトンネルは対応付けの失効であり、keepaliveが標準的な答えです。IPsecには標準のNAT-traversal拡張があるので、変換を越えられないという主張は単純に誤りです。トンネルがまったく確立しない場合は、トポロジーを疑う前にエンドポイントと認証情報を確認してください。
wg show
ping -c3 10.8.0.1
外向きのトンネルがあるネットワークでは動き、別のネットワークでは動かないなら、そこで止めてください。その比較はネットワークの話であり、ルーターの台数の話ではありません。
内向き:ポート転送が届くのは自分の管理下の機器だけ
サーバーの運用は逆向きです。インターネットから新しい接続が届き、すべての層を通ってあなたのマシンに到達しなければなりません。内側のルーターのポート転送ルールは、外側の変換装置もその通信をあなたに届ける場合にしか役立ちません。ローカルのルールを繰り返しても、プロバイダーの機器を制御できるわけではありません。
nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'
内側のルーターのWANアドレスを、観測した公開アドレスと比べ、それぞれの値の出どころを書き留めます。WANアドレスがプライベートか共有範囲内なら、外側の層はあなたが設定できない変換を行っています。効果を発揮できないルールに一晩を費やす前に、プロバイダーがどのような内向きの到達性に対応しているか尋ねてください。ルーターを取り外したり、ファイアウォールを広く無効にしたりするのは診断ではなく、一つのポートを開けるための悪い取引です。
外側の層がプロバイダーのもので、転送しないなら止めてください。その場合に使える答えは別のアクセス方法かリレーであり、あなた側のもう一つのルールではありません。
一度に一つの変数だけを試す
テストごとに一つだけ変えて結果を記録してください。二重NATの経路は単一ルーターの経路より変数が多いからです。プロファイルと端末を固定し、別のアクセスネットワークと比べます。ネゴシエーションが失敗するのか、アイドル後にセッションが切れるのか、プライベートな宛先だけが失敗するのかを記録します。この三つの観察は三つの異なる層を指しています。
journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40
重複するプライベートサブネットは別の罠で、どれだけ変換しても直りません。自宅ネットワークと遠隔ネットワークが同じ範囲を使うと、間に何台の変換装置があっても経路の衝突が現れます。片側の番号を振り直すのが唯一の持続的な答えです。
遠隔ゲートウェイも同じ注意に値します。その転送ルールと戻り経路が欠けている部分かもしれないからです。認証が通るトンネルでも使えるアプリケーション経路がないことがあり、その不具合はクライアント側からは同じに見えます。どちらの向きが失敗し、どの層が責任を持つのかを言えるようになったとき、この解説は終わります。