ルーターのVPNかポート転送か：どちらが勝つ？

ルーター自身がVPNを終端しているのに、古い転送ルールが同じUDPポートをLAN上のマシンへ送り続けている。本当の終端になれるのはどちらか一方だけで、カーネルは二者を裁定しない。宛先変換はローカルサービスに問い合わせる前にパケットを書き換えるため、VPNプロセスはすでに別の場所へ送られたトラフィックを待ち続ける。課題はどちらがポートを所有するかを決めること、そしてルールを一致させることだ。

一つのポート、二人の所有者の主張

ルーター内で動くVPNサーバーには、自身のソケットへ導く受信許可が必要だ。同じポートへの宛先NATエントリはまったく別の場所へ導く。LANアドレスと転送の判断だ。これらはログも障害の仕方も異なる別の終端である。よくある手がかりは、一方のアドレスファミリーだけが動き、もう一方が動かないことだ。残ったエントリが単一のファミリー向けに書かれ、見直されていないからだ。

編集の前に主張を書き留める。ファミリー、外部アドレス、トランスポート、ポート、変換先だ。

宛先変換はローカル確認より先に走る

宛先NATはプリルーティング段階でパケットの宛先を変える。カーネルがローカル配送と転送のどちらを選ぶより前だ。宛先がLANホストになると、パケットは転送経路をたどる。ルーター自身のソケット向けの入力ルールは決して参照されない。だからクライアントがタイムアウトする間、VPNのログは空のままだ。

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

この順序が機構のすべてであり、機器の画面はチェックボックスの裏にそれを隠すだけで変えてはいない。パケットがどの経路を取るかは、今も宛先の所有者が決める。

LANホストが意図した終端なら、転送は正しく、ルーターが同じポートでも待ち受けるべきではない。

片方のマッピングを残し、もう片方を消す

そのポートとファミリーのNATエントリを列挙し、残す方を選ぶ。

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

同じ番号のTCPエントリはUDPの障害には無関係であり、両者を一つの対象として扱うと誤ったルールを消してしまう。ローカルソケットを勝たせるべきときは、競合するマッピングの所有者がその一行を削除するか書き換え、ルーター自身のポートへの受信許可はそのまま残す。無関係な転送、管理経路、ルールセットの控えは、すべて変更を生き延びるべきだ。

VPNが別ホストに住んでいるなら、転送が正しい対象だ。コンテナや仮想マシン内のサービスは、その箱がルーターと呼ばれていても公開ポートを必要とすることがある。だから筐体のラベルではなく、ソケットとその名前空間をたどること。

外から所有者を確かめる

ファミリーごとに別々に検証する。ルーターで終端するIPv6接続は、古いルールがリダイレクトするIPv4接続について何も語らないからだ。どちらの終端が応答したかは受信側サービスのログで読み、クライアントの成功メッセージは弱い証拠として扱う。意味のある検証には新しいフローが必要だ。外部ホストからnc -zvu 203.0.113.7 1194でプローブを送り、勝者のログをjournalctl -u openvpn@server -n 20で読む。ルーターのリスナーは接続自体を記録し、LANホストは自分のサービス内で記録する。

接続トラッキングは既存のフローを元のマッピングに留めるため、確立済みのセッションは、たった今直したルールより長く生き残ることがある。

意図した終端が通常の身元確認で応答したら、トンネルの先にある非公開リソースを検証する。外側のリスナーに届くのは最初の一歩にすぎない。内側のルーティングとアプリケーションの認可は別の結果だ。