著者 Matt Connor
ufwでVPSに接続できないときの復旧方法
ufwでVPSから締め出された場合の復旧手順を解説します。プロバイダーのコンソールでufwを無効化し、実際に適用されたルールを確認して再発を防ぎます。
まず復旧する
ufw によって VPS から締め出された場合、復旧する方法はプロバイダーのコンソールまたはレスキューモードです。ブロックルールが有効になった後は、SSH 経由で修正する方法がないためです。カーネルは sshd がパケットを受け取る前に破棄するため、ログイン先も、ネットワーク経由で修復する手段もありません。プロバイダーのコントロールパネルでコンソールを開き、そのプロンプトでログインして、1 つのコマンドを実行します。
sudo ufw disableFirewall stopped and disabled on system startup と表示されるはずです。新しい SSH 接続は 1、2 秒以内に再び機能します。設定した内容は失われません。disable はカーネルからルールをアンロードし、ENABLED=no を /etc/ufw/ufw.conf に書き込みます。一方、ルールは /etc/ufw/user.rules にディスク上で保持され、次回の ufw enable を待機します。
再起動して解決することを期待しないでください。ufw はブート時に自動起動するため、ENABLED=yes を実行すると、ネットワークが起動する前に同じルールセットが再び読み込まれます。再起動しても、ufw によるロックアウトの状態は変わりません。
コンソールには、設定していない可能性があるパスワードが必要です
Web コンソール（VNC またはシリアル）は、マシンに接続されたキーボードです。ネットワーク経路ではないため、ファイアウォールのルールで遮断することはできません。ただし、ローカルログインは必要です。ここで鍵認証のみの構成が問題になります。sudo ユーザーにパスワードを設定しておらず、root ログインもロックされている場合、コンソールには入力できないログインプロンプトが表示されます。SSH 接続が利用できるうちに、今すぐそのパスワードを設定します: sudo passwd yourname。多くの管理パネルでは root パスワードもリセットできますが、通常は再起動が必要になります。
コンソールを使用できない場合は、プロバイダーのレスキューシステムを起動します。これはディスクをマウントしていない状態で別のオペレーティングシステムを実行するため、外部から ufw を無効にできます。
lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt最初に lsblk を実行します。root パーティションが常に /dev/vda1 とは限らないためです。通常のシステムを再起動すると、手動で有効にするまで ufw は無効なままです。
最小限の復旧手順
次の順序で実行します。最初の 4 つは安全です。その後の手順は安全ではありません。
sudo ufw disableを実行してルールを無効化し、アクセスを回復します。sudo ufw show addedを実行して、追加したルールを、それらを追加したコマンドの形式で表示します。これは ufw が非アクティブな状態でも機能します。ufw statusは機能しません。sudo sshd -T | grep -i '^port'を実行して、sshd が実際に待ち受けているポートを確認します。変更していなければ、port 22が表示されます。- 実際のポートを指定して
sudo ufw allow 22/tcpを実行し、次回の有効化で同じロックアウトが発生しないようにします。 sudo ufw enableを実行します。先にロールバックをスケジュールしてください。手順はこのページの後半にあります。
ufw reset が実際に行うこと
ufw reset は最終手段であり、最初に実行する操作ではありません。ファイアウォールを無効化し、すべてのルールファイルをバックアップしたうえで、デフォルト設定を着信拒否、発信許可に戻します。ファイルごとにバックアップ先を 1 行ずつ表示します。
Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'リセット後は許可ルールが一切なくなるため、SSH 経由ではなくコンソールから実行してください。再度有効化する前に、SSH のルールを追加します。バックアップはプレーンテキストです。sudo grep -n dport /etc/ufw/user.rules.20260813_101500 で以前のルールを確認できるため、誤って破棄するつもりのなかったルールセットを再構築できます。
ufw がルールを保存する場所
記憶に頼るより、ファイルを確認する方が確実です。次の 5 つのパスに、状態全体が保存されています。
/etc/ufw/user.rulesと/etc/ufw/user6.rules: 追加したルールです。評価される順序で保存されています。/etc/ufw/before.rulesと/etc/ufw/after.rules、および6の各バリアント: ルールの周囲に ufw が組み込むフレームワークです。確立済み接続の accept ルールや loopback ルールも含まれます。/etc/default/ufw: デフォルトポリシーとIPV6スイッチです。/etc/ufw/ufw.conf:ENABLEDとログレベルです。/var/log/ufw.log: ログが有効な場合に、ブロックされた内容が記録されます。
ufw はファイルを書き換える前に、タイムスタンプ付きのコピーを作成します。そのため、ls /etc/ufw/ には user.rules.20260813_101500 のような名前のファイルが蓄積されます。これは変更を元に戻すための履歴です。設定を戻し始める前に確認すると役立ちます。
ディスク上の内容ではなく、kernel に読み込まれている内容を確認するには、sudo ufw show raw、または sudo iptables -S と sudo ip6tables -S を使用します。Ubuntu 22.04 と 24.04 では、これらのコマンドは nft バックエンド版です。そのため、sudo nft list ruleset は同じルールを新しい構文で表示します。
ufw を有効にすると SSH セッションが切断されるのはなぜですか？
受信のデフォルトポリシーは deny です。SSH ポートの許可ルールがない状態で ufw を有効にすると、新しい接続がすべて遮断されます。ufw は警告も表示します。Command may disrupt existing ssh connections. Proceed with operation (y|n)? に対して、SSH の許可ルールがないまま y と応答することが、このページにある問題の最も一般的な原因です。
分かりにくいのは、切断までに遅延がある点です。/etc/ufw/before.rules はユーザー定義のルールより先に、ESTABLISHED,RELATED 状態のパケットを許可します。そのため、コマンドを入力した SSH セッションは通常どおり動作し続けます。接続不能になるのは次の接続時です。数時間後になる場合もあり、その時点ではファイアウォールの変更が原因だと気付きにくくなります。最初の SSH セッションを閉じる前に、必ず 2 つ目の SSH セッションを開き、接続できることを確認してください。
apt と DNS は、ポリシー変更後になぜ機能しなくなったのですか？
sudo ufw default deny outgoing は外向きの DNS（domain name system）問い合わせと外向き HTTP をブロックするため、名前解決が停止し、パッケージ更新も停止します。apt update は Temporary failure resolving 'archive.ubuntu.com' を報告します。受信 SSH は引き続き機能します。SSH への応答は ESTABLISHED であり、フレームワークのルールを通過するためです。その結果、ファイアウォールが無関係に見えますが、実際にはファイアウォールが原因です。
外向き通信を拒否するポリシーを使用する場合は、マシンが実際に必要とする通信を許可します。
sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp最後のルールがないと時刻がずれます。時刻がずれると TLS（transport layer security）証明書の検証に失敗するため、curl はポートではなく日付が原因で失敗し始めます。この症状は変更から数日後に現れます。そのため、外向き通信の拒否は監視対象のマシンに適用するポリシーであり、一度設定したままにするマシン向けではありません。
ufw のルールが一致しないのはなぜですか？
ufw はユーザールールを順番に評価し、最初に一致した時点で処理を停止します。広範な allow の後に追加した deny は、先に allow でパケットの処理が決まるため適用されません。番号付きで順序を表示し、必要な位置に挿入してください。
sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4sudo ufw --dry-run allow 8080/tcp は書き込まれるルールを表示するだけで、変更は行いません。ルールを有効化する前に安全に確認する方法です。
アプリケーションプロファイルにも注意が必要です。sudo ufw allow OpenSSH は /etc/ufw/applications.d/openssh-server のプロファイルを使用し、そのプロファイルは port 22 を意味します。sshd が 2222 で待ち受けている場合、このルールは実際には使用されていないポートを開くため、正しく見えるルールセットのまま接続できなくなります。ポートを変更した後は、ポート番号を直接指定してください。その他の構文については、VPS 向け ufw ファイアウォールの基本で説明しています。
IPv4 ルールでは、なぜ実際に確認できる状況を説明できないのですか？
トラフィックの半分は IPv4 ではないためです。Ubuntu では IPV6=yes が /etc/default/ufw に含まれており、ufw は /etc/ufw/user6.rules に IPv6 用の並列ルールセットを保持します。ufw allow from 203.0.113.10 to any port 22 のように IPv4 アドレスを指定したルールは、IPv6 ルールをまったく作成しません。VPS に AAAA レコードがあり、クライアントが IPv6 を優先すると、ufw status に正しいように見えるルールが表示されていても、接続はタイムアウトします。ssh -4 user@host と ssh -6 user@host を使って違いをテストしてください。前者は成功し、後者が失敗する場合、その差は IPv6 ルールセットにあります。
逆のケースは、セキュリティ上さらに危険です。IPV6=no の場合、ufw は ip6tables をまったく管理しないため、IPv6 のポリシーはカーネルのデフォルトである ACCEPT のままになります。閉じているはずのポートが IPv6 アドレスで応答し、ufw のコマンドにも表示されません。sudo ip6tables -S と ss -tlnp で確認し、全体像については ufw が IPv6 ポートを処理する仕組み を参照してください。
Docker のポートが ufw で拒否されているのに開いているのはなぜですか？
Docker は、nat テーブルに DNAT（宛先ネットワークアドレス変換）ルールを書き込み、FORWARD に独自のチェーンを挿入してポートを公開します。ufw のルールは INPUT の経路に配置されます。コンテナ宛てのトラフィックはホストに配信されるのではなく転送されるため、拒否ルールが配置されたチェーンには到達しません。ufw が有効で、すべての接続を拒否する設定でも、docker run -p 5432:5432 はインターネットから到達可能です。
sudo iptables -t nat -S DOCKER最も簡単な対策は、loopback にバインドして公開することです。-p 127.0.0.1:5432:5432 はホスト側を 127.0.0.1 にバインドするため、ufw の設定にかかわらず外部から到達できません。サービスを公開する必要がある場合の事例については、ufw を迂回して Docker のポートを公開するを参照してください。
ルールを適用する前にロールバックを予約する
これは、ファイアウォール運用を継続可能にする習慣です。リスクのある変更を行う前に、元に戻す処理を予約します。変更によって接続できなくなっても、5 分後にマシンが自動的に復旧するため、コンソールを開く必要はありません。
sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disablesystemd に Running timer as unit: ufw-rollback.timer と表示されます。ここで変更を行います。その後も新しい SSH セッションを開ける場合は、ロールバックをキャンセルします。
sudo systemctl stop ufw-rollback.timer新しいセッションを開けない場合は、そのまま待ちます。ufw は自動的に停止し、次の接続試行が成功します。ufw では、従来の shutdown -r +5 の方法は役に立ちません。ufw はブート時に同じルールセットを再度読み込むためです。
2 つ目の接続手段を確保する
- 必要になる前に 1 度プロバイダーのコンソールへログインし、パスワードが機能することを確認します。テストしていないコンソールはバックアップになりません。
- 独自の鍵を持つ 2 つ目の sudo ユーザーを用意します。これにより、1 つの
authorized_keysファイルが壊れてもアクセス手段を失わずに済みます。 - プロバイダーがパネル上で ufw とは別のネットワークファイアウォールを提供しているか確認します。同じポートをブロックするため、
ufw statusにはその設定が表示されません。 - アドレスが動的な場合、そのアドレスを
ufw allow from <your home address>の唯一の SSH ルールにしないでください。プロバイダーによってアドレスが夜間に変更され、アクセスできなくなります。
これらをすべて行う最も安価なタイミングは、新しいサーバーの初期設定を進めるときです。新しい VPS の最初の 10 分に行うほかの設定と併せて実施します。
拒否またはタイムアウトから障害が発生した層を特定する
Connection refusedは、パケットがサーバーに到達し、何らかのプロセスがTCPリセットを返したことを示します。ネットワーク経路には問題がないため、sshdが停止しているか、別のポートで待ち受けています。通常、ファイアウォールが原因である可能性は低いです。ufwはデフォルトで拒否ではなく破棄するためです。
Connection timed outは、何も応答が返らなかったことを示します。これは、ufw、プロバイダーのネットワークファイアウォール、または誤ったアドレスによってパケットが破棄された場合の典型的な状態です。この2つのエラーを正しく読み取れば、推測に1時間を費やさずに済みます。connection refusedとtimed outの違いで、残りのケースも確認できます。
次の変更を行う前にログを有効にする
sudo ufw logging on
sudo tail -f /var/log/ufw.logブロックされたパケットは次のように表示されます。
[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYNSRC= に自分のアドレスを指定した DPT=22 が表示されれば、ネットワークでも sshd でもなく、ufw が接続をブロックしている証拠です。rsyslog がない最小構成のイメージでは /var/log/ufw.log は存在せず、同じ行が sudo journalctl -k | grep UFW から出力されます。ufw は独自のログルールにレート制限を適用するため、行がないことはパケットが許可された証拠ではありません。
自分で追加していないルールが見つかった場合
ルールセットが勝手に変更されていたなら、ファイアウォールの問題ではありません。root 権限を持つ誰かが変更したということです。sudo grep ufw /var/log/auth.logを実行して、どの sudo コマンドがどのアカウントで実行されたかを確認します。続いて、lastでその時刻前後のログインを確認します。アカウントが把握している利用者と一致しない場合は、ファイアウォールの調査を続けず、VPS が侵害された場合のチェックリストを順に確認してください。他者に制御されているサーバーでファイアウォールを再有効化しても、問題が見えなくなるだけです。
原因を特定したら、ロックアウトを繰り返さない方法で ufw を再度有効にします。実際に使用している SSH ポートを許可し、ロールバックをスケジュールしてから ufw を有効にします。その後、別の端末から新しい SSH セッションを開始し、接続できることを確認します。その新しいセッションが確立するまでは、作業中のセッションを閉じないでください。ログは 1 日間有効にしておきます。ログを確認するほうが、user.rules を読むよりも、許可し忘れた内容をはるかに早く特定できるためです。
FAQ
ufw disableはルールを削除しますか？
いいえ。disableはカーネルからルールセットをアンロードし、ENABLED=noを/etc/ufw/ufw.confに書き込みます。ルールは/etc/ufw/user.rulesと/etc/ufw/user6.rulesに残り、ファイアウォールが無効な間もsudo ufw show addedで一覧表示できます。ルールを消去するコマンドはufw resetです。このコマンドは各ファイルを先にバックアップし、Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'のような行を出力します。
VPSを再起動するとufwのロックアウトは解除されますか？
いいえ。ufwは/etc/ufw/ufw.confのENABLED=yesからブート時に起動するため、同じルールがネットワークの起動前に読み込まれ、再びロックアウトされます。ufwを停止した後、またはレスキューモードでディスクをマウントしてそのファイルを編集した後であれば、再起動で解決できます。プロバイダーのコンソールを使用し、そこでsudo ufw disableを実行してください。
ufwがポートを拒否しているのに、Dockerコンテナへ接続できるのはなぜですか？
Dockerは、公開する各ポートに対して独自のDNATルールとFORWARDルールを書き込みます。そのトラフィックはホストに配信されず、コンテナへ転送されるため、ufwのdenyルールがあるINPUTチェーンを通りません。ホスト専用のポートには-p 127.0.0.1:5432:5432を使用してloopbackで公開し、Dockerが設定した内容をsudo iptables -t nat -S DOCKERで確認してください。
コンソールのパスワードがなく、レスキューモードもありません。どのような選択肢がありますか？
残る選択肢はプロバイダー側の対応です。通常はサーバーを再起動する、コントロールパネルからのパスワードリセットを依頼できます。また、ディスクを別のインスタンスに接続し、そこで/etc/ufw/ufw.confを編集する方法もあります。サーバーを再構築する前にサポートへ問い合わせてください。再構築すると、そのサーバー上のデータが失われます。復旧したらsudo passwd yournameを実行し、コンソールログインを1回テストしてください。次回ロックアウトされた場合でも、復旧にかかる時間を2分に抑えられます。