NAT hairpin: mengapa titik akhir VPN gagal dari dalam

Pelayan VPN yang menjawab dari rangkaian mudah alih tetapi gagal dari sofa biasanya bukan masalah sijil. Klien di dalam LAN meminta penghala menterjemah paket yang destinasinya ialah alamat awam penghala itu sendiri, bermakna paket itu mesti keluar dan masuk semula dengan segera. Gerakan itu dipanggil hairpinning, dan banyak penghala sama ada tidak melaksanakannya atau hanya melakukannya apabila kotak semak diaktifkan. Kejayaan ujian dari luar itulah yang mengelirukan, kerana ia membuktikan pendengar dan peraturan penghantaran sudah betul.

Paket keluar dan masuk semula

Ikut paket itu. Klien menyelesaikan nama awam, bersambung ke alamat awam, dan NAT destinasi penghala menulis semula destinasi ke pelayan dalaman. Balasan pelayan dialamatkan ke alamat LAN klien, jadi ia kembali melalui antara muka LAN penghala tanpa pernah melalui peraturan NAT yang sepatutnya menterjemah semula sumber.

Kini klien menerima paket daripada alamat yang tidak pernah ia hantar apa-apa, lalu membuangnya. Asimetri itulah seluruh kegagalan.

RFC 4787 menerangkan tingkah laku yang dijangka daripada NAT dalam kes ini, dan versi ringkasnya ialah ia pilihan dalam amalan walaupun di tempat yang ditetapkan secara teori. Sesetengah penghala menamakan tetapan itu NAT loopback, yang lain memanggilnya hairpin NAT atau NAT reflection, dan ada yang tidak memaparkan apa-apa. Penghala yang tidak memilikinya bukan salah dikonfigurasi; ia melakukan perkara biasa, dan pembaikan terletak di tempat lain. Jangan simpulkan daripada ujian setempat yang gagal bahawa peraturan penghantaran awam itu salah.

Pemeriksaan 1: uji kedua-dua laluan secara berasingan

Dari luar LAN, sambung dengan profil yang sama seperti yang akan digunakan oleh pengguna sebenar dan sahkan sesi terbentuk. Dari dalam, sambung ke alamat awam dengan profil yang sama dan catat ralat tepat serta masanya.

Ujian setempat yang tepat mengekalkan nama hos dan hanya menggantikan alamat: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ menghantar permintaan ke alamat awam sambil masih membentangkan nama pelayan yang betul. Itu memisahkan masalah penyelesaian nama daripada masalah terjemahan, yang mudah dikelirukan apabila nama yang sama berfungsi dari kedai kopi. Perhatikan sama ada klien gagal pada sambungan TCP atau kemudian pada TLS, kerana yang pertama menunjuk kepada terjemahan dan yang kedua kepada identiti.

Pemeriksaan 2: baca apa yang pelayan lihat

Pemerhatian paling berguna ialah pandangan pelayan. Jalankan tangkapan pada hos VPN yang ditapis kepada alamat LAN klien dan alamat LAN penghala, kemudian ulangi percubaan setempat. Jika tiada apa yang tiba, paket itu tidak terselamat daripada terjemahan.

Jika sambungan tiba dari alamat LAN penghala dan bukan dari alamat klien, hairpinning sedang berlaku dan sumber telah ditulis semula. Itu konfigurasi yang berfungsi, bukan kerosakan.

Pemeriksaan 3: betulkan tanpa menyentuh laluan luar

Terdapat tiga bentuk yang disokong, mengikut urutan jejari kesan yang meningkat. Yang paling sempit ialah DNS berpecah: terbitkan rekod dalaman supaya nama pelayan yang sama diselesaikan ke alamat dalaman bagi klien di LAN, yang mengelakkan laluan awam sepenuhnya. Seterusnya ialah mengaktifkan pilihan loopback atau reflection penghala yang didokumenkan, jika ada, dan hanya menggunakannya pada perkhidmatan ini. Yang paling luas ialah peraturan source-NAT pada penghala yang menulis semula trafik dari LAN ke pelayan supaya balasan kembali melalui penghala; pada penghala Linux ia ialah peraturan MASQUERADE dalam POSTROUTING yang sepadan dengan alamat dan port pelayan. Ketiga-tiganya membiarkan laluan luar tidak tersentuh, dan itulah sifat yang perlu dikekalkan.

Jangan luaskan penghantaran port yang tidak berkaitan supaya laluan setempat menyerupai laluan luar, dan jangan pindahkan perkhidmatan ke port lain untuk mengelakkan masalah. Kedua-dua perubahan mengubah apa yang boleh dicapai oleh dunia luar untuk membaiki sesuatu yang hanya dilihat oleh dunia dalam.

DNS berpecah mempunyai satu perangkap yang wajar disebut. Menggantikan nama hos dengan IP sewenang-wenangnya mengubah apa yang disahkan oleh klien, jadi rekod dalaman masih mesti sepadan dengan nama dalam sijil.

Pemeriksaan 4: sahkan kedua-dua laluan selepas itu

Ulangi percubaan luar dari luar LAN, ulangi percubaan dalam dengan profil yang sama, dan sahkan log pelayan menunjukkan dua sesi berjaya yang berasingan dan bukan satu kejayaan dan satu kesenyapan. Kemudian periksa bahawa klien lain masih mencapai pendengar dan laluan ke sumber peribadi tidak berubah.

Kekalkan rekod ringkas: alamat mana yang digunakan oleh setiap klien, apa yang pelayan lihat, dan pembaikan mana antara tiga yang digunakan. Keperluan hairpinning RFC 4787 ialah rujukan untuk apa yang dijangka daripada NAT di sini, dan ia menerangkan mengapa penghala tanpa ciri itu berkelakuan normal. Kegagalan setempat yang tidak dapat dihasilkan semula oleh dunia luar ialah persoalan terjemahan sehingga dibuktikan sebaliknya, jadi ujilah ia sebagai demikian.