NAT decidas, kiun fontan adreson via VPN-servilo efektive vidas

Vi imagas, ke la VPN-servilo legas la adreson de via tekkomputilo el la paketo kaj skribas ĝin en protokolon. Tio, kion ĝi legas, estas tio, kion la lasta NAT-salto metis en la eksteran kaplinion, kaj ĉe telefono uzata kiel alirpunkto tio ofte estas adreso dividata kun centoj da aliaj abonantoj. La propra adreso de via maŝino 192.168.x.x neniam transiras la reton en tiu kaplinio, kaj la tunelan adreson donas la servilo post kiam la konekto jam staras. Do kiam servila protokolo kaj ip addr sur la tekkomputilo malkongruas, nek unu estas malĝusta; ili priskribas malsamajn tavolojn de unu sesio.

Tri adresoj, kaj nur unu estas en la protokolo

La konfuzo venas de kunfandiĝo de tri adresoj en unu. Ĉiu havas alian posedanton, loĝas en alia kaplinio kaj atingas la servilon per alia vojo.

Nur la meza vico estas nekonata ĉe la konekta momento. La servilo skribas ĝin en sian samtavolan tabelon, statan dosieron aŭ fluan protokolon laŭ la demono: WireGuard nomas ĝin finpunkto, statdosiero de OpenVPN nomas ĝin Real Address, kaj strongSwan raportas ĝin kiel la malproksiman gastiganton de la IKE_SA. Tiu valoro refreŝiĝas ĉiufoje, kiam alvenas paketo el alia fonto, do ĝi ŝanĝiĝas sen ke iu restartigas ion ajn.

La suba vico estas tio, kion homoj mislegas kiel aserton pri identeco. Ĝi markas lokon en la servila agordo, ne personon, ĉar la servilo elektis ĝin el sia propra provizo. Du uzantoj povas ricevi la saman tunelan adreson en malsamaj tagoj, kaj unu povas teni du el ili el du aparatoj.

Kial la protokolita opo ŝanĝiĝas dum la tunelo restas aktiva

Adresa tradukado estas tabelo kun tempigilo, ne daŭra ligo. Hejma enkursigilo tenas sian UDP-mapadon iom post la lasta paketo, peranta kluzo reciklas pordojn laŭ sia propra horaro, kaj telefono, kiu transiras de Wi-Fi al LTE, revenas kun tute alia fonto. La aprioraj valoroj de conntrack en Linux estas utila mezurilo ĉi tie: nf_conntrack_udp_timeout estas 30 sekundoj kaj la fluada variaĵo estas 120, do kvieta tunelo povas perdi sian mapadon longe antaŭ ol la uzanto rimarkas.

La tunelo postvivas ĉar la protokolo aŭtentikigas la samtavolanon, ne la adreson. WireGuard estas senstata post la manpremo, do ĉiu aŭtentikigita paketo ĝisdatigas la konservitan finpunkton kaj religo resaniĝas ĉe la sekva paketo; tial ekzistas persistent-keepalive = 25, por teni la mapadon varma dum senaktiveco. La --float de OpenVPN faras la saman laboron, lasante aŭtentikigitan klienton daŭrigi el nova adreso kaj pordo. En versioj 2.4 kaj 2.5, kie float estas defaŭlte malŝaltita, religo restarigas la sesion kaj la kliento rekonektiĝas.

IPsec atingas tion kun pli da movaj partoj. IKEv2 rimarkas tradukadon komparante la haŝojn de fonto kaj celo en la NAT-detektaj ŝarĝoj, transiras al UDP 4500-enkapsuligo kaj sekvas keepalive-jn al la nova opo. Kiam keepalive-j estas blokitaj, la SA restas aktiva surpapere dum trafiko en unu direkto silente haltas.

Kion la servilo povas atribui, kaj kion ne

La mito inda mortigi estas, ke tradukado kaŝas vin de la operatoro. Ĝi ŝanĝas la etikedon, ne la observadon. Kluzo malantaŭ la NAT de operatoro vidas la spacon 100.64.0.0/10 aŭ unu publikan adreson dividatan de multaj abonantoj, kaj tamen povas ligi la fluon al certifikata subjekto, publika ŝlosilo de WireGuard, atribuita tunela adreso, bajtaj nombriloj kaj tempa fenestro. Nenio el tio bezonas vian LAN-adreson.

La limoj iras ankaŭ la alian direkton. Dividita adreso en protokolo montras al kluzo, ne al domanaro; du sesioj el la sama tradukita adreso sur malsamaj pordoj estas malsamaj aparatoj; la sama adreso en du malsamaj tagoj povas esti du nerilataj abonantoj se la pordo estis reciklita. Servilo, kiu registras nur samtavolajn ŝlosilojn, ne povas mapi unu al kliento sen la konta datumbazo, kaj servilo, kiu registras nur adresojn, ne povas distingi tekkomputilon de telefono malantaŭ la sama enkursigilo.

Komparu ambaŭ finojn anstataŭ diveni

Por klarigi, kio okazis, kaptu la saman konekton ĉe ambaŭ finoj sammomente kaj komparu la opon, ne la adreson. Ĉe la kliento, antaŭ ajna tradukado:

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

Poste legu la tradukan enskribon sur la enkursigilo aŭ la CGNAT-kluzo, kaj kio finfine alvenas al la servilo:

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

Tri ŝablonoj klarigas la plej multajn malkongruojn. La fonta pordo ĉe la servilo malsamas de la loka pordo dum la celo kongruas: ordinara porda tradukado. La fonta adreso ĉe la servilo apartenas al ISP-bloko, kiu ne estas via: almenaŭ unu plia NAT-tavolo. Paketoj haltas post senaktiva periodo kaj rekomenciĝas kun nova pordo: la mapado eksvalidiĝis, ne vojiga fuŝo. Se la tempindikoj estas pli ol unu aŭ du sekundojn apartaj, vi komparas du malsamajn provojn.

Kie la diferenco rompas aferojn

Interrompoj, kiuj aspektas kiel servilaj fuŝoj, kutime komenciĝas ĉi tie. Alirregulo fiksita al via hejma adreso malsukcesas post kiam la luo de la ISP ŝanĝiĝas. Regulo de fail2ban kongruanta kun tradukita adreso malpermesas ĉiujn abonantojn malantaŭ tiu kluzo samtempe. Site-to-site samtavolano kun fiksa malproksima adreso ĉesas renovigi ŝlosilojn post kiam mova ligilo ŝanĝiĝas. La tunela protokolo estis en ordo; la supozo pri la ekstera opo ne estis.

La sama konfuzo aperas ĉe la servila flanko. Se la VPN-skatolo mem staras malantaŭ NAT, vi bezonas pordan plusendadon kaj funkciantan plusendan vojon; la gvidilo de strongSwan pri plusendado kovras tiun kazon por IPsec. Servilo atingebla nur per privata adreso neniam vidas la tradukitan opon, kiun prezentas ĝiaj klientoj, kaj tio estas alia problemo ol tradukado de klientoj.

Trairu ĉi tiujn kvar kontrolojn laŭorde kaj haltu ĉe la unua, kiu malsukcesas:

• Kaptu ĉe ambaŭ finoj samtempe; konfirmu, ke la fonta pordo, la cela pordo kaj la tempindikoj kongruas.
• Legu en la samtavola listo de la servilo la adreson, kiun ĝi nun tenas, ne tiun, kiun vi atendis.
• Kontrolu la tabelon conntrack aŭ NAT por la enskribo kaj ĝia restanta vivodaŭro.
• Konfirmu, ke la adreso de la tunela interfaco ĉe la kliento kongruas kun tiu, kiun la servilo atribuis, ne kun la LAN-adreso.

Se ambaŭ kaptaĵoj kongruas pri la opo kaj la tunelo ankoraŭ malsukcesas, tradukado ne estas via problemo; daŭrigu al la manpremo kaj al la vojiga tabelo ene de la tunelo.