SNAT, DNAT dan Masquerade: apa yang setiap peraturan NAT VPN lakukan

Letakkan tangkapan pada kedua-dua belah gateway VPN dan satu aliran boleh menunjukkan empat alamat berbeza. NAT sumber menulis semula dari mana paket mendakwa ia datang; NAT destinasi menulis semula ke mana ia pergi. Masquerade bukan arah ketiga, ia ialah peraturan NAT sumber yang mengambil alamatnya daripada antara muka keluar dan bukannya nilai tetap. Namakan yang mana satu daripada tiga yang anda benar-benar perlukan dan kebanyakan tiket „VPN rosak“ mengecil menjadi soalan tentang laluan balik.

Apa yang ditulis semula oleh setiap peraturan

NAT sumber, biasanya ditulis SNAT, menukar alamat sumber sesuatu aliran apabila ia meninggalkan penghala atau gateway. Perkhidmatan penerima membalas ke alamat yang diterjemah, dan kotak yang menterjemah membalikkan perubahan itu menggunakan keadaan yang disimpannya untuk sambungan tersebut. Dalam Linux keadaan itu hidup dalam conntrack, sebab itu conntrack -L mencetak tuple asal dan balasan bersebelahan.

NAT destinasi, DNAT, menukar destinasi sebaliknya. Paket yang dialamatkan ke alamat awam pada UDP 51820 boleh ditulis semula ke pelayan WireGuard dalaman pada 10.8.0.2:51820. Begitulah penghala rumah atau pengimbang beban awan menerbitkan pendengar VPN, dan itu tidak berkata apa-apa tentang apa yang terowong boleh bawa selepas itu.

Masquerade tergolong dalam keluarga SNAT. Peraturan itu tidak menamakan sebarang alamat; ia menggunakan alamat yang ada pada antara muka keluar apabila paket keluar. Linux memberikannya sasaran sendiri, dan ia pilihan biasa pada antara muka WAN yang mendapat alamatnya daripada DHCP atau PPPoE.

Di mana pemetaan hidup menentukan kegagalan

Catat tuple pada setiap sempadan: sebelum terowong, di dalamnya dan pada antara muka awam. Tangkapan di dalam terowong sah berbeza daripada yang di luar, dan sesiapa yang membandingkan kedua-duanya tanpa tahu di mana terjemahan berlaku akan mengejar hos yang salah.

Trafik balik mesti melalui peranti yang memegang pemetaan. Jika balasan mengambil laluan lain, pautan atas kedua, laluan dasar atau penyedia yang tidak pernah mendengar julat persendirian anda, terjemahan songsang berkeadaan tidak pernah berlaku dan klien melihat trafik sehala. Menambah lebih banyak NAT sumber jarang membaiki laluan balik yang hilang; ia boleh menyembunyikan gejala pada satu aliran sambil memecahkan dasar berasaskan alamat di tempat lain.

Kesilapan biasa yang lain ialah mengharapkan terowong mencipta kebolehlethan. Klien persendirian yang paketnya keluar ke internet memerlukan susunan keluar yang sah: laluan lalai, gateway yang memajukan dan biasanya terjemahan sumber ke alamat awam. Penyulitan sahaja tidak menjadikan alamat persendirian boleh dicapai.

Masquerade atau SNAT eksplisit

Bandingkan kedua-duanya dari segi apa yang mereka janjikan. Masquerade memilih alamat keluar, SNAT eksplisit memakukannya. Pada gateway dengan alamat awam yang stabil, pemakuan memberi log dan senarai kebenaran rakan kongsi satu nilai yang boleh diramal. Pada pautan WAN dinamik, alamat SNAT yang dipaku menjadi salah sebaik sahaja pajakan berubah, dan itulah tepat kes yang Masquerade dibina untuknya.

Skop sama pentingnya dengan pilihan. Peraturan Masquerade yang sepadan dengan setiap paket yang meninggalkan gateway, tanpa had sumber atau destinasi, juga menterjemah trafik yang anda mahu biarkan utuh, termasuk trafik ke rangkaian persendirian lain. Hadkan peraturan itu kepada julat klien, destinasi yang dimaksudkan dan antara muka.

IPsec berasaskan dasar ialah tempat ini paling menggigit. Panduan pemajuan strongSwan menelusuri pengaktifan pemajuan IP dan penambahan peraturan SNAT sumber untuk klien, dan dokumentasi yang sama merangkumi pengecualian trafik yang mesti mengekalkan alamat asalnya. Terjemahkan sumber sebelum dasar keselamatan memadankannya dan terowong boleh naik sementara trafik masih jatuh, kerana paket itu tidak lagi kelihatan seperti pemilih yang dirundingkan.

Putuskan juga apa yang patut dilihat oleh hujung jauh. Selepas terjemahan perkhidmatan melihat gateway, bukan klien individu. Itu memudahkan penghalaan balik dan pada masa yang sama meratakan log dan melumpuhkan senarai kebenaran setiap klien. Jika memelihara alamat klien penting, rancang laluan balik berpenghalaan dan bukannya menyembunyikannya supaya ujian lulus.

Membaca peraturan pada gateway Linux

Gateway akses jauh dengan klien pada 10.8.0.0/24 dan antara muka WAN bernama eth0 memerlukan pemajuan diaktifkan dan dasar penapisan yang membenarkan aliran sebelum mana-mana peraturan NAT dapat membantu. Versi iptables menyimpan kedua-dua arah dalam jadual 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 menggunakan dua cangkuk yang sama dengan antara muka bernama dan rangkaian 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-dua coretan menganggap rangkaian penapisan sudah menerima aliran yang dimajukan. NAT bukan peraturan kebenaran, dan paket yang diterjemah dengan betul masih boleh digugurkan satu jadual kemudian. Sahkan pemetaan hidup dengan conntrack -L, sahkan apa yang dimuatkan dengan nft list ruleset atau iptables-save -t nat, kemudian tangkap pada kedua-dua antara muka untuk melihat alamat benar-benar berubah.

Mod kegagalan yang kelihatan seperti peraturan buruk

Trafik pin rambut ialah yang klasik. Klien dalaman yang mencapai pelayan dalaman melalui alamat awam pelayan memerlukan DNAT semasa masuk dan terjemahan sumber semasa keluar balik, jika tidak pelayan membalas terus kepada klien dan balasan ditolak. Pembaikan ialah peraturan kedua yang lebih sempit untuk kes dalaman-ke-awam itu, bukan peraturan Masquerade yang lebih luas untuk segala-galanya.

Terjemahan berganda ialah yang senyap. Klien yang sudah berada di belakang NAT gred pembawa tiba di gateway anda dengan alamat yang tidak dapat anda hala semula, jadi anda menterjemah lagi. Ia berkesan, tetapi log kini membawa dua lompatan pengalamatan persendirian dan apa-apa penyiasatan memerlukan kedua-dua pemetaan. IPsec berasaskan dasar menambah twist ketiga: terjemahkan sebelum padanan dasar dan anda mendapat SA yang naik tanpa trafik lalu, yang terbaca seperti pepijat tembok api, bukan pepijat NAT.

Kemudian ada ujian yang lulus dan penggunaan yang gagal. Menjalankan perintah NAT dengan tangan membuktikan mekanisme, bukan konfigurasi. Peraturan yang ditambah semasa berjalan hilang semasa but semula atau pada peristiwa antara muka seterusnya, dan peraturan Masquerade yang terikat pada antara muka yang berubah nombor boleh mengubah alamat yang dilihat hujung jauh secara senyap. Letakkan peraturan itu dalam konfigurasi tembok api pemiliknya dan uji semula selepas menyambung semula.

Senarai semak sebelum menyimpan peraturan

Namakan arah dahulu: sumber, destinasi atau kedua-duanya. Kemudian tentukan siapa yang mesti memegang keadaan — gateway, penghala di atas atau rakan IPsec — dan sahkan laluan balasan kembali melaluinya. Hadkan peraturan itu kepada julat klien, destinasi dan antara muka yang benar-benar anda maksudkan, dan putuskan lebih awal sama ada hujung jauh patut melihat gateway atau alamat klien asal.

Uji dari klien, bukan dari gateway. Pelayar pada gateway itu sendiri boleh memintas peraturan terjemahan klien sepenuhnya, jadi halaman yang berfungsi di situ tidak membuktikan apa-apa tentang terowong. Hantar satu permintaan yang berasal dari klien, perhatikan pembilang dan jadual conntrack, dan ulangi selepas terowong menyambung semula dan alamat WAN berubah jika salah satu daripadanya mungkin di tempat anda bekerja.