Di mana NAT VPN diletakkan di before.rules UFW dan cara mengujinya
Baris NAT di before.rules harus berada di dalam bagian tabel yang sah dengan COMMIT. Uji kandidat dengan iptables-restore --test sebelum memuat ulang UFW.
Aturan NAT yang berfungsi saat diketik di shell gagal saat ditempel ke before.rules, karena berkas itu bukan skrip. Berkas itu adalah dokumen berformat pemulihan dengan bagian tabel, deklarasi rantai, dan penanda COMMIT untuk setiap tabel. Baris di tempat yang salah entah membatalkan seluruh pemulihan atau diam-diam membuang aturan yang Anda yakini ada. Prosedur di bawah menempatkan fragmen di tempat yang diharapkan kerangka dan membuktikan hasilnya sebelum pemuatan ulang berikutnya.
Perintah shell bukan berkas pemulihan
Baris yang dimulai dengan iptables -t nat adalah instruksi bagi biner iptables, sedangkan berkas yang dibaca UFW adalah deskripsi kumpulan aturan lengkap. Perbedaannya bukan kosmetik: format pemulihan harus tahu di tabel mana ia berada, rantai mana yang ada, dan di mana tabel berakhir. Perintah yang ditempel ke dokumen itu entah kesalahan sintaksis atau, lebih buruk, aturan yang terpasang ke tabel yang salah. Kerangka memuat berkas-berkas ini melalui alat pemulihan justru karena bersifat deklaratif, bukan berurutan.
Dokumen juga dimuat sebagai satu kesatuan, sehingga satu bagian yang cacat dapat menghentikan penerapan bagian lain berkas. Karena itu kesalahan kecil pada fragmen NAT ikut menjatuhkan aturan filter, dan begitulah perubahan firewall menjadi gangguan.
Letakkan fragmen di dalam bagian tabel yang ada
Fragmen NAT memiliki bentuk, dan bentuk lebih penting daripada teks aturan di dalamnya. Tajuk tabel membuka bagian, deklarasi rantai menetapkan penghitung, aturan menyusul, dan COMMIT menutup bagian.
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT
Kumpulan dan antarmuka di atas adalah placeholder untuk milik Anda; strukturnya adalah bagian yang layak disalin. Jika berkas sudah memuat bagian *nat, tambahkan aturan di dalam bagian itu alih-alih membuka bagian kedua, karena format mengharapkan satu COMMIT per tabel dan dua bagian untuk tabel yang sama adalah perbaikan yang menunggu terjadi. Pertahankan definisi rantai distribusi, termasuk yang ditambahkan vendor untuk integrasinya sendiri. Panduan kerangka UFW mendokumentasikan berkas before, user, dan after beserta persyaratan COMMIT yang cocok.
Jika berkas ternyata kosong, jangan mengisinya dari tutorial. Pastikan paket mana yang memilikinya dan apa kebijakan aktif sebenarnya, karena berkas persisten yang kosong tidak membuktikan kernel tidak menyimpan aturan, dan kumpulan aturan yang dimuat tidak membuktikan pemuatan ulang berikutnya memiliki berkas lengkap untuk dibaca. Pulihkan dulu garis dasar yang didukung, lalu terapkan kembali perubahan situs di atasnya.
Uji kandidat tanpa menerapkannya
Alat pemulihan dapat mengurai dan membangun kumpulan aturan tanpa menerapkannya, yang merupakan uji termurah yang tersedia. Jalankan pada salinan yang dilindungi, bukan pada berkas aktif, dan baca teks kesalahan, bukan hanya status keluar. Kegagalan penguraian menyebut baris dan biasanya tabel, yang lebih banyak daripada yang akan dikatakan pemuatan ulang gagal.
sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"
Lulus pemeriksaan itu membuktikan dokumen dapat diurai dan tidak lebih. Itu tidak membuktikan kandidat masih memuat setiap rantai yang menjadi sandaran UFW, bahwa hanya sumber yang Anda maksud yang diizinkan, atau bahwa administrasi jarak jauh tetap dapat dijangkau. Itu adalah tinjauan terpisah, dan yang terakhir layak mendapat sesi kedua yang dibuka sebelum Anda mulai.
Pilih alat yang sesuai dengan backend terpasang dan keluarga alamat. Host yang menjalankan backend nft melalui lapisan kompatibilitas memerlukan perintah yang sesuai, dan aturan IPv6 berada di berkas yang sama sekali berbeda.
Pisahkan penerusan, NAT, dan kebijakan akses
Penerjemahan sumber menyelesaikan masalah pengalamatan dan tidak memberikan apa pun. Penerusan adalah izin terpisah yang dikendalikan oleh sysctl dan oleh tabel filter, dan itulah yang orang lupakan ketika terowongan merutekan tetapi tidak melewatkan lalu lintas. Kebijakan akses adalah keputusan ketiga tentang sumber mana yang boleh mencapai layanan mana, dan tidak ada aturan NAT yang mengungkapkannya. Memisahkan ketiganya itulah yang membuat kegagalan dapat didiagnosis alih-alih satu gejala samar.
sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD
Baca ketiga keluaran itu bersama-sama, bukan satu per satu. Aturan masquerade dengan penerusan dimatikan menghasilkan klien yang terhubung dan tidak mencapai apa pun, yang dari sisi klien tampak persis seperti kesalahan perutean dan mengirim orang ke berkas yang salah. Tabel filter juga tempat accept yang terlalu luas bersembunyi, jadi periksa kebijakan bawaannya saat Anda di sana.
Verifikasi pemuatan ulang, penolakan, dan kehilangan VPN
Tiga pengamatan membentuk uji penerimaan lengkap: pemuatan ulang berhasil, operasi klien yang diizinkan berfungsi, dan permintaan yang seharusnya ditolak benar-benar ditolak. Yang ketiga itulah yang dilewati, dan itu satu-satunya bukti bahwa kebijakan melakukan sesuatu.
sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v
Lalu uji kegagalan yang Anda rancang. Jatuhkan terowongan dan amati apa yang dilakukan host, karena kebijakan yang hanya berfungsi selama VPN menyala adalah kebijakan dengan ketergantungan yang tidak dinyatakan. Muat ulang sekali lagi sesudahnya untuk membuktikan bahwa berkas, bukan keadaan berjalan yang tersisa, yang menghasilkan hasil yang berfungsi.
NAT IPv4 tidak mengatakan apa pun tentang IPv6, jadi nyatakan cakupan yang dimaksud untuk kedua keluarga dalam catatan yang sama dengan aturan. Kebijakan terkelola yang koheren adalah tujuannya, dan fragmen yang kebetulan dapat diurai bukan buktinya.