SNAT, DNAT, dan Masquerade: apa yang dilakukan setiap aturan NAT VPN

Pasang tangkapan di kedua sisi gateway VPN dan satu aliran bisa menunjukkan empat alamat berbeda. NAT sumber menulis ulang dari mana paket mengaku datang; NAT tujuan menulis ulang ke mana ia pergi. Masquerade bukan arah ketiga, ia adalah aturan NAT sumber yang mengambil alamatnya dari antarmuka keluar alih-alih nilai tetap. Sebutkan mana dari ketiganya yang benar-benar Anda butuhkan dan sebagian besar tiket „VPN rusak“ menyusut menjadi pertanyaan tentang jalur balik.

Apa yang ditulis ulang setiap aturan

NAT sumber, biasanya ditulis SNAT, mengubah alamat sumber suatu aliran saat keluar dari router atau gateway. Layanan penerima membalas ke alamat yang diterjemahkan, dan kotak yang menerjemahkan membalik perubahan itu memakai keadaan yang disimpannya untuk koneksi tersebut. Di Linux keadaan itu hidup di conntrack, karena itu conntrack -L mencetak tuple asli dan balasan berdampingan.

NAT tujuan, DNAT, mengubah tujuan sebagai gantinya. Paket yang dialamatkan ke alamat publik pada UDP 51820 dapat ditulis ulang ke server WireGuard internal di 10.8.0.2:51820. Begitulah router rumah atau penyeimbang beban cloud memublikasikan pendengar VPN, dan itu tidak mengatakan apa pun tentang apa yang boleh dibawa terowongan sesudahnya.

Masquerade termasuk keluarga SNAT. Aturan itu tidak menyebut alamat; ia memakai alamat apa pun yang dipegang antarmuka keluar saat paket pergi. Linux memberinya target sendiri, dan itu pilihan biasa pada antarmuka WAN yang mendapat alamatnya dari DHCP atau PPPoE.

Di mana pemetaan hidup menentukan kegagalan

Catat tuple di setiap batas: sebelum terowongan, di dalamnya, dan pada antarmuka publik. Tangkapan di dalam terowongan sah berbeda dari yang di luarnya, dan siapa pun yang membandingkan keduanya tanpa tahu di mana terjemahan terjadi akan mengejar host yang salah.

Lalu lintas balik harus melewati perangkat yang memegang pemetaan. Jika balasan mengambil rute lain, uplink kedua, rute kebijakan, atau penyedia yang tak pernah mendengar rentang privat Anda, terjemahan balik berstatus itu tidak pernah terjadi dan klien melihat lalu lintas satu arah. Menambah NAT sumber jarang memperbaiki rute balik yang hilang; ia dapat menyembunyikan gejala pada satu aliran sekaligus merusak kebijakan berbasis alamat di tempat lain.

Kesalahan umum lainnya adalah mengharapkan terowongan menciptakan keterututan. Klien privat yang paketnya keluar ke internet memerlukan pengaturan keluar yang sah: rute default, gateway yang meneruskan, dan biasanya terjemahan sumber ke alamat publik. Enkripsi saja tidak membuat alamat privat dapat dijangkau.

Masquerade atau SNAT eksplisit

Bandingkan keduanya dari apa yang dijanjikan. Masquerade memilih alamat keluar, SNAT eksplisit memakunya. Pada gateway dengan alamat publik stabil, pemakuan memberi log dan daftar izin mitra satu nilai yang dapat diprediksi. Pada tautan WAN dinamis, alamat SNAT yang dipaku menjadi salah begitu sewa berubah, dan itulah tepat kasus yang Masquerade dibuat untuknya.

Cakupan sama pentingnya dengan pilihan. Aturan Masquerade yang cocok dengan setiap paket yang meninggalkan gateway, tanpa batas sumber atau tujuan, juga menerjemahkan lalu lintas yang ingin Anda biarkan utuh, termasuk lalu lintas ke jaringan privat lain. Batasi aturan pada rentang klien, tujuan yang dimaksud, dan antarmuka.

IPsec berbasis kebijakan adalah tempat ini paling menggigit. Panduan penerusan strongSwan menelusuri cara mengaktifkan penerusan IP dan menambahkan aturan SNAT sumber untuk klien, dan dokumentasi yang sama mencakup pengecualian lalu lintas yang harus mempertahankan alamat aslinya. Terjemahkan sumber sebelum kebijakan keamanan mencocokkannya dan terowongan bisa naik sementara lalu lintas tetap jatuh, karena paket tidak lagi tampak seperti selektor yang dinegosiasikan.

Putuskan juga apa yang harus dilihat ujung jauh. Setelah terjemahan, layanan melihat gateway, bukan klien perorangan. Itu menyederhanakan perutean balik dan sekaligus meratakan log serta melumpuhkan daftar izin per klien. Jika mempertahankan alamat klien penting, rencanakan jalur balik terutut alih-alih menyembunyikannya agar sebuah uji lolos.

Membaca aturan pada gateway Linux

Gateway akses jarak jauh dengan klien di 10.8.0.0/24 dan antarmuka WAN bernama eth0 memerlukan penerusan aktif dan kebijakan filter yang mengizinkan aliran sebelum aturan NAT mana pun dapat membantu. Versi iptables menyimpan kedua arah di tabel nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Bentuk nftables memakai dua kait yang sama dengan antarmuka bernama dan rantai eksplisit:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Kedua cuplikan mengasumsikan rantai filter sudah menerima aliran yang diteruskan. NAT bukan aturan izin, dan paket yang diterjemahkan dengan benar masih bisa dibuang satu tabel kemudian. Pastikan pemetaan hidup dengan conntrack -L, pastikan apa yang dimuat dengan nft list ruleset atau iptables-save -t nat, lalu tangkap di kedua antarmuka untuk melihat alamat benar-benar berubah.

Mode kegagalan yang tampak seperti aturan buruk

Lalu lintas jepit rambut adalah yang klasik. Klien internal yang mencapai server internal melalui alamat publik server memerlukan DNAT saat masuk dan terjemahan sumber saat keluar kembali, jika tidak server membalas langsung ke klien dan balasan ditolak. Perbaikannya adalah aturan kedua yang lebih sempit untuk kasus internal-ke-publik itu, bukan aturan Masquerade yang lebih luas untuk semuanya.

Terjemahan ganda adalah yang senyap. Klien yang sudah di belakang NAT kelas operator tiba di gateway Anda dengan alamat yang tak dapat Anda rutekan balik, jadi Anda menerjemahkan lagi. Berhasil, tetapi log kini membawa dua lompatan pengalamatan privat dan setiap penyelidikan memerlukan kedua pemetaan. IPsec berbasis kebijakan menambah puntiran ketiga: terjemahkan sebelum pencocokan kebijakan dan Anda mendapat SA yang naik tanpa lalu lintas lewat, yang terbaca seperti bug firewall, bukan bug NAT.

Lalu ada uji yang lolos dan penerapan yang gagal. Menjalankan perintah NAT dengan tangan membuktikan mekanismenya, bukan konfigurasinya. Aturan yang ditambahkan saat berjalan hilang pada reboot atau pada peristiwa antarmuka berikutnya, dan aturan Masquerade yang terikat ke antarmuka yang berubah nomor dapat diam-diam mengubah alamat yang dilihat ujung jauh. Taruh aturan itu dalam konfigurasi firewall pemiliknya dan uji ulang setelah menyambung kembali.

Daftar periksa sebelum menyimpan aturan

Sebutkan arahnya lebih dulu: sumber, tujuan, atau keduanya. Lalu tentukan siapa yang harus memegang keadaan, yaitu gateway, router di atasnya, atau peer IPsec, dan pastikan jalur balasan kembali melaluinya. Batasi aturan pada rentang klien, tujuan, dan antarmuka yang benar-benar Anda maksud, dan putuskan sebelumnya apakah ujung jauh harus melihat gateway atau alamat klien asli.

Uji dari klien, bukan dari gateway. Peramban di gateway itu sendiri dapat melewati aturan terjemahan klien sepenuhnya, jadi halaman yang berfungsi di sana tidak membuktikan apa pun tentang terowongan. Kirim satu permintaan yang berasal dari klien, amati penghitung dan tabel conntrack, lalu ulangi setelah terowongan menyambung ulang dan alamat WAN berubah jika salah satunya mungkin di tempat Anda bekerja.