NAT menentukan alamat sumber mana yang sebenarnya dilihat oleh pelayan VPN anda

Anda membayangkan pelayan VPN membaca alamat komputer riba anda daripada paket dan menulisnya ke log. Yang dibacanya ialah apa yang diletakkan oleh lompatan NAT terakhir dalam pengepala luar, dan pada telefon yang digunakan sebagai hotspot itu selalunya alamat yang dikongsi dengan ratusan pelanggan lain. Alamat mesin anda sendiri 192.168.x.x tidak pernah melintasi internet dalam pengepala itu, dan alamat terowong diberikan oleh pelayan selepas sambungan sudah dibuka. Jadi apabila log pelayan dan ip addr pada komputer riba tidak sepadan, kedua-duanya tidak salah; kedua-duanya menerangkan lapisan berbeza dalam satu sesi.

Tiga alamat, dan hanya satu ada dalam log

Kekeliruan timbul daripada menggabungkan tiga alamat menjadi satu. Setiap satu mempunyai pemilik berbeza, hidup dalam pengepala berbeza dan sampai ke pelayan melalui laluan berbeza.

Hanya baris tengah tidak diketahui pada masa menyambung. Pelayan menulisnya ke jadual rakan, fail status atau log aliran bergantung pada daemon: WireGuard memanggilnya titik akhir, fail status OpenVPN melabelnya Real Address, dan strongSwan melaporkannya sebagai hos jauh IKE_SA. Nilai itu dikemas kini setiap kali paket tiba dari sumber lain, jadi ia berubah tanpa sesiapa memulakan semula apa-apa.

Baris bawah ialah apa yang orang salah baca sebagai dakwaan identiti. Ia menandakan satu slot dalam konfigurasi pelayan, bukan seseorang, kerana pelayan memilihnya daripada kolamnya sendiri. Dua pengguna boleh menerima alamat terowong yang sama pada hari berbeza, dan seorang boleh memegang dua daripadanya dari dua peranti.

Mengapa tuple yang direkodkan berubah semasa terowong kekal aktif

Terjemahan alamat ialah jadual dengan pemasa, bukan ikatan kekal. Penghala rumah menyimpan pemetaan UDP-nya seketika selepas paket terakhir, get laluan pengendali mengitar semula port mengikut jadualnya sendiri, dan telefon yang beralih daripada Wi-Fi ke LTE kembali dengan sumber yang sama sekali berbeza. Nilai lalai conntrack Linux ialah penanda aras berguna di sini: nf_conntrack_udp_timeout ialah 30 saat dan varian penstriman ialah 120, jadi terowong yang senyap boleh kehilangan pemetaannya jauh sebelum pengguna menyedarinya.

Terowong bertahan kerana protokol mengesahkan rakan, bukan alamat. WireGuard tanpa keadaan selepas jabat tangan, jadi mana-mana paket yang disahkan mengemas kini titik akhir tersimpan dan pengikatan semula pulih pada paket seterusnya; sebab itulah persistent-keepalive = 25 wujud, untuk memastikan pemetaan kekal hangat semasa melahu. --float OpenVPN melakukan kerja yang sama dan membolehkan klien yang disahkan menyambung semula dari alamat dan port baharu. Pada binaan 2.4 dan 2.5 yang float dimatikan secara lalai, pengikatan semula menetapkan semula sesi dan klien menyambung semula.

IPsec sampai ke sana dengan lebih banyak bahagian bergerak. IKEv2 mengesan terjemahan dengan membandingkan cincangan sumber dan destinasi dalam muatan pengesanan NAT, bertukar kepada enkapsulasi UDP 4500, dan mengikuti keepalive ke tuple baharu. Apabila keepalive disekat, SA kekal aktif di atas kertas manakala trafik dalam satu arah berhenti secara senyap.

Apa yang pelayan boleh atribusikan, dan apa yang tidak

Mitos yang patut dibunuh ialah terjemahan menyembunyikan anda daripada pengendali. Ia menukar label, bukan pemerhatian. Get laluan di belakang NAT pengendali melihat ruang 100.64.0.0/10 atau satu alamat awam yang dikongsi oleh ramai pelanggan, dan masih boleh mengaitkan aliran dengan subjek sijil, kunci awam WireGuard, alamat terowong yang diberikan, pembilang bait dan tetingkap masa. Tiada satu pun daripada itu memerlukan alamat LAN anda.

Hadnya berjalan ke arah lain juga. Alamat kongsi dalam log menunjuk kepada get laluan, bukan isi rumah; dua sesi dari alamat terjemahan yang sama pada port berbeza ialah peranti berbeza; alamat yang sama pada dua hari berbeza boleh jadi dua pelanggan tidak berkaitan jika port dikitar semula. Pelayan yang hanya merekod kunci rakan tidak boleh memetakan satu kepada pelanggan tanpa pangkalan data akaun, dan pelayan yang hanya merekod alamat tidak boleh membezakan komputer riba daripada telefon di belakang penghala yang sama.

Bandingkan kedua-dua hujung daripada meneka

Untuk memastikan apa yang berlaku, tangkap sambungan yang sama di kedua-dua hujung pada saat yang sama dan bandingkan tuple, bukan alamat. Pada klien, sebelum sebarang terjemahan:

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

Kemudian baca entri terjemahan pada penghala atau get laluan CGNAT, dan apa yang akhirnya tiba di pelayan:

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

Tiga corak menerangkan kebanyakan ketidakpadanan. Port sumber di pelayan berbeza daripada port setempat manakala destinasi sepadan: terjemahan port biasa. Alamat sumber di pelayan tergolong dalam blok ISP yang bukan milik anda: sekurang-kurangnya satu lapisan NAT tambahan. Paket berhenti selepas tempoh melahu dan bersambung dengan port baharu: pemetaan telah tamat tempoh, bukan kerosakan penghalaan. Jika cap masa terpisah lebih daripada satu atau dua saat, anda membandingkan dua percubaan berbeza.

Di mana perbezaan merosakkan keadaan

Gangguan yang kelihatan seperti kerosakan pelayan biasanya bermula di sini. Peraturan akses yang dipaku pada alamat rumah anda gagal selepas pajakan ISP berubah. Peraturan fail2ban yang sepadan dengan alamat terjemahan mengharamkan semua pelanggan di belakang get laluan itu serentak. Rakan tapak-ke-tapak dengan alamat jauh tetap berhenti memperbaharui kunci selepas pautan mudah alih berubah. Protokol terowong itu baik; andaian tentang tuple luar tidak.

Kekeliruan yang sama muncul di hujung pelayan. Jika kotak VPN itu sendiri berada di belakang NAT, anda memerlukan pemajuan port dan laluan pemajuan yang berfungsi; panduan pemajuan strongSwan merangkumi kes itu untuk IPsec. Pelayan yang hanya boleh dicapai pada alamat peribadi tidak pernah melihat tuple terjemahan yang dikemukakan oleh kliennya, dan itu masalah berbeza daripada klien diterjemahkan.

Lakukan keempat-empat semakan ini mengikut urutan dan berhenti pada yang pertama gagal:

• Tangkap di kedua-dua hujung pada masa yang sama; sahkan port sumber, port destinasi dan cap masa sepadan.
• Baca senarai rakan pelayan untuk alamat yang dipegangnya sekarang, bukan alamat yang anda jangkakan.
• Semak jadual conntrack atau NAT untuk entri dan baki hayatnya.
• Sahkan alamat antara muka terowong pada klien sepadan dengan yang diberikan oleh pelayan, bukan alamat LAN.

Jika kedua-dua tangkapan bersetuju tentang tuple dan terowong masih gagal, terjemahan bukan masalah anda; teruskan ke jabat tangan dan ke jadual penghalaan di dalam terowong.