NAT simetris dan VPN: ukur pemetaannya, bukan labelnya

Sebuah utas dukungan berakhir dengan vonis “NAT simetris, VPN tidak akan berfungsi di sini”, lalu klien dipasang ulang tiga kali tanpa alasan. Label itu merugikan karena menjawab pertanyaan yang tidak diajukan siapa pun. Klien yang terhubung keluar ke server tetap membuat pemetaan pada saat mengirim paket pertama, dan balasannya diizinkan kembali menurut aturan yang diterapkan hampir semua jaringan. Yang benar-benar dipersulit pemetaan bergantung titik akhir adalah dua peer yang mencoba saling menjangkau pada saat yang sama, dan itu uji yang berbeda.

Dua pertanyaan bersembunyi di balik satu label

Pertanyaan pertama adalah apakah host di balik jaringan ini dapat membuka sesi ke alamat publik dan port yang diketahui. Bagi klien tunnel itu kasus biasa, dan jawabannya hampir selalu ya. Router mencatat sumber internal, mengalokasikan port eksternal, dan meloloskan balasannya karena termasuk sesi yang dimulai dari dalam.

Pertanyaan kedua adalah apakah dua host di balik jaringan berbeda dapat menemukan jalur bersama dan saling mengirim tanpa server di tengah. Itu bergantung pada cara tiap jaringan mengalokasikan port eksternal tersebut, dan hanya di situ perilaku pemetaan penting.

Mencampur keduanya menghasilkan salah diagnosis klasik: fitur peer-to-peer gagal, seseorang menjalankan uji tipe NAT, melihat kategori terburuk, dan menyimpulkan tunnel biasa pun tidak bisa berfungsi. Tunnel tidak pernah menjadi hal yang gagal.

Pemetaan dan penyaringan adalah dua sifat terpisah

Istilah RFC lebih tepat daripada nama yang dipakai vendor, dan layak dibawa ke tiket karena menyelesaikan perdebatan. Pemetaan adalah cara port eksternal dialokasikan. Penyaringan adalah paket masuk mana yang diizinkan lewat. Sebuah jaringan bisa ketat pada satu dan longgar pada yang lain, dan kombinasi itulah yang harus dilewati protokol peer-to-peer.

Baris ketiga adalah yang dimaksud sebagian besar router konsumen dan operator seluler dengan simetris. Perhatikan bahwa label itu hanya menjelaskan alokasi. Jaringan dengan pemetaan tersebut dan penyaringan longgar masih dapat menerima paket masuk ke port yang baru saja dialokasikannya, karena itu pelubangan lubang berhasil pada sebagian dan gagal pada sebagian lain.

Penyaringan punya tiga kasusnya sendiri dan namanya sendiri untuk masing-masing. Menulis “NAT simetris” di tiket padahal yang dimaksud “penyaringan bergantung alamat dan port” mengirim orang berikutnya ke bab yang salah dalam manual. Keduanya berperilaku berbeda saat diuji, jadi kesalahannya bukan akademis.

Ukur pemetaannya alih-alih menamainya

Anda dapat mengamati port yang dialokasikan langsung dari sisi server layanan UDP apa pun yang Anda kendalikan. Mulai penangkapan di host publik, kirim dari klien, dan baca port sumber tempat paket tiba:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

Baris titik akhir paling berguna dari ketiganya, karena WireGuard mencatat alamat dan port terakhir yang diterimanya dari setiap peer. Bandingkan port itu dengan port yang dianggap klien sedang dipakai. Keduanya akan berbeda setiap kali ada penerjemahan, dan pertanyaan pentingnya adalah apakah nilainya tetap stabil.

Ulangi pengamatan terhadap port tujuan kedua atau server kedua dan bandingkan lagi. Jika port eksternal berubah per tujuan, pemetaannya bergantung alamat dan port. Jika tetap sama, jaringan memberi Anda satu pemetaan dan penemuan punya peluang.

Alat berbasis STUN melaporkan klasifikasi yang sama dalam satu langkah, dan aman dipakai bila jaringan mengizinkan UDP keluar ke server STUN publik. Bila tidak mengizinkan, metode penangkapan di atas tetap berfungsi dan tidak menuntut apa pun selain host yang sudah Anda kendalikan.

Pilih perbaikan yang cocok dengan kegagalan

Jika fitur yang gagal bersifat peer-to-peer, jawaban yang didukung adalah relay, layanan pertemuan yang dapat dijangkau kedua peer, atau topologi berbeda. TURN ada justru untuk ini, dan produk yang menyertakan relay sendiri sedang memberi tahu bahwa ia memperkirakan sebagian jaringan bersikap musuh.

Jika fitur yang gagal adalah tunnel biasa, perilaku pemetaan bukan masalah Anda dan tidak satu pun dari hal di atas berlaku. Periksa bahwa klien benar-benar mengirim, server melihat paketnya, dan balasannya kembali. Urutan itu tiga pengamatan dan tidak menuntut pengetahuan apa pun tentang kategori NAT router.

Yang tidak berhasil adalah menyebar perubahan port lokal sampai sesuatu tersambung. Mengubah port sumber klien tidak mengubah cara jaringan mengalokasikan pemetaan. Keberhasilan kebetulan pada percobaan kelima adalah positif palsu, dan akan dikutip sebagai perbaikan selama berbulan-bulan.

Catat arsitekturnya, bukan vonisnya

Catatan yang berguna menyebut protokol apa, ke arah mana sesi dimulai, apakah ada relay di jalur, dan apa yang diamati di kabel. “NAT simetris, tidak berfungsi” tidak terpakai, karena sekaligus keliru soal tunnel dan tidak informatif soal jalur peer.

Sertakan kestabilan port yang terukur dan perilaku penyaringan bila Anda mengujinya. Kedua fakta itu memungkinkan orang lain memperkirakan apakah fitur baru akan berfungsi di jaringan tersebut tanpa mengulang seluruh penyelidikan. Keduanya juga lebih awet daripada kategori vendor yang berarti sedikit berbeda di setiap halaman bantuan.

Terakhir, simpan terminologi RFC 4787 di tangan saat Anda menulisnya. Memakai istilah yang tepat hanya seharga satu kalimat dan mencegah pembaca berikutnya mengulangi salah diagnosis yang sama, dan itulah seluruh maksud menulis catatan itu.