VPN 変更後にルーターの管理画面が応答しなくなる理由

ルーターでトンネルを試すために経路やファイアウォールのルールを変えたら、十分前まで正常だったノート PC から管理画面が応答しなくなりました。反射的に VPN のせいだと考えがちです。ほとんどの場合トンネルは健全で、次の三つのうちどれかが壊れています。ルーター自身のアドレスへの戻り経路がない、入力ポリシーが要求を捨てている、あるいは呼び出しているアドレスで Web サービスが待ち受けていない。三つともブラウザーでは同じに見えるので、人々は一時間トンネルを再起動して何も学びません。

まず殺すべき神話はこれです。動いているトンネルは再び入るための道ではありません。それは独自の信頼の問いを持つ新しいネットワーク接続であり、誰も確認していない新しい経路を開きながら、古い管理経路を静かに消すことがあります。

トンネルは管理経路ではなかった

転送と入力は別の仕事です。「クライアントはトンネル経由で NAS に届くか？」はルーターを通るパケットについての転送の問いです。「ルーターの SSH ポートを開けるか？」はルーター自身宛てのパケットについての入力の問いです。転送トラフィック用に書かれた通過ルールは二番目の問いには何もせず、これがトラフィックを完璧に運ぶトンネルでも管理セッションを拒否し続ける最も一般的な理由です。

逆の誤りはインターフェース名を信頼することです。トンネルはピアに対して暗号化され、その背後のすべてのサービスに対してではありません。インターフェースのラベルにある VPN という語は、どの送信元にログインを許すべきかについて何も語りません。

第一層：ルーター自身のアドレスへの経路はあるか

クライアント側で始め、パケットがどこへ行くかをカーネルに尋ねます。Linux では ip route get 10.6.0.1 が選択された経路、出力インターフェース、送信元アドレスを表示します。プロバイダー方向のデフォルト経路が表示されるなら、パケットはトンネルに入らず、ルーター上のどのルールでも救えません。

トンネル側にはこの問いの独自の版があります。WireGuard は AllowedIPs を暗号鍵ルーティングテーブルとして扱い、両端でピアが使える送信元アドレスと、そのピアへ送る宛先を宣言します。クライアントの項目にルーターのトンネルアドレスが含まれていなければ、クライアントにはそこへの経路がありません。そのクライアントのサーバー側項目がクライアントのトンネルアドレスを覆っていなければ、サーバーはどのファイアウォールルールも見る前にパケットを捨てます。

ポリシーを調べる前に、到達したい正確なアドレスを確認します。古い DNS レコードや変更前のキャッシュされた近隣エントリは、ルーターが決して持っていなかったアドレスへあなたを送ります。

第二層：転送ポリシーではなく入力ポリシー

ファイアウォールはパケットが到着するインターフェースでルールを評価します。pfSense と OPNsense ではインターフェースのタブとルールの順序が、ファイアウォール自身のサービスへのトラフィックを許すか決めます。LAN クライアントをインターネットへ出すルールは、トンネルのピアに Web GUI を開かせるルールではありません。firewall4 の OpenWrt では各ゾーンが入力ポリシーを持ち、option input 'ACCEPT' か 'REJECT' で、入力が REJECT のゾーンにあるトンネルインターフェースは管理接続を拒否しつつ、転送が許可されていればトラフィックは転送し続けます。

新しい経路を動かすためにアンチロックアウトのルールを無効にしないでください。そのルールは悪いルールが LAN の管理アドレスを締め出すのを防ぎます。守るのは LAN サブネットであり、いま作ったトンネルのサブネットではありません。管理者の送信元に絞ったルールを一つ追加し、安全網には手を触れないでください。pfSense の 管理者アクセスのドキュメント に、それらの設定がどこにあるか書かれています。

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

第三層：そのアドレスで何かが待ち受けているか

サービスは動いていても、一つのアドレスに束縛されているために到達できないことがあります。OpenWrt の uhttpd は /etc/config/uhttpd に明示的な待ち受け項目を持ちます。たとえば list listen_http '0.0.0.0:80' で、LAN アドレスにだけ束縛するビルドはトンネルのアドレスでは何も受け付けず、待ち受けインターフェースの設定を出す製品も同じように振る舞い、上の待ち受けコマンドがこれに直接答えます。

次に拒否と沈黙を分けます。nc -vz 10.6.0.1 443 が接続拒否を返すなら、パケットはルーターに届き、何かが拒否しています。閉じたポートか、明示的な拒否ルールです。タイムアウトまで固まるなら、パケットは捨てられたか、そもそもルーティングされていません。この違いが次にどの層を見るべきかを教え、五秒で済みます。

VPN インターフェースは境界であり、復旧経路ではない

暗号化は回線を守りますが、誰が管理画面を開けるかについては何も語りません。トンネルが動いたら、トンネルインターフェースですべてを許可して到達性を解決したくなる衝動に抗ってください。管理者には自分のトンネルアドレスに紐づくルールか、管理者専用の別トンネルを与え、一般ユーザー、NAS、カメラ、家族のノート PC を管理ポートから遠ざけます。ファイル共有が必要なピアが、ルーターのログインからルール一つ分の距離にいるべきではありません。

ルーターの役割が答えを変えます。トンネルを終端するルーターはそこから管理者を受け入れても正当ですが、トンネルをインターネット出口としてだけ使うルーターは通常そうすべきではありません。どちらの場合もサブネットの許可はログインではないので、アカウント認証とトランスポートの安全性は有効のままにします。

ロックアウト後に人がやる埋め合わせはもっと悪いものです。WAN 管理を有効にする、あるいはポートを Web GUI に転送する。これは短い障害を恒久的な露出に変え、ログインページはインターネット上のあらゆるスキャナーから届くようになります。許可される側だけでなく拒否される側もテストし、管理アクセスを持つべきでないピアがログイン要求ではなくタイムアウトや拒否になることを確かめます。

新しい接続でもテストします。ステートフルファイアウォールは既存のフローを状態テーブルに保持するので、すでに開いている SSH セッションは、すべての新規接続を遮断する変更を生き延びることがあります。こうしてロックアウトは次の再起動か次のスリープまで見えないままになります。

ポリシーに触れる前に戻り道を用意する

最初の変更の前に四つを書き留めます。トンネルが死んだらどうやって機器に届くか。シリアルコンソール、プロバイダーのコンソール、LAN 上のマシンなど、現在の設定をどこへ書き出すか、どの一つのルールや経路を変えるのか、そしてその項目を正確にどう戻すか。OpenWrt では sysupgrade -b /tmp/backup.tar.gz が設定を取得し、編集は uci commit まで保留されるので、早めに気づけば安価に取り消せます。pfSense は設定履歴を保持し、AutoConfigBackup はすでに有効な場合にだけ役立ちます。ルーターが fail-closed のルールセットで動いているなら、計画した保守経路がそのルールの塞ぐトラフィックの内側にないことを確認し、再起動は永続ルールを消すのではなく再適用することを覚えておいてください。

試行ごとに境界を一つだけ変え、開いたままのシェルではなく新しい接続からテストします。テストが失敗したら、次の層に触れる前にその一つの変更を戻します。トンネルはその間ずっと上がったままでかまいませんが、緑の状態アイコンはまだ入れる証拠ではありません。

離れる前の簡単な確認：

• たったいま編集したルールに依存しない送信元からルーターに届きますか。
• トンネルインターフェースの入力ポリシーは管理者の送信元だけを許していますか。
• 管理サービスはトンネル上に存在するアドレスに束縛されていますか。
• 拒否されるピアと新しいセッションを一つずつ試しましたか。
• WAN の管理面はまだ閉じていますか。