NAT menentukan alamat sumber mana yang sebenarnya dilihat server VPN Anda

Anda membayangkan server VPN membaca alamat laptop Anda dari paket dan menuliskannya ke log. Yang dibacanya adalah apa yang diletakkan lompatan NAT terakhir di header luar, dan pada ponsel yang dipakai sebagai hotspot itu sering alamat yang dibagi dengan ratusan pelanggan lain. Alamat mesin Anda sendiri 192.168.x.x tidak pernah melintasi internet di header itu, dan alamat tunnel diberikan server setelah koneksi sudah aktif. Jadi ketika log server dan ip addr di laptop tidak cocok, keduanya tidak salah; keduanya menggambarkan lapisan berbeda dari satu sesi.

Tiga alamat, dan hanya satu yang ada di log

Kebingungan muncul karena tiga alamat digabung menjadi satu. Masing-masing punya pemilik berbeda, hidup di header berbeda, dan mencapai server lewat jalur berbeda.

Hanya baris tengah yang tidak diketahui saat koneksi. Server menulisnya ke tabel peer, berkas status, atau log aliran tergantung daemon: WireGuard menyebutnya endpoint, berkas status OpenVPN melabelinya Real Address, dan strongSwan melaporkannya sebagai host jauh IKE_SA. Nilai itu diperbarui setiap kali paket datang dari sumber lain, jadi berubah tanpa siapa pun memulai ulang apa pun.

Baris bawah adalah yang orang salah baca sebagai klaim identitas. Itu menandai satu slot di konfigurasi server, bukan seseorang, karena server memilihnya dari kumpulannya sendiri. Dua pengguna bisa menerima alamat tunnel yang sama pada hari berbeda, dan satu orang bisa memegang dua di antaranya dari dua perangkat.

Mengapa tuple yang dicatat berubah saat tunnel tetap aktif

Terjemahan alamat adalah tabel dengan pengatur waktu, bukan ikatan permanen. Router rumah menyimpan pemetaan UDP-nya beberapa saat setelah paket terakhir, gateway operator mendaur ulang port menurut jadwalnya sendiri, dan ponsel yang berpindah dari Wi-Fi ke LTE kembali dengan sumber yang sama sekali berbeda. Nilai bawaan conntrack di Linux menjadi patokan berguna di sini: nf_conntrack_udp_timeout adalah 30 detik dan varian streaming 120, sehingga tunnel yang tenang bisa kehilangan pemetaannya jauh sebelum pengguna menyadarinya.

Tunnel bertahan karena protokol mengautentikasi peer, bukan alamat. WireGuard tanpa status setelah handshake, jadi setiap paket terautentikasi memperbarui endpoint tersimpan dan pengikatan ulang pulih pada paket berikutnya; itulah sebabnya persistent-keepalive = 25 ada, untuk menjaga pemetaan tetap hangat saat menganggur. --float milik OpenVPN melakukan hal yang sama dan memungkinkan klien terautentikasi melanjutkan dari alamat dan port baru. Pada build 2.4 dan 2.5 yang float-nya mati secara bawaan, pengikatan ulang mereset sesi dan klien menyambung ulang.

IPsec mencapainya dengan lebih banyak bagian bergerak. IKEv2 mengenali terjemahan dengan membandingkan hash sumber dan tujuan pada muatan deteksi NAT, beralih ke enkapsulasi UDP 4500, dan mengikuti keepalive ke tuple baru. Ketika keepalive diblokir, SA tetap hidup di atas kertas sementara lalu lintas di satu arah berhenti diam-diam.

Apa yang bisa diatribusikan server, dan apa yang tidak

Mitos yang layak dibunuh adalah bahwa terjemahan menyembunyikan Anda dari operator. Itu mengubah label, bukan pengamatan. Gateway di belakang NAT operator melihat ruang 100.64.0.0/10 atau satu alamat publik yang dibagi banyak pelanggan, dan tetap bisa mengaitkan aliran dengan subjek sertifikat, kunci publik WireGuard, alamat tunnel yang diberikan, penghitung byte, dan jendela waktu. Tidak satu pun dari itu membutuhkan alamat LAN Anda.

Batasnya juga berjalan ke arah lain. Alamat bersama di log menunjuk gateway, bukan rumah tangga; dua sesi dari alamat terjemahan yang sama pada port berbeda adalah perangkat berbeda; alamat yang sama pada dua hari berbeda bisa jadi dua pelanggan tak bertalian jika port didaur ulang. Server yang hanya mencatat kunci peer tidak bisa memetakan satu ke pelanggan tanpa basis data akun, dan server yang hanya mencatat alamat tidak bisa membedakan laptop dari ponsel di belakang router yang sama.

Bandingkan kedua ujung alih-alih menebak

Untuk memastikan apa yang terjadi, tangkap koneksi yang sama di kedua ujung pada saat yang sama dan bandingkan tuple, bukan alamat. Di klien, sebelum terjemahan apa pun:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Lalu baca entri terjemahan di router atau gateway CGNAT, dan apa yang akhirnya tiba di server:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Tiga pola menjelaskan sebagian besar ketidakcocokan. Port sumber di server berbeda dari port lokal sementara tujuan cocok: terjemahan port biasa. Alamat sumber di server milik blok ISP yang bukan milik Anda: setidaknya satu lapisan NAT tambahan. Paket berhenti setelah periode menganggur dan berlanjut dengan port baru: pemetaan kedaluwarsa, bukan kesalahan routing. Jika stempel waktu terpisah lebih dari satu atau dua detik, Anda membandingkan dua percobaan berbeda.

Di mana perbedaannya merusak

Gangguan yang tampak seperti kesalahan server biasanya mulai di sini. Aturan akses yang dipatok ke alamat rumah Anda gagal setelah sewa ISP berubah. Aturan fail2ban yang cocok dengan alamat terjemahan melarang semua pelanggan di belakang gateway itu sekaligus. Peer situs-ke-situs dengan alamat jauh tetap berhenti memperbarui kunci setelah tautan seluler berubah. Protokol tunnel baik-baik saja; asumsi tentang tuple luar tidak.

Kebingungan yang sama muncul di sisi server. Jika kotak VPN sendiri berada di belakang NAT, Anda perlu penerusan port dan jalur penerusan yang berfungsi; panduan penerusan strongSwan mencakup kasus itu untuk IPsec. Server yang hanya bisa dijangkau di alamat privat tidak pernah melihat tuple terjemahan yang disajikan kliennya, dan itu masalah berbeda dari klien yang diterjemahkan.

Jalankan keempat pemeriksaan ini secara berurutan dan berhenti pada yang pertama gagal:

• Tangkap di kedua ujung pada waktu yang sama; pastikan port sumber, port tujuan, dan stempel waktu cocok.
• Baca daftar peer server untuk alamat yang dipegangnya sekarang, bukan alamat yang Anda harapkan.
• Periksa tabel conntrack atau NAT untuk entri dan sisa masa hidupnya.
• Pastikan alamat antarmuka tunnel di klien cocok dengan yang diberikan server, bukan alamat LAN.

Jika kedua tangkapan sepakat soal tuple dan tunnel tetap gagal, terjemahan bukan masalah Anda; lanjutkan ke handshake dan ke tabel routing di dalam tunnel.