ちょっとした操作ミスで、ASUSルーターの管理画面から ファイアウォール をオフにしてしまい、その数秒後に自宅のネットワークが丸ごと停止してしまったことがあります。すべての機器が外部と通信できなくなり、ルーターの管理画面にすら入れなくなりました。しかもその時、自分は外出先にいました。この記事では、そのときの原因究明の過程と、以前から動かしていた Cloudflare Tunnel の接続を使って、通常の入り口を経由せずにルーターを復旧させた一部始終を記録しておきます。
何が起きたのか
ちょうど自宅サーバーとネットワーク構成を見直している最中で、ASUS ルーターの管理画面でファイアウォールをオフにしてしまいました。一見すると小さな設定変更に思えますが、実際にはその後の連鎖反応は想像以上のものでした。
- NAT と DNS 解決が同時に機能しなくなる：LAN 内のサーバーが外部へ新しい接続を開始できなくなり、ドメイン名の解決もできず、docker pull や curl はすべてタイムアウトしてしまいました。
- 通常の管理経路も完全に遮断される：ルーターの外部向け DDNS が瞬時に機能を停止しました。ファイアウォールをオフにした時点で、ルーターはあらゆる新規の受信リクエストを拒否するようになり、外部から DDNS とポート番号でアクセスする方法も、LAN 内から新たに接続を確立する方法も、どちらも通用しませんでした。
ASUS 自身のファイアウォール機能の説明ページにも書かれている通り、ルーターのファイアウォールは外部からの攻撃を防ぐだけの機能ではなく、LAN 内の機器間のパケット管理の一部も担っています。オフにすることで影響を受けるのは、セキュリティ面だけではないのです。
そのとき自分は外出先にいて、自宅で稼働しているスマート機器はカメラも含めてすべて同時にオフラインになりました。もう物理的にルーターの前まで行かないと解決できないと諦めかけていた矢先、あることに気づきました。ルーターの管理画面には入れず、カメラもすべて切断されているのに、Cloudflare Tunnel 経由で接続している自宅サーバーの CasaOS の画面は問題なく開けて、Web 上のターミナルも普通にコマンドを実行できたのです。
この「まだ生きている」という一点が、後にルーターを救出する糸口になりました。
なぜ Cloudflare Tunnel だけが生き残っていたのか
通常の受信接続がすべて機能しなくなっている状況で、唯一つながっていたのが、LAN 内のサーバー上で動いている Cloudflare Tunnel（cloudflared プロセス）でした。理由は、二つの接続方式が向いている方向がそもそも違うからです。
| 方式 | 接続の方向 | ファイアウォールをオフにした後の状態 |
|---|---|---|
| DDNS | 外から内へ（外部からルーターへ能動的に接続） | ルーターが新規の受信リクエストを拒否し、即座に機能停止 |
| Cloudflare Tunnel | 内から外へ（サーバー側から能動的に接続） | ファイアウォールをオフにする前から確立していた接続がそのまま維持される |
ポイントは、ファイアウォールをオフにする前の時点で、cloudflared がすでに Cloudflare のエッジノードとの間で持続的な TCP 長時間接続を確立していたことです。その古い接続は、ルーターのメモリ上の接続テーブルに残ったまま解放されていませんでした。そのため、外部からのリクエストはこの既存の経路を通じてサーバー内部まで届き続けることができたわけです。これが、Cloudflare Tunnel だけがファイアウォールの停止による影響を受けなかった根本的な理由です。
試した方法とつまずいた点
ルーターの制御を取り戻すため、サーバー上でいくつかの方向性から試行錯誤しました。
方法1：Docker で一時的な転送用コンテナを起動する
まず考えたのは、alpine/socat のコンテナを起動して、サーバーの 8080 番ポートへの通信をルーターの管理用アドレス（192.168.1.1）へ転送することでした。しかしサーバーの DNS がすでに機能しておらず外部に接続できないため、Docker は i/o timeout エラーを出し、イメージすら取得できませんでした。この方法は断念せざるを得ませんでした。
方法2：サーバー上に既存の SSH でポート転送を行う
新しいイメージを取得できない以上、サーバーにすでに入っている SSH の仕組みだけに頼ることにしました。
まず root ユーザーでトンネルを試みました。
ssh -N -f -L 0.0.0.0:8080:192.168.1.1:80 [email protected]Linux のデフォルトのセキュリティ機構により、root ユーザーがローカルから直接 SSH ログインすることは許可されておらず、Permission denied と表示されました。
次に一般ユーザー user に切り替え、ポート番号も未使用の 9090 に変更しました。
ssh -N -f -L 0.0.0.0:9090:192.168.1.1:80 [email protected]トンネル自体の確立には成功しましたが、外部から http://[IP]:9090 にアクセスしても開けませんでした。原因は、ASUS ルーターが HTTPS でのアクセスを強制している可能性が高く、かつデフォルトの管理用ポート番号もすでに変更されていたためです。
そこで、ルーターがどのポートを開けているのかを調べるため、ポートスキャンを行いました。
for port in 80 443 8543; do nc -zv -w 2 192.168.1.1 $port; doneここでの 8543 は説明のために仮に置いた番号です。実際に試す際は、ご自身のルーターで実際に変更したカスタム管理ポートに置き換えてください。
スキャンの結果、80 番ポートは Connection refused となった一方、443 番と 8543 番はどちらも succeeded! でした。これにより、ルーターは暗号化された HTTPS のみを受け付けており、管理サービス自体は正常に動作していて、単に入り口が隠されているだけだと分かりました。
最終的な解決策：Cloudflare Tunnel のマッピングを直接変更する
すでに外部からのトラフィックが既存の Tunnel 接続を通じてサーバー内部まで届いている以上、一番シンプルなのは、サーバー内部で複雑な SSH 転送をあれこれ組む代わりに、Cloudflare Tunnel のマッピングルールを直接書き換えることでした。
ステップ1：Public Hostname のルールを追加する
Cloudflare Zero Trust の管理コンソールにログインし、稼働中の Tunnel を見つけて、Public Hostname に以下のルールを新規追加します。
- Subdomain：router
- Domain：yourdomain.com
- Type：HTTPS（ルーター側の暗号化プロトコルに合わせるため、必ずこれを選択します）
- URL：192.168.1.1:8543（ルーターが実際に開放している HTTPS ポートを指定します。8543 は仮の番号なので、実際にはご自身の管理ポートに置き換えてください）
ステップ2：TLS 検証を無効にする
ASUS ルーターの LAN 側はデフォルトで自己署名証明書を使用しているため、Cloudflare はセキュリティ上の理由でこの接続をデフォルトでブロックします。Additional application settings の TLS 項目にある No TLS Verify を有効にする必要があります。
ステップ3：動作確認
設定を保存したら、ブラウザで直接以下にアクセスします。
https://router.yourdomain.comトラフィックは Cloudflare Tunnel の 443 番ポートを経由してサーバーに届き、クライアント側でローカルに復号された上で、暗号化プロトコルとしてルーターの 8543 番ポートへ送られます。ルーターのログイン画面が無事表示され、ログイン後は「詳細設定」→「ファイアウォール」に進み、「ファイアウォールを有効にする」を再び「はい」に設定して保存します。
保存が反映された瞬間、LAN 内の DNS 解決と NAT エンジンが正常に戻り、ネットワーク全体が復旧しました。
今回の対応の流れ
いくつかの気づき
一つ目は、極端なネットワーク障害の場面における内網穿透ツールの価値の高さです。「内から外へ」という長時間接続の仕組みを持つ Cloudflare Tunnel は、DNS が機能停止し、メインルーターのファイアウォールに異常が起きている状況でも生き残っていました。今回の遠隔での自力復旧において、唯一使えた経路がこれだったのです。
二つ目は、DDNS と Tunnel にはそれぞれ向いている場面がありますが、今回の経験から見ると、Tunnel のほうが障害に対する耐性が明らかに高いということです。DDNS はポートの公開に依存しているため、ファイアウォールの設定が変わるだけで簡単に機能しなくなります。一方 Tunnel は受信用ポートを一切公開する必要がなく、パブリック IP の変化にも影響されません。証明書も Cloudflare 側で一括管理してもらえます。もし遠隔管理の逃げ道を一つだけ残すとしたら、Tunnel のほうが確実な選択だと感じました。
三つ目は、穿透先の機器が HTTPS で動作していて自己署名証明書を使っている場合、必ず No TLS Verify を有効にしておく必要があるということです。これを忘れると、Cloudflare のエッジノードの段階でトラフィックがブロックされてしまい、どう設定してもアクセスできません。
最後は、より経験則に近い話ですが、ネットワーク機器を遠隔でいじる際は、メインルーターのファイアウォールを丸ごとオフにするのはできるだけ避けたほうがよいということです。特定の通信だけを通したい場合は、「ネットワークサービスフィルター」やポート転送を使って、特定の IP とポートに絞って細かく許可設定をするほうが安全ですし、自分自身を締め出してしまうこともありません。
