Patutkah anda menggunakan SNAT pada pengalihan port ke subnet VPN?

Mengalihkan port ke hos yang berada di belakang klien VPN penghala itu sendiri gagal dengan cara yang kelihatan seperti masalah tembok api, kerana permintaan jelas tiba. Perkhidmatan merekod sambungan, klien menunggu, dan tiada apa kembali. Terjemahan destinasi telah melaksanakan tugasnya; paket balasan ialah bahagian yang hilang. Satu peraturan NAT sumber terpilih pada penghala membaikinya, dan bahagian menariknya ialah memutuskan betapa sempit peraturan itu boleh dibuat.

Mengapa balasan mengambil laluan lain

Pengalihan port menulis semula ke mana paket pergi, tidak pernah dari mana ia datang. Alamat klien internet kekal dalam medan sumber sepanjang perjalanan melalui terowong, jadi perkhidmatan jauh melihat orang asing dan menjawab dengan satu-satunya cara yang diketahuinya: melalui get laluan lalainya sendiri. Get laluan itu ialah pemusat VPN di sebelah jauh, yang tiada laluan balik ke alamat awam sewenang-wenangnya.

Tonton tangkapan pada antara muka terowong dan asimetri jelas: paket permintaan keluar, tiada yang masuk. Rantaian pengalihan membenarkan aliran dan terowong membawanya, jadi penurunan berlaku selepas hos jauh sudah memilih laluan balik.

Peraturan sumber yang cukup sempit untuk dipercayai

Jadikan penghala sebagai sumber yang dijawab oleh hos jauh. Dalam susun atur ini alamat WAN ialah 203.0.113.24, LAN ialah 192.168.88.0/24, alamat terowong penghala ialah 172.20.5.1, dan perkhidmatan menjawab pada 172.20.5.40:8443. Peraturan di bawah sepadan dengan paket selepas terjemahan destinasi, itulah sebabnya ia menamakan alamat terjemahan dan bukan alamat awam. Tiada apa di dalamnya bergantung pada alamat klien, dan itulah maksudnya.

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 padanan dalam baris itu wujud untuk memastikan penulisan semula kekal setempat kepada satu perkhidmatan pada satu terowong. Buang antara muka atau port dan anda menulis semula lebih banyak trafik daripada yang diperlukan masalah, dan begitulah pembaikan bersasar menjadi misteri kepada orang seterusnya.

Bilakah penyamaran menyeluruh ialah pilihan jujur

Jika penghala mengalihkan banyak perkhidmatan ke subnet VPN yang sama, peraturan setiap perkhidmatan menjadi senarai yang tiada siapa menyelenggarakannya. Menyamarkan semua yang keluar dari antara muka terowong lebih mudah dan boleh dijangka, dengan kos menyembunyikan klien asal daripada setiap hos di sebelah jauh. Pilihnya apabila log di sana tidak digunakan untuk atribusi; kekalkan peraturan sempit apabila digunakan.

Kedua-dua pilihan juga gagal secara berbeza. Peraturan sempit yang tiada memecahkan satu perkhidmatan; penyamaran luas yang sepadan terlalu banyak boleh menulis semula secara senyap trafik yang sudah berfungsi, termasuk sambungan keluar penghala itu sendiri.

Semak pembilang sebelum menerbitkan

Peraturan yang tidak pernah sepadan kelihatan sama seperti peraturan yang berfungsi sehingga anda mengira paket. Baca semula jadual dengan pembilang bait sebelum mana-mana klien menyambung, kemudian sambung dari rangkaian yang bukan LAN dan baca semula. Dua bacaan itulah yang mengubah tekaan menjadi fakta. Terbitkan pengalihan hanya selepas yang kedua bergerak.

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

Pembilang sifar pada peraturan sumber selepas sambungan sebenar bermakna padanan itu salah, biasanya kerana destinasi atau port tidak sepadan dengan paket selepas terjemahan. Jika pembilang meningkat tetapi klien masih tamat masa, laluan balik sudah dibaiki dan sesuatu yang lain menggugurkan balasan, jadi lihat dasar pengalihan di sebelah jauh seterusnya. Akses hairpin dari dalam LAN ialah masalah berasingan dan memerlukan peraturannya sendiri, bukan versi yang lebih luas daripada ini.