Haruskah Anda menerapkan SNAT pada penerusan port ke subnet VPN?

Meneruskan port ke host yang berada di belakang klien VPN router itu sendiri gagal dengan cara yang tampak seperti masalah firewall, karena permintaannya jelas tiba. Layanan mencatat koneksi, klien menunggu, dan tidak ada yang kembali. Terjemahan tujuan melakukan tugasnya; paket balasan adalah bagian yang hilang. Satu aturan NAT sumber yang selektif di router memperbaikinya, dan bagian menariknya adalah memutuskan seberapa sempit aturan itu bisa dibuat.

Mengapa balasannya mengambil jalur lain

Penerusan port menulis ulang ke mana paket pergi, tidak pernah dari mana asalnya. Alamat klien internet tetap di kolom sumber sepanjang perjalanan melalui terowongan, sehingga layanan jauh melihat orang asing dan menjawab dengan satu-satunya cara yang diketahuinya: melalui gateway bawaannya sendiri. Gateway itu adalah konsentrator VPN di sisi jauh, yang tidak punya rute kembali ke alamat publik sembarang.

Amati tangkapan pada antarmuka terowongan dan asimetrinya jelas: paket permintaan keluar, tidak ada yang masuk. Rantai penerusan mengizinkan aliran dan terowongan membawanya, jadi penurunan terjadi setelah host jauh sudah memilih jalur kembali.

Aturan sumber yang cukup sempit untuk dipercaya

Jadikan router sebagai sumber yang dijawab oleh host jauh. Dalam tata letak ini alamat WAN adalah 203.0.113.24, LAN adalah 192.168.88.0/24, alamat terowongan router adalah 172.20.5.1, dan layanan menjawab di 172.20.5.40:8443. Aturan di bawah cocok dengan paket setelah terjemahan tujuan, itulah sebabnya aturan itu menyebut alamat yang diterjemahkan, bukan alamat publik. Tidak ada yang bergantung pada alamat klien, dan justru itulah intinya.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Setiap kecocokan di baris itu ada untuk menjaga penulisan ulang tetap lokal pada satu layanan di satu terowongan. Hapus antarmuka atau portnya dan Anda menulis ulang lebih banyak lalu lintas daripada yang dibutuhkan masalah, dan begitulah perbaikan yang tertarget berubah menjadi misteri bagi orang berikutnya.

Kapan masquerade menyeluruh adalah pilihan jujur

Jika router meneruskan banyak layanan ke subnet VPN yang sama, aturan per layanan menjadi daftar yang tidak dirawat siapa pun. Menyamarkan semua yang keluar dari antarmuka terowongan lebih sederhana dan dapat diprediksi, dengan biaya menyembunyikan klien asli dari setiap host di sisi jauh. Pilih itu bila log di sana tidak dipakai untuk atribusi; pertahankan aturan sempit bila dipakai.

Kedua opsi juga gagal dengan cara berbeda. Aturan sempit yang hilang merusak satu layanan; masquerade luas yang cocok terlalu banyak dapat diam-diam menulis ulang lalu lintas yang sudah berfungsi, termasuk koneksi keluar router itu sendiri.

Periksa penghitung sebelum menerbitkan

Aturan yang tidak pernah cocok terlihat sama dengan aturan yang berfungsi sampai Anda menghitung paket. Baca kembali tabel dengan penghitung byte sebelum klien mana pun terhubung, lalu hubungkan dari jaringan yang bukan LAN dan baca lagi. Dua pembacaan itulah yang mengubah dugaan menjadi fakta. Terbitkan penerusan hanya setelah yang kedua bergerak.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Penghitung nol pada aturan sumber setelah koneksi nyata berarti kecocokannya salah, biasanya karena tujuan atau port tidak cocok dengan paket setelah terjemahan. Jika penghitung naik tetapi klien masih kehabisan waktu, jalur kembali sudah diperbaiki dan ada hal lain yang menjatuhkan balasannya, jadi lihat kebijakan penerusan di sisi jauh berikutnya. Akses hairpin dari dalam LAN adalah masalah terpisah dan perlu aturannya sendiri, bukan versi yang lebih luas dari aturan ini.