NAT odloča, kateri izvorni naslov vaš VPN strežnik v resnici vidi

Predstavljate si, da VPN strežnik prebere naslov vašega prenosnika iz paketa in ga zapiše v dnevnik. Kar prebere, je tisto, kar je zadnji NAT skok vstavil v zunanjo glavo, na telefonu, ki deluje kot dostopna točka, pa je to pogosto naslov, ki si ga deli na stotine drugih naročnikov. Lastni naslov vašega računalnika 192.168.x.x v tej glavi nikoli ne prečka interneta, naslov predora pa strežnik dodeli šele po vzpostavitvi povezave. Ko se dnevnik strežnika in ip addr na prenosniku ne ujemata, torej nobeden ni napačen; opisujeta različne plasti ene seje.

Trije naslovi, v dnevniku pa le eden

Zmeda nastane, ker se trije naslovi stisnejo v enega. Vsak ima drugega lastnika, živi v drugi glavi in doseže strežnik po drugi poti.

Ob povezavi ni znana le srednja vrstica. Strežnik jo zapiše v svojo tabelo partnerjev, statusno datoteko ali dnevnik tokov glede na demona: WireGuard jo imenuje končna točka, statusna datoteka OpenVPN jo označi kot Real Address, strongSwan pa jo sporoči kot oddaljenega gostitelja IKE_SA. Ta vrednost se osveži vsakič, ko pride paket z drugega vira, zato se spremeni, ne da bi kdor koli kar koli znova zagnal.

Spodnja vrstica je tisto, kar ljudje napačno berejo kot trditev o identiteti. Označuje mesto v konfiguraciji strežnika, ne osebe, ker jo je strežnik izbral iz svojega nabora. Dva uporabnika lahko različne dni dobita isti naslov predora, eden pa ima lahko dva z dveh naprav.

Zakaj se zabeleženi tuple spreminja, medtem ko predor ostaja aktiven

Prevajanje naslovov je tabela s časovnikom, ne trajna vezava. Domači usmerjevalnik svojo preslikavo UDP hrani še nekaj časa po zadnjem paketu, prehod operaterja reciklira vrata po svojem urniku, telefon, ki preide z Wi-Fi na LTE, pa se vrne s povsem drugim virom. Privzete vrednosti conntracka v Linuxu so tu koristno merilo: nf_conntrack_udp_timeout je 30 sekund, različica za pretakanje pa 120, zato lahko tih predor izgubi preslikavo veliko prej, preden uporabnik to opazi.

Predor preživi, ker protokol overi partnerja, ne naslova. WireGuard je po rokovanju brez stanja, zato vsak overjen paket posodobi shranjeno končno točko in ponovna vezava se popravi pri naslednjem paketu; zato obstaja persistent-keepalive = 25, da ohrani preslikavo toplo med mirovanjem. --float v OpenVPN opravi isto delo in overjenemu odjemalcu omogoči nadaljevanje z novega naslova in vrat. V različicah 2.4 in 2.5, kjer je float privzeto izklopljen, ponovna vezava ponastavi sejo in odjemalec se znova poveže.

IPsec tja pride z več gibljivimi deli. IKEv2 prevajanje zazna s primerjavo zgoščenih vrednosti vira in cilja v koristnem tovoru zaznavanja NAT, preide na enkapsulacijo UDP 4500 in sledi keepalive do novega tupla. Ko so keepalive blokirani, SA ostane na papirju aktiven, promet v eno smer pa se tiho ustavi.

Kaj lahko strežnik pripiše in česa ne

Mit, ki si ga je vredno ubiti, je, da vas prevajanje skrije pred operaterjem. Spremeni oznako, ne opazovanja. Prehod za NAT operaterja vidi prostor 100.64.0.0/10 ali en javni naslov, ki si ga deli veliko naročnikov, in lahko tok vseeno poveže s subjektom potrdila, javnim ključem WireGuarda, dodeljenim naslovom predora, števci bajtov in časovnim oknom. Nič od tega ne potrebuje vašega naslova LAN.

Meje veljajo tudi v drugo smer. Skupni naslov v dnevniku kaže na prehod, ne na gospodinjstvo; dve seji z istega prevedenega naslova na različnih vratih sta različni napravi; isti naslov dva različna dneva lahko pomeni dva nepovezana naročnika, če so bila vrata reciklirana. Strežnik, ki beleži le ključe partnerjev, jih brez podatkovne baze računov ne more pripisati odjemalcu, strežnik, ki beleži le naslove, pa ne loči prenosnika od telefona za istim usmerjevalnikom.

Primerjajte oba konca, namesto da ugibate

Da ugotovite, kaj se je zgodilo, zajemite isto povezavo na obeh koncih v istem trenutku in primerjajte tuple, ne naslova. Na odjemalcu, pred vsakršnim prevajanjem:

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

Nato preberite vnos prevajanja na usmerjevalniku ali prehodu CGNAT in tisto, kar nazadnje prispe na strežnik:

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

Trije vzorci pojasnijo večino odstopanj. Izvorna vrata na strežniku se razlikujejo od lokalnih vrat, medtem ko se cilj ujema: običajno prevajanje vrat. Izvorni naslov na strežniku pripada bloku ISP, ki ni vaš: vsaj ena dodatna plast NAT. Paketi se po obdobju nedejavnosti ustavijo in nadaljujejo z novimi vrati: preslikava je potekla, ne napaka usmerjanja. Če so časovni žigi več kot sekundo ali dve narazen, primerjate dva različna poskusa.

Kje razlika polomi stvari

Prekinitve, ki so videti kot okvare strežnika, se običajno začnejo tu. Pravilo dostopa, pripeto na vaš domači naslov, odpove po spremembi najema pri ISP. Pravilo fail2ban, ki se ujema s prevedenim naslovom, hkrati blokira vse naročnike za tem prehodom. Partner site-to-site s stalnim oddaljenim naslovom preneha obnavljati ključe po spremembi mobilne povezave. Protokol predora je bil v redu; predpostavka o zunanjem tuplu ni bila.

Ista zmeda se pojavi na strani strežnika. Če sama škatla VPN stoji za NAT, potrebujete posredovanje vrat in delujočo pot posredovanja; vodnik strongSwan za posredovanje pokriva ta primer za IPsec. Strežnik, dosegljiv le na zasebnem naslovu, nikoli ne vidi prevedenega tupla, ki ga predstavljajo njegovi odjemalci, in to je druga težava kot prevajanje odjemalcev.

Pojdite skozi te štiri preverbe po vrsti in ustavite se pri prvi, ki ne uspe:

• Zajemite na obeh koncih hkrati; potrdite, da se izvorna vrata, ciljna vrata in časovni žigi ujemajo.
• Preberite na seznamu partnerjev strežnika naslov, ki ga ta trenutno drži, ne tistega, ki ste ga pričakovali.
• Preverite tabelo conntrack ali NAT za vnos in njegovo preostalo življenjsko dobo.
• Potrdite, da se naslov predorskega vmesnika na odjemalcu ujema s tistim, ki ga je dodelil strežnik, ne z naslovom LAN.

Če se oba zajema ujemata glede tupla in predor še vedno ne deluje, prevajanje ni vaša težava; pojdite na rokovanje in na usmerjevalno tabelo znotraj predora.