Cara pulihkan akses selepas ufw menyekat SSH

Dapatkan semula akses

Jika ufw telah menyekat akses anda ke VPS, cara untuk masuk semula adalah melalui konsol pembekal atau mod penyelamat (rescue mode), kerana tiada penyelesaian berasaskan SSH yang wujud sebaik sahaja peraturan sekatan itu aktif. Kernel akan menggugurkan paket anda sebelum sshd sempat menerimanya, jadi tiada apa untuk dilog masuk dan tiada apa yang boleh dibaiki melalui rangkaian. Buka konsol dalam panel kawalan pembekal anda, log masuk pada prompt tersebut, dan jalankan satu arahan ini.

sudo ufw disable

Anda sepatutnya melihat Firewall stopped and disabled on system startup. Sambungan SSH baharu akan berfungsi semula dalam masa satu atau dua saat. Tiada konfigurasi anda yang hilang: disable akan memunggah peraturan daripada kernel dan menulis ENABLED=no ke dalam /etc/ufw/ufw.conf, sementara peraturan anda kekal tersimpan dalam cakera di /etc/ufw/user.rules, menunggu ufw enable yang seterusnya.

Jangan but semula (reboot) dengan harapan masalah selesai. ufw akan bermula sendiri semasa but, jadi ENABLED=yes bermaksud set peraturan yang sama akan dimuatkan semula sebelum rangkaian aktif. But semula tidak mengubah apa-apa tentang sekatan ufw.

Konsol memerlukan kata laluan yang mungkin tidak anda miliki

Konsol web (VNC atau bersiri) berfungsi seperti papan kekunci yang disambungkan terus ke mesin. Ia bukan laluan rangkaian, jadi tiada peraturan firewall yang boleh menyekatnya. Ia memerlukan log masuk tempatan, dan di sinilah persediaan yang hanya menggunakan kunci (key-only) sering gagal: jika anda tidak pernah menetapkan kata laluan untuk pengguna sudo anda, dan log masuk root dikunci, konsol akan memaparkan gesaan yang tidak dapat anda jawab. Tetapkan kata laluan tersebut sekarang, sementara anda masih mempunyai akses SSH: sudo passwd yourname. Kebanyakan panel kawalan juga boleh menetapkan semula kata laluan root, yang biasanya memaksa sistem untuk but semula (reboot).

Jika konsol tidak boleh digunakan, but sistem penyelamat (rescue system) pembekal anda. Ia menjalankan sistem pengendalian berasingan dengan cakera anda dinyahlekap (unmounted), jadi anda boleh mematikan ufw dari luar.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Jalankan lsblk terlebih dahulu, kerana partition root tidak selalunya /dev/vda1. But semula ke sistem biasa dan ufw akan kekal mati sehingga anda mengaktifkannya secara manual.

Urutan pemulihan minimum

Lakukan langkah mengikut urutan ini. Empat langkah pertama adalah selamat. Langkah selepas itu tidak selamat.

1. sudo ufw disable untuk membuang peraturan dan mendapatkan semula akses anda.
2. sudo ufw show added untuk mencetak peraturan yang telah anda tambah, dalam bentuk arahan yang menambahnya. Ini berfungsi semasa ufw tidak aktif, yang tidak dapat dilakukan oleh ufw status.
3. sudo sshd -T | grep -i '^port' untuk mengesahkan port yang sebenarnya didengar oleh sshd. Ia mencetak port 22 melainkan anda telah mengubahnya.
4. sudo ufw allow 22/tcp, menggunakan port sebenar anda, supaya pengaktifan seterusnya tidak mengulangi kegagalan akses.
5. sudo ufw enable, dengan penjadualan rollback dilakukan terlebih dahulu. Perkara ini diterangkan dengan lebih lanjut di bawah halaman ini.

Apakah yang sebenarnya dilakukan oleh ufw reset

ufw reset ialah langkah terakhir, bukan langkah pertama. Ia menyahaktifkan firewall, menyandarkan setiap fail peraturan, dan menetapkan semula lalai kepada deny untuk trafik masuk serta allow untuk trafik keluar. Ia mencetak satu baris sandaran bagi setiap fail:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Selepas tetapan semula, anda tidak mempunyai sebarang peraturan allow, jadi jalankan arahan ini daripada konsol dan bukannya melalui SSH, serta tambahkan peraturan SSH sebelum anda mengaktifkannya semula. Sandaran tersebut adalah dalam bentuk teks biasa. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 menunjukkan peraturan lama anda, yang merupakan cara untuk membina semula set peraturan yang anda tidak berniat untuk hapuskan.

Lokasi penyimpanan peraturan ufw

Membaca fail adalah lebih tepat daripada bergantung pada ingatan. Lima laluan menyimpan keseluruhan keadaan sistem:

• /etc/ufw/user.rules dan /etc/ufw/user6.rules: peraturan yang anda tambah, mengikut urutan ia dinilai.
• /etc/ufw/before.rules dan /etc/ufw/after.rules, serta varian 6: rangka kerja yang dibalut oleh ufw di sekeliling peraturan anda, termasuk kebenaran untuk sambungan yang telah diwujudkan dan peraturan loopback.
• /etc/default/ufw: polisi lalai dan suis IPV6.
• /etc/ufw/ufw.conf: ENABLED dan tahap log.
• /var/log/ufw.log: perkara yang disekat, setelah pengelogan diaktifkan.

ufw menulis salinan fail bertanda masa sebelum ia menulis semula fail tersebut, jadi ls /etc/ufw/ akan dipenuhi dengan nama seperti user.rules.20260813_101500. Itu adalah sejarah buat asal (undo) anda, dan ia wajar dibaca sebelum anda mula mengubah semula tetapan.

Untuk melihat perkara yang dimuatkan dalam kernel dan bukannya perkara yang terdapat pada cakera, gunakan sudo ufw show raw, atau sudo iptables -S dan sudo ip6tables -S. Pada Ubuntu 22.04 dan 24.04, arahan tersebut adalah versi yang disokong oleh nft, jadi sudo nft list ruleset akan mencetak peraturan yang sama dalam sintaks yang lebih baharu.

Mengapa mendayakan ufw memutuskan sesi SSH saya?

Polisi lalai untuk trafik masuk adalah deny. Mendayakan ufw tanpa peraturan untuk port SSH anda akan menyekat setiap sambungan baharu. ufw memang memberikan amaran: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Menjawab y tanpa peraturan allow untuk SSH adalah punca paling biasa bagi semua masalah di halaman ini.

Bahagian yang mengelirukan ialah kelewatan tersebut. /etc/ufw/before.rules menerima paket dalam status ESTABLISHED,RELATED sebelum peraturan anda sendiri sampai, jadi sesi tempat anda menaip arahan tersebut terus berfungsi seperti biasa. Sekatan hanya muncul pada sambungan seterusnya, yang mungkin berlaku beberapa jam kemudian, dan pada waktu itu perubahan firewall tidak lagi dirasakan berkaitan. Sentiasa buka sesi SSH kedua dan sahkan ia berfungsi sebelum anda menutup sesi yang pertama.

Mengapa apt dan DNS berhenti berfungsi selepas perubahan polisi?

sudo ufw default deny outgoing menyekat pertanyaan DNS (domain name system) keluar dan HTTP keluar, jadi resolusi nama gagal dan kemas kini pakej terhenti. apt update melaporkan Temporary failure resolving 'archive.ubuntu.com'. SSH masuk masih berfungsi, kerana balasan kepadanya adalah ESTABLISHED dan melepasi peraturan rangka kerja, yang menjadikan firewall kelihatan tidak bersalah sedangkan ia adalah puncanya.

Jika anda mahukan polisi deny outgoing, buka apa yang sebenarnya diperlukan oleh mesin tersebut:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Tanpa peraturan terakhir, jam akan tersasar, dan jam yang salah akan merosakkan pengesahan sijil TLS (transport layer security), jadi curl mula gagal pada tarikh dan bukannya pada port. Gejala itu muncul beberapa hari selepas perubahan, itulah sebabnya deny outgoing adalah polisi untuk mesin yang anda pantau, bukan untuk kotak yang anda sediakan sekali sahaja.

Mengapa peraturan ufw saya tidak pernah sepadan?

ufw menilai peraturan pengguna mengikut urutan dan berhenti pada padanan pertama. deny yang ditambah selepas allow yang lebih umum tidak akan pernah berfungsi, kerana tindakan allow telah pun menentukan nasib paket tersebut. Paparkan urutan dengan nombor, kemudian masukkan peraturan di posisi yang diperlukan.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp memaparkan peraturan yang akan ditulis tanpa membuat sebarang perubahan. Ini adalah cara selamat untuk membaca peraturan sebelum ia dikuatkuasakan.

Satu lagi perangkap terletak pada profil aplikasi. sudo ufw allow OpenSSH menggunakan profil dalam /etc/ufw/applications.d/openssh-server, dan profil tersebut merujuk kepada port 22. Jika sshd mendengar pada port 2222, peraturan tersebut membuka port yang tidak digunakan oleh sesiapa dan menyebabkan anda terkunci keluar dengan set peraturan yang kelihatan betul. Gunakan nombor port setelah anda menukar port tersebut. Selebihnya sintaks diterangkan dalam asas firewall ufw untuk VPS.

Mengapa peraturan IPv4 tidak menjelaskan apa yang saya lihat?

Ini kerana separuh daripada trafik bukan IPv4. Ubuntu menyertakan IPV6=yes dalam /etc/default/ufw, dan ufw kemudian mengekalkan set peraturan v6 selari dalam /etc/ufw/user6.rules. Peraturan yang ditulis dengan alamat IPv4, seperti ufw allow from 203.0.113.10 to any port 22, tidak mencipta sebarang peraturan v6. Jika VPS anda mempunyai rekod AAAA, klien anda lebih mengutamakan IPv6, dan sambungan anda tamat masa (timeout) sementara ufw status menunjukkan peraturan yang kelihatan betul. Uji perbezaan tersebut dengan ssh -4 user@host terhadap ssh -6 user@host. Jika yang pertama berfungsi dan yang kedua tidak, jurang tersebut adalah set peraturan v6.

Kes sebaliknya lebih buruk untuk keselamatan. Dengan IPV6=no, ufw tidak mengurus ip6tables langsung, jadi polisi v6 kekal pada tetapan lalai kernel iaitu ACCEPT. Port yang anda sangka tertutup akan menjawab pada alamat IPv6-nya, dan tiada arahan ufw yang akan menyebutnya. Semak dengan sudo ip6tables -S dan ss -tlnp, dan baca bagaimana ufw mengendalikan port IPv6 untuk gambaran penuh.

Mengapa port Docker terbuka sedangkan ufw menafikannya?

Docker menerbitkan port dengan menulis peraturan DNAT (destination network address translation) ke dalam jadual nat dan memasukkan chain miliknya sendiri ke dalam FORWARD. Peraturan ufw berada dalam laluan INPUT. Trafik ke kontena diforward dan bukannya dihantar ke hos, jadi trafik tersebut tidak pernah sampai ke chain yang mengandungi peraturan deny anda. docker run -p 5432:5432 boleh dicapai dari internet walaupun ufw aktif dan menafikan segala-galanya.

sudo iptables -t nat -S DOCKER

Penyelesaian paling mudah adalah dengan menerbitkan pada loopback: -p 127.0.0.1:5432:5432 mengikat bahagian hos kepada 127.0.0.1, dan tiada apa-apa dari luar boleh mencapainya walau apa pun yang ditetapkan oleh ufw. Docker menerbitkan port di sekeliling ufw membincangkan kes di mana servis tersebut memang perlu diakses secara awam.

Jadualkan rollback sebelum anda menggunakan peraturan

Ini adalah tabiat yang menjadikan pengurusan firewall lebih selamat. Sebelum melakukan sebarang perubahan berisiko, jadualkan proses pembatalan (undo). Jika perubahan tersebut menyebabkan anda terkunci keluar, mesin akan pulih sendiri dalam masa lima minit dan anda tidak perlu membuka konsol fizikal.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd akan mencetak Running timer as unit: ufw-rollback.timer. Sekarang, buat perubahan anda. Jika anda masih boleh membuka sesi SSH baharu selepas itu, batalkan rollback tersebut:

sudo systemctl stop ufw-rollback.timer

Jika anda tidak dapat membuka sesi tersebut, tunggu sahaja. ufw akan berhenti dengan sendirinya dan percubaan seterusnya akan berjaya disambungkan. Trik klasik shutdown -r +5 tidak membantu dengan ufw, kerana ufw akan memuatkan semula set peraturan yang sama semasa but.

Sediakan laluan akses kedua

• Log masuk ke konsol pembekal sekali, sebelum anda memerlukannya, dan sahkan kata laluan berfungsi. Konsol yang tidak pernah anda uji bukanlah sandaran.
• Kekalkan pengguna sudo kedua dengan kunci tersendiri, supaya satu fail authorized_keys yang rosak tidak menamatkan akses anda.
• Semak sama ada pembekal anda menjalankan firewall rangkaian dalam panel, berasingan daripada ufw. Ia menyekat port yang sama, dan ufw status tidak akan memaklumkan perkara tersebut.
• Jangan jadikan ufw allow from <your home address> satu-satunya peraturan SSH anda jika alamat tersebut bersifat dinamik. Pembekal anda mungkin menukarnya pada waktu malam dan anda akan kehilangan akses.

Masa paling jimat untuk melakukan semua ini adalah pada pelayan baharu, bersama-sama dengan kerja penyediaan lain dalam sepuluh minit pertama pada VPS baharu.

Ralat refused atau timed out menunjukkan lapisan mana yang gagal

Connection refused bermaksud paket sampai ke pelayan dan sesuatu menghantar semula TCP reset. Laluan rangkaian adalah baik, jadi sshd mungkin dihentikan atau mendengar pada port yang berbeza. Firewall jarang menjadi punca, kerana ufw secara lalai akan melakukan drop dan bukannya reject.

Connection timed out bermaksud tiada maklum balas diterima langsung. Ini adalah tanda bagi tindakan drop: ufw, firewall rangkaian penyedia, atau alamat yang salah. Membaca kedua-dua ralat ini dengan betul menjimatkan masa daripada meneka, dan perbezaan antara connection refused dan timed out akan menghuraikan kes-kes yang selebihnya.

Hidupkan pengelogan sebelum perubahan seterusnya

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Paket yang disekat akan kelihatan seperti ini:

[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 SYN

DPT=22 dengan alamat anda sendiri dalam SRC= adalah bukti bahawa ufw yang menyekat anda, bukannya rangkaian atau sshd. Pada imej minimum tanpa rsyslog, tiada /var/log/ufw.log, dan baris yang sama datang daripada sudo journalctl -k | grep UFW. ufw mengehadkan kadar peraturan pengelogannya sendiri, jadi baris yang hilang bukanlah bukti bahawa sesuatu paket telah dibenarkan.

Jika anda menemui peraturan yang tidak pernah anda tambah

Set peraturan yang berubah dengan sendirinya bukanlah masalah firewall. Seseorang yang mempunyai akses root telah menulisnya. Jalankan sudo grep ufw /var/log/auth.log untuk melihat arahan sudo yang dijalankan dan di bawah akaun yang mana, kemudian last untuk melihat log masuk sekitar cap masa tersebut. Jika akaun tersebut tidak sepadan dengan sesiapa yang anda kenali, hentikan penyahpepijatan firewall dan lakukan senarai semak VPS yang telah diceroboh sebagai gantinya. Mengaktifkan semula firewall pada kotak yang dikawal oleh orang lain hanya menyembunyikan masalah tersebut.

Mengembalikan konfigurasi asal

Setelah anda mengetahui puncanya, aktifkan semula ufw dengan cara yang tidak akan menyebabkan anda terkunci lagi. Benarkan port SSH sebenar anda, jadualkan proses rollback, aktifkan ufw, kemudian buka sesi SSH baharu daripada terminal lain dan sahkan sambungan tersebut berjaya. Hanya selepas sesi baharu itu aktif, barulah anda menutup sesi yang sedang digunakan. Biarkan fungsi log aktif selama sehari, kerana log tersebut memberitahu anda perkara yang terlupa dibenarkan dengan lebih pantas berbanding membaca user.rules.

FAQ

Adakah ufw disable memadamkan peraturan saya?

Tidak. disable memunggah set peraturan daripada kernel dan menulis ENABLED=no ke dalam /etc/ufw/ufw.conf. Peraturan anda kekal dalam /etc/ufw/user.rules dan /etc/ufw/user6.rules, dan sudo ufw show added menyenaraikannya semasa firewall tidak aktif. ufw reset ialah perintah yang membersihkannya, dan ia membuat sandaran setiap fail terlebih dahulu, dengan mencetak baris seperti Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Adakah but semula VPS saya akan membatalkan sekatan ufw?

Tidak. ufw bermula semasa but daripada ENABLED=yes dalam /etc/ufw/ufw.conf, jadi peraturan yang sama dimuatkan sebelum rangkaian diaktifkan dan anda akan disekat semula. But semula hanya membantu selepas anda mematikan ufw, atau selepas anda menyunting fail tersebut daripada mod penyelamat (rescue mode) dengan cakera yang telah dilekapkan (mounted). Gunakan konsol pembekal dan jalankan sudo ufw disable di sana.

Mengapa kontena Docker saya boleh dicapai apabila ufw menafikan port tersebut?

Docker menulis peraturan DNAT dan FORWARD miliknya sendiri bagi setiap port yang diterbitkan. Trafik tersebut dihantar ke kontena dan bukannya dihantar ke hos, jadi ia tidak pernah melalui rantaian INPUT di mana peraturan deny ufw anda berada. Terbitkan pada loopback dengan -p 127.0.0.1:5432:5432 apabila port tersebut hanya untuk hos, dan periksa perkara yang dipasang oleh Docker dengan sudo iptables -t nat -S DOCKER.

Saya tiada kata laluan konsol dan tiada mod penyelamat. Apakah pilihan saya?

Pilihan yang tinggal bergantung kepada pembekal anda: tetapan semula kata laluan daripada panel kawalan, yang biasanya memulakan semula pelayan, atau melampirkan cakera ke instans lain supaya anda boleh menyunting /etc/ufw/ufw.conf dari sana. Tanya sokongan teknikal sebelum anda membina semula pelayan, kerana pembinaan semula akan memusnahkan data di dalamnya. Sebaik sahaja anda kembali masuk, jalankan sudo passwd yourname dan uji log masuk konsol sekali, supaya sekatan seterusnya hanya mengambil masa dua minit untuk diselesaikan.