VPNサブネットへのポート転送にSNATを適用すべきか？

ルーター自身のVPNクライアントの背後にあるホストへポートを転送すると、要求は明確に届くのに、ファイアウォールの問題のように見える形で失敗します。サービスは接続を記録し、クライアントは待ち、何も戻ってきません。宛先変換は仕事を果たし、失われたのは戻りパケットのほうです。ルーター上の単一の選択的な送信元NATルールがこれを直し、興味深いのはそのルールをどこまで狭くできるかを決めることです。

応答が別の道を通る理由

ポート転送はパケットの行き先を書き換えるだけで、出所は決して書き換えません。インターネット側クライアントのアドレスはトンネルを越える間ずっと送信元フィールドに残るため、遠隔のサービスは見知らぬ相手を見て、知っている唯一の方法、つまり自分のデフォルトゲートウェイ経由で応答します。そのゲートウェイは向こう側のVPNコンセントレーターであり、任意の公開アドレスへの戻り経路を持ちません。

トンネルインターフェースでキャプチャを見ると、要求パケットは出ていき、入ってくるものはないという非対称性が明らかです。転送チェーンがフローを許可し、トンネルがそれを運んだので、破棄は遠隔ホストがすでに戻り経路を選んだ後に起きています。

信頼できるほど狭い送信元ルール

ルーターを、遠隔ホストが応答する送信元にします。この構成ではWANアドレスが203.0.113.24、LANが192.168.88.0/24、ルーターのトンネルアドレスが172.20.5.1、サービスは172.20.5.40:8443で応答します。下のルールは宛先変換後のパケットに一致するため、公開アドレスではなく変換後のアドレスを指定します。クライアントのアドレスに依存するものは何もなく、まさにそこが要点です。

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

その行の一致条件はすべて、書き換えを単一のトンネル上の単一のサービスに限定するために存在します。インターフェースやポートを外せば、問題が必要とする以上のトラフィックを書き換えることになり、的を絞った修正が次の人にとって謎になるのはこうしてです。

包括的なマスカレードが正直な選択である場合

ルーターが多くのサービスを同じVPNサブネットへ転送するなら、サービスごとのルールは誰も保守しない一覧になります。トンネルインターフェースを出るすべてをマスカレードするほうが単純で予測しやすく、その代償は向こう側のすべてのホストから元のクライアントを隠すことです。そちらのログを帰属に使わないならそれを選び、使うなら狭いルールを保ってください。

二つの選択肢は失敗の仕方も異なります。狭いルールが欠けると一つのサービスが壊れ、一致しすぎる広いマスカレードはすでに動いていたトラフィックを静かに書き換えることがあり、ルーター自身の発信接続も含まれます。

公開する前にカウンターを確認する

決して一致しないルールは、パケットを数えるまで動作するルールと見分けがつきません。どのクライアントも接続する前にバイトカウンター付きでテーブルを読み直し、次にLANではないネットワークから接続してもう一度読みます。推測を事実に変えるのはこの二回の読み取りです。二回目が動いてから初めて転送を公開してください。

iptables -t nat -L POSTROUTING -v -n --line-numbers

実際の接続後に送信元ルールのカウンターがゼロなら、一致が間違っており、ふつうは宛先かポートが変換後のパケットと合っていないためです。カウンターが増えるのにクライアントがまだタイムアウトするなら、戻り経路は直っており別の何かが応答を落としているので、次は向こう側の転送ポリシーを見てください。LAN内からのヘアピンアクセスは別の問題で、これの広い版ではなく独自のルールが必要です。