NAT hairpin: mengapa endpoint VPN gagal dari dalam

Server VPN yang menjawab dari jaringan seluler tetapi gagal dari sofa biasanya bukan masalah sertifikat. Klien di dalam LAN meminta router menerjemahkan paket yang tujuannya adalah alamat publik router itu sendiri, berarti paket harus keluar dan langsung masuk kembali. Manuver itu disebut hairpinning, dan banyak router entah tidak menerapkannya atau hanya melakukannya saat kotak centang diaktifkan. Justru lolosnya uji dari luar yang membingungkan, karena itu membuktikan listener dan aturan penerusan sudah benar.

Paket keluar dan masuk kembali

Ikuti paketnya. Klien me-resolve nama publik, terhubung ke alamat publik, dan NAT tujuan di router menulis ulang tujuan ke server internal. Balasan server dialamatkan ke alamat LAN klien, jadi balasan itu kembali melalui antarmuka LAN router tanpa pernah melewati aturan NAT yang seharusnya menerjemahkan balik sumbernya.

Kini klien menerima paket dari alamat yang tidak pernah ia kirimi apa pun, lalu membuangnya. Asimetri itulah seluruh kegagalannya.

RFC 4787 menjelaskan perilaku yang diharapkan dari NAT dalam kasus ini, dan versi singkatnya adalah perilaku itu opsional dalam praktik bahkan di tempat yang secara teori sudah ditetapkan. Sebagian router menyebut pengaturan itu NAT loopback, sebagian lagi hairpin NAT atau NAT reflection, dan sebagian tidak menampilkan apa pun. Router yang tidak memilikinya bukan salah konfigurasi; ia melakukan hal yang biasa, dan perbaikannya ada di tempat lain. Jangan simpulkan dari uji lokal yang gagal bahwa aturan penerusan publik salah.

Pemeriksaan 1: uji kedua jalur secara terpisah

Dari luar LAN, hubungkan dengan profil yang sama seperti yang akan dipakai pengguna nyata dan pastikan sesi terbentuk. Dari dalam, hubungkan ke alamat publik dengan profil yang sama dan catat galat persisnya serta waktunya.

Uji lokal yang tepat mempertahankan nama host dan hanya mengganti alamatnya: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ mengirim permintaan ke alamat publik sambil tetap menyajikan nama server yang benar. Itu memisahkan masalah resolusi nama dari masalah penerjemahan, yang mudah tertukar ketika nama yang sama berhasil dari kedai kopi. Perhatikan apakah klien gagal pada koneksi TCP atau nanti pada TLS, karena yang pertama menunjuk ke penerjemahan dan yang kedua ke identitas.

Pemeriksaan 2: baca apa yang dilihat server

Pengamatan paling berguna adalah sudut pandang server. Jalankan tangkapan pada host VPN yang difilter ke alamat LAN klien dan ke alamat LAN router, lalu ulangi percobaan lokal. Bila tidak ada yang tiba, paket tidak selamat melewati penerjemahan.

Bila koneksi tiba dari alamat LAN router alih-alih dari alamat klien, hairpinning sedang terjadi dan sumbernya ditulis ulang. Itu konfigurasi yang bekerja, bukan kerusakan.

Pemeriksaan 3: perbaiki tanpa menyentuh jalur luar

Ada tiga bentuk yang didukung, dengan radius dampak yang meningkat. Yang paling sempit adalah DNS terpisah: terbitkan catatan internal agar nama server yang sama di-resolve ke alamat internal bagi klien di LAN, yang sepenuhnya menghindari jalur publik. Berikutnya adalah mengaktifkan opsi loopback atau reflection yang didokumentasikan router, jika ada, dan menerapkannya hanya pada layanan ini. Yang paling luas adalah aturan source-NAT di router yang menulis ulang lalu lintas dari LAN ke server agar balasannya kembali melalui router; pada router Linux itu aturan MASQUERADE di POSTROUTING yang cocok dengan alamat dan porta server. Ketiganya membiarkan jalur eksternal tak tersentuh, dan itulah sifat yang harus dipertahankan.

Jangan perluas penerusan porta yang tidak terkait agar jalur lokal menyerupai jalur eksternal, dan jangan pindahkan layanan ke porta lain untuk menghindari masalahnya. Kedua perubahan itu mengubah apa yang dapat dijangkau dunia luar untuk memperbaiki sesuatu yang hanya dilihat dunia dalam.

DNS terpisah punya satu jebakan yang layak disebut. Mengganti nama host dengan IP sembarang mengubah apa yang divalidasi klien, jadi catatan internal tetap harus cocok dengan nama pada sertifikat.

Pemeriksaan 4: verifikasi kedua jalur sesudahnya

Ulangi percobaan eksternal dari luar LAN, ulangi percobaan internal dengan profil yang sama, dan pastikan log server menunjukkan dua sesi berhasil yang berbeda, bukan satu keberhasilan dan satu keheningan. Lalu periksa bahwa klien lain masih menjangkau listener dan rute ke sumber daya privat tidak berubah.

Buat catatan tetap singkat: alamat mana yang dipakai tiap klien, apa yang dilihat server, dan perbaikan mana dari ketiganya yang diterapkan. Persyaratan hairpinning RFC 4787 adalah rujukan untuk apa yang diharapkan dari NAT di sini, dan menjelaskan mengapa router tanpa fitur itu berperilaku normal. Kegagalan lokal yang tidak dapat direproduksi dunia luar adalah pertanyaan penerjemahan sampai terbukti sebaliknya, jadi ujilah sebagai demikian.