NAT odlučuje koju izvornu adresu vaš VPN poslužitelj zapravo vidi
Adresa vašeg prijenosnika nikada ne stiže do VPN poslužitelja. NAT je prepisuje na zadnjem skoku, a IP adresa tunela dodjeljuje se kasnije. Kako usporediti oba kraja.
Zamišljate da VPN server čita adresu vašeg laptopa iz paketa i upisuje je u dnevnik. Ono što čita jeste ono što je zadnji NAT skok stavio u vanjsko zaglavlje, a na telefonu koji služi kao pristupna tačka to je često adresa koju dijeli stotine drugih pretplatnika. Vlastita adresa vašeg računara 192.168.x.x nikada ne prelazi internet u tom zaglavlju, a adresu tunela dodjeljuje server nakon što je veza već uspostavljena. Zato, kada se dnevnik servera i ip addr na laptopu razilaze, nijedno nije pogrešno; ona opisuju različite slojeve jedne sesije.
Tri adrese, a samo jedna je u dnevniku
Zabuna nastaje kada se tri adrese svedu na jednu. Svaka ima drugog vlasnika, živi u drugom zaglavlju i stiže do servera drugim putem.
| Address | Who assigns it | Where it sits | Visible to the VPN server |
|---|---|---|---|
Device address, e.g. 192.168.1.24 | Your router via DHCP | Outer header, before translation | No, rewritten in place |
| Translated address and port | Router, ISP CGNAT, or both | Outer header, after translation | Yes, this is the tuple it logs |
Tunnel address, e.g. 10.8.0.6 | The VPN server itself | Inner header, after decapsulation | Yes, but it chose it |
Samo je srednji red nepoznat u trenutku povezivanja. Server ga upisuje u svoju tablicu partnera, datoteku stanja ili dnevnik tokova ovisno o daemonu: WireGuard ga naziva krajnjom tačkom, datoteka stanja OpenVPN označava ga kao Real Address, a strongSwan ga prijavljuje kao udaljenog domaćina IKE_SA. Ta vrijednost se osvježava kad god stigne paket iz drugog izvora, pa se mijenja bez toga da iko bilo šta ponovo pokreće.
Donji red je ono što ljudi pogrešno čitaju kao tvrdnju o identitetu. On označava mjesto u konfiguraciji servera, ne osobu, jer ga je server izabrao iz vlastitog pula. Dva korisnika mogu dobiti istu adresu tunela različitim danima, a jedan može držati dvije takve adrese sa dva uređaja.
Zašto se zapisani tuple mijenja dok tunel ostaje aktivan
Prevođenje adresa je tablica s tajmerom, a ne trajno vezivanje. Kućni ruter čuva svoje UDP mapiranje neko vrijeme nakon zadnjeg paketa, operaterov gateway reciklira portove po vlastitom rasporedu, a telefon koji pređe s Wi-Fi na LTE vraća se s potpuno drugim izvorom. Zadane vrijednosti Linux conntracka korisno su mjerilo ovdje: nf_conntrack_udp_timeout iznosi 30 sekundi, a varijanta za streaming 120, pa tihi tunel može izgubiti mapiranje mnogo prije nego što korisnik to primijeti.
Tunel preživljava jer protokol autentificira partnera, a ne adresu. WireGuard je nakon rukovanja bez stanja, pa svaki autentificirani paket ažurira pohranjenu krajnju tačku i ponovno vezivanje se popravi na sljedećem paketu; zato postoji persistent-keepalive = 25, da održi mapiranje toplim dok je veza neaktivna. OpenVPN-ov --float radi isti posao, dopuštajući autentificiranom klijentu da nastavi s nove adrese i porta. U verzijama 2.4 i 2.5 gdje je float zadano isključen, ponovno vezivanje resetira sesiju i klijent se ponovo povezuje.
IPsec to postiže s više pokretnih dijelova. IKEv2 primjećuje prevođenje upoređujući hasheve izvora i odredišta u korisnom teretu za otkrivanje NAT-a, prelazi na enkapsulaciju u UDP 4500 i prati keepalive do novog tuplea. Kada je keepalive blokiran, SA ostaje aktivan samo na papiru, dok promet u jednom smjeru tiho staje.
Šta server može pripisati, a šta ne
Mit koji vrijedi ubiti jeste da vas prevođenje skriva od operatera. Ono mijenja oznaku, ne opažanje. Gateway iza operaterovog NAT-a vidi prostor 100.64.0.0/10 ili jednu javnu adresu koju dijeli mnogo pretplatnika, i ipak može vezati tok za subjekt certifikata, javni ključ WireGuarda, dodijeljenu adresu tunela, brojače bajtova i vremenski prozor. Ništa od toga ne treba vašu LAN adresu.
Ograničenja idu i u drugom smjeru. Dijeljena adresa u dnevniku pokazuje na gateway, ne na domaćinstvo; dvije sesije s iste prevedene adrese na različitim portovima su različiti uređaji; ista adresa u dva različita dana može biti dva nepovezana pretplatnika ako je port recikliran. Server koji bilježi samo ključeve partnera ne može ih povezati s klijentom bez baze podataka računa, a server koji bilježi samo adrese ne može razlikovati laptop od telefona iza istog rutera.
Uporedite oba kraja umjesto nagađanja
Da razriješite šta se dogodilo, snimite istu vezu na oba kraja u istom trenutku i uporedite tuple, a ne adresu. Na klijentu, prije bilo kakvog prevođenja:
ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints
Zatim pročitajte unos prevođenja na ruteru ili CGNAT gatewayu i ono što na kraju stiže na server:
conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820
Tri obrasca objašnjavaju većinu neslaganja. Izvorni port na serveru razlikuje se od lokalnog porta dok se odredište poklapa: obično prevođenje portova. Izvorna adresa na serveru pripada ISP bloku koji nije vaš: najmanje jedan dodatni NAT sloj. Paketi prestanu nakon perioda mirovanja i nastave s novim portom: mapiranje je isteklo, a ne kvar usmjeravanja. Ako su vremenske oznake udaljene više od sekunde ili dvije, upoređujete dva različita pokušaja.
Gdje razlika kvari stvari
Prekidi koji izgledaju kao kvarovi servera obično počinju ovdje. Pravilo pristupa vezano za vašu kućnu adresu prestaje raditi nakon promjene ISP najma. fail2ban pravilo koje odgovara prevedenoj adresi zabranjuje sve pretplatnike iza tog gatewaya odjednom. Partner site-to-site s fiksnom udaljenom adresom prestaje obnavljati ključeve nakon promjene mobilne veze. Protokol tunela je bio u redu; pretpostavka o vanjskom tupleu nije.
Ista zabuna pojavljuje se i na strani servera. Ako je sama VPN kutija iza NAT-a, trebate prosljeđivanje porta i radni put za prosljeđivanje; strongSwan vodič za prosljeđivanje pokriva taj slučaj za IPsec. Server dostupan samo na privatnoj adresi nikada ne vidi prevedeni tuple koji njegovi klijenti predstavljaju, a to je drugačiji problem od prevođenja klijenata.
Prođite kroz ove četiri provjere po redoslijedu i zaustavite se na prvoj koja ne uspije:
- Snimite na oba kraja istovremeno; potvrdite da se izvorni port, odredišni port i vremenske oznake poklapaju.
- Pročitajte listu partnera na serveru za adresu koju trenutno drži, a ne adresu koju ste očekivali.
- Provjerite conntrack ili NAT tablicu za unos i njegov preostali životni vijek.
- Potvrdite da se adresa tunelskog interfejsa na klijentu poklapa s onom koju je server dodijelio, a ne s LAN adresom.
Ako se oba snimka slažu o tupleu, a tunel i dalje ne radi, prevođenje nije vaš problem; prijeđite na rukovanje i na tablicu usmjeravanja unutar tunela.