Di mana NAT VPN dalam before.rules UFW dan cara mengujinya

Peraturan NAT yang berfungsi apabila ditaip dalam shell gagal apabila ditampal ke dalam before.rules, kerana fail itu bukan skrip. Ia ialah dokumen berformat pemulihan dengan bahagian jadual, pengisytiharan rantai dan penanda COMMIT bagi setiap jadual. Baris di tempat yang salah sama ada membatalkan seluruh pemulihan atau membuang secara senyap peraturan yang anda sangka ada. Prosedur di bawah meletakkan serpihan di tempat yang dijangka oleh rangka kerja dan membuktikan hasilnya sebelum pemuatan semula seterusnya.

Arahan shell bukan fail pemulihan

Baris yang bermula dengan iptables -t nat ialah arahan kepada binari iptables, manakala fail yang dibaca UFW ialah penerangan satu set peraturan yang lengkap. Perbezaannya bukan kosmetik: format pemulihan mesti tahu di jadual mana ia berada, rantai mana yang wujud dan di mana jadual itu berakhir. Arahan yang ditampal ke dalam dokumen itu sama ada ralat sintaks atau, lebih teruk, peraturan yang dipasang pada jadual yang salah. Rangka kerja memuatkan fail ini melalui alat pemulihan semata-mata kerana ia bersifat deklaratif, bukan berjujukan.

Dokumen itu juga dimuatkan sebagai satu keseluruhan, jadi satu bahagian yang rosak boleh menghalang penerapan seluruh fail yang lain. Oleh itu kesilapan kecil dalam serpihan NAT turut menjatuhkan peraturan penapis, dan begitulah perubahan firewall menjadi gangguan.

Letakkan serpihan di dalam bahagian jadual sedia ada

Serpihan NAT mempunyai bentuk, dan bentuk lebih penting daripada teks peraturan di dalamnya. Pengepala jadual membuka bahagian itu, pengisytiharan rantai menetapkan pembilang, peraturan menyusul, dan COMMIT menutup bahagian itu.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Kumpulan dan antara muka di atas ialah pemegang tempat untuk nilai anda sendiri; strukturnya ialah bahagian yang wajar disalin. Jika fail sudah mengandungi bahagian *nat, tambahkan peraturan di dalam bahagian itu dan bukannya membuka yang kedua, kerana format menjangka satu COMMIT setiap jadual dan dua bahagian untuk jadual yang sama ialah pembaikan yang menunggu berlaku. Kekalkan definisi rantai pengedaran, termasuk yang ditambah oleh vendor untuk integrasinya sendiri. Manual rangka kerja UFW mendokumenkan fail before, user dan after bersama keperluan COMMIT yang sepadan.

Jika fail didapati kosong, jangan isinya daripada tutorial. Sahkan pakej mana yang memilikinya dan apakah dasar langsung sebenarnya, kerana fail kekal yang kosong tidak membuktikan kernel tidak menyimpan peraturan, dan set peraturan yang dimuatkan tidak membuktikan pemuatan semula seterusnya mempunyai fail lengkap untuk dibaca. Pulihkan garis dasar yang disokong dahulu, kemudian gunakan semula perubahan tapak di atasnya.

Uji calon tanpa menerapkannya

Alat pemulihan boleh menghuraikan dan membina set peraturan tanpa menerapkannya, dan ini ujian paling murah yang tersedia. Jalankannya pada salinan yang dilindungi dan bukan pada fail langsung, dan baca teks ralat dan bukan hanya status keluar. Kegagalan penghuraian menamakan baris dan biasanya jadual, yang lebih banyak daripada yang akan diberitahu oleh pemuatan semula yang 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 itu dihuraikan dan tidak lebih. Ia tidak membuktikan calon masih mengandungi setiap rantai yang bergantung pada UFW, bahawa ia hanya membenarkan sumber yang anda maksudkan, atau bahawa pentadbiran jauh kekal boleh dicapai. Itu semakan berasingan, dan yang terakhir wajar mendapat sesi kedua yang dibuka sebelum anda bermula.

Pilih alat yang sepadan dengan backend yang dipasang dan keluarga alamat. Hos yang menjalankan backend nft melalui lapisan keserasian memerlukan arahan yang sepadan, dan peraturan IPv6 tinggal dalam fail yang sama sekali berbeza.

Asingkan penerusan, NAT dan dasar akses

Terjemahan sumber menyelesaikan masalah pengalamatan dan tidak memberikan apa-apa. Penerusan ialah kebenaran berasingan yang dikawal oleh sysctl dan oleh jadual penapis, dan itulah yang orang lupa apabila terowong menghala tetapi tidak melepaskan trafik. Dasar akses ialah keputusan ketiga tentang sumber mana yang boleh mencapai perkhidmatan mana, dan tiada peraturan NAT menyatakannya. Memisahkan ketiga-tiganya itulah yang menjadikan kegagalan boleh didiagnosis dan bukannya satu gejala kabur.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Baca ketiga-tiga output itu bersama-sama, bukan satu demi satu. Peraturan masquerade dengan penerusan dimatikan menghasilkan klien yang bersambung dan tidak mencapai apa-apa, yang dari sisi klien kelihatan tepat seperti kerosakan penghalaan dan menghantar orang ke fail yang salah. Jadual penapis juga tempat accept yang terlalu luas bersembunyi, jadi semak dasar lalainya semasa anda di sana.

Sahkan pemuatan semula, penolakan dan kehilangan VPN

Tiga pemerhatian membentuk ujian penerimaan yang lengkap: pemuatan semula berjaya, operasi klien yang dibenarkan berfungsi, dan permintaan yang patut ditolak benar-benar ditolak. Yang ketiga itulah yang dilangkau, dan ia satu-satunya bukti bahawa dasar itu melakukan apa-apa.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Kemudian uji kegagalan yang anda reka. Jatuhkan terowong dan perhatikan apa yang dilakukan hos, kerana dasar yang hanya berfungsi semasa VPN hidup ialah dasar dengan kebergantungan yang tidak dinyatakan. Muat semula sekali lagi selepas itu untuk membuktikan bahawa fail, dan bukan keadaan berjalan yang tertinggal, yang menghasilkan hasil yang berfungsi.

NAT IPv4 tidak menyatakan apa-apa tentang IPv6, jadi nyatakan liputan yang dimaksudkan untuk kedua-dua keluarga dalam nota yang sama dengan peraturan. Matlamatnya ialah dasar terurus yang koheren, dan serpihan yang kebetulan dihuraikan bukanlah buktinya.