Sakelar mati UFW memblokir VPN Anda? Izinkan peer

Anda mengikuti daftar periksa: tolak keluar, izinkan terowongan, aktifkan ufw. Lalu klien menunggu di handshake dan tidak pernah terhubung, atau terhubung dan tidak ada halaman yang dimuat. Kedua kegagalan berasal dari celah yang sama. Aturan yang memungkinkan terowongan ada tidak ada, karena terowongan bukan antarmuka tempat paket Anda keluar.

Mengapa izin pada tun0 awalnya tidak cocok dengan apa pun

tun0 dibuat oleh klien setelah sesi ada. Datagram yang membangun sesi itu adalah paket UDP biasa yang ditujukan ke penyedia di port 1194, dan keluar melalui wlan0 atau eth0 dengan alamat sumber fisik. allow out on tun0 hanya cocok dengan lalu lintas yang antarmuka keluarnya tun0, jadi selama handshake tidak cocok dengan apa pun.

Pasang default deny outgoing di atasnya dan paket luar dibuang sebelum antarmuka muncul. Klien mencoba lagi, kehabisan waktu, dan melaporkan kegagalan TLS atau handshake, yang membuat orang berburu di sertifikat dan MTU sementara firewall diam-diam memakan koneksi. Aturan yang dimaksudkan menahan lalu lintas Anda justru mencegah lalu lintas itu ditahan.

Perbaikan refleks membuat kebocoran permanen. sudo ufw allow out on wlan0, atau mengembalikan default ke izinkan, menaikkan terowongan dan meninggalkan mesin tanpa sakelar mati: lain kali terowongan jatuh, semuanya berlanjut lewat adaptor fisik. Saya kehilangan satu sore justru pada pasangan perubahan itu sebelum mengetahui paket mana yang sebenarnya saya saring.

Apa yang dibutuhkan dua rangkaian paket

Lalu lintas Anda melewati firewall dua kali, dalam dua bentuk. Paket dalam berjalan dari alamat terowongan keluar melalui tun0. Paket luar berjalan dari alamat fisik ke peer, dan hanya itulah yang terlihat di kabel. Satu aturan per bentuk:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Ganti alamat dan port dengan yang dari profil Anda sendiri. Peer WireGuard biasanya menjawab di 51820/udp; profil OpenVPN yang lewat TCP 443 membutuhkan port itu. Detailnya berbeda, bentuknya tidak: kedua aturan sempit, dan bersama-sama keduanya menentukan satu-satunya tujuan yang dapat dijangkau mesin saat terowongan mati.

Urutan adalah mitos kedua. Dengan iptables mentah Anda membaca rantai dari atas ke bawah dan menalar aturan mana yang menang. ufw bukan pembungkus tipis daftar yang Anda ketik; ia mengompilasi aturan Anda ke rantainya sendiri dan memilih titik penyisipan. ufw status mencetaknya dalam urutan ufw, bukan urutan Anda. Saat aturan tampak diabaikan, bandingkan ufw show added dengan kumpulan terkompilasi dari iptables -S | grep ufw sebelum menulis ulang apa pun.

Pengecualian harus tetap selebar satu alamat

Aturan peer hanya benar selama ia menyebut alamat yang didial klien. Penyedia memutar endpoint, dan profil yang menyelesaikan nama host akan mengikuti perubahan DNS ke alamat baru sementara aturan tetap menunjuk ke yang lama. Saat terowongan yang berfungsi berbulan-bulan berhenti naik, bandingkan alamat dalam aturan dengan yang dicari klien sebelum memperluas apa pun.

Memperluas ke seluruh subnet, atau ke setiap tujuan di port 1194, mengubah kebijakan kembali menjadi firewall berlubang. Pengecualiannya adalah sakelar mati; begitu lebar, tidak ada lagi yang bisa dimatikan. Pertahankan pada satu alamat dan tinggalkan komentar yang menyebut profil dan penyedia pemiliknya, karena enam bulan lagi alamat itu akan tampak sembarangan.

Resolusi nama pantas mendapat barisnya sendiri. Pencarian terjadi sebelum terowongan ada, melalui antarmuka fisik, jadi kebijakan tolak-keluar yang ketat dapat membuat klien tidak dapat menemukan servernya sendiri. Izinkan port 53 ke alamat resolver Anda, atau selesaikan sekali dan patok alamatnya di profil. Mengizinkan DNS di setiap antarmuka adalah keputusan, bukan default.

Bangun kebijakan sebelum terowongan dibutuhkan

ufw enable menerapkan seluruh kebijakan sekaligus dan memuat ulang rantainya, dan mengubah kebijakan default pada firewall yang berjalan juga memuat ulangnya. manual ufw memperingatkan bahwa ini dapat memutus koneksi yang ada seperti SSH. Jadi perintahnya berjalan dalam urutan ini, dengan aturan SSH sebelum pengaktifan dan sesi konsol terbuka:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset sengaja ditinggalkan dari blok itu. Ia menghapus setiap aturan dan menonaktifkan firewall, dan pada host jarak jauh pengaktifan berikutnya itulah yang memutus sesi Anda. Jika Anda tetap mengatur ulang, tambahkan aturan SSH dan pastikan jalur kedua untuk masuk kembali melalui konsol sebelum melanjutkan.

Urutannya bukan kosmetik. Aturan yang ditambahkan saat ufw berjalan tidak membuang apa pun, tetapi saat Anda membalik kebijakan default, rantainya dimuat ulang, dan sesi yang diizinkan kebijakan lama ikut pergi. Lakukan default, izin, dan pengaktifan dalam satu kali jalan, selama Anda masih punya jalur masuk yang tidak bergantung pada mesin.

Uji keadaan terblokir, dan simpan pembatalannya

Sakelar mati yang belum diuji hanyalah dugaan. Putuskan klien dengan sengaja dan coba muat halaman: itu harus gagal. Sambungkan lagi dan itu harus pulih tanpa menyentuh aturan. sudo ufw status verbose mengonfirmasi default dan status pencatatan, dan ufw status numbered menunjukkan aturan uji mana yang harus dihapus saat ia melewati tujuannya.

Simpan skrip kebalikannya di samping yang maju. Mesin dengan tolak-keluar dan terowongan mati tidak dapat mengunduh perbaikannya sendiri, jadi pembatalan harus ada di disk dan dapat dibaca dari konsol:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Jalankan saat terowongan sudah mati dan aturannya harus dicabut, bukan sebagai langkah rutin. Sebelum menutup terminal, empat hal harus terpenuhi: aturan peer menyebut tepat satu alamat, DNS punya pengecualian bernama, pengaktifan datang setelah izin, dan mencabut terowongan mematikan lalu lintas biasa tanpa mematikan klien selamanya.