NAT beslút hokker boarneadres jo VPN-tsjinner eins sjocht

Jo stelle jo foar dat de VPN-tsjinner it adres fan jo laptop fan it pakket lêst en it yn in log skriuwt. Wat er lêst is wat de lêste NAT-hop yn 'e bûtenste kop set hat, en op in tillefoan dy't as hotspot tsjinnet is dat faak in adres dat mei hûnderten oare abonnees dield wurdt. It eigen adres fan jo masine 192.168.x.x stekt nea yn dy kop oer it ynternet, en it tunneladres wurdt troch de tsjinner útjûn neidat de ferbining al oan is. As in tsjinnerlog en ip addr op 'e laptop dus fan elkoar ferskille, is net ien ferkeard; se beskriuwe ferskillende lagen fan ien sesje.

Trije adressen, en mar ien stiet yn it log

De betizing komt derfan dat trije adressen yn ien gearfette wurde. Elk hat in oare eigner, wennet yn in oare kop en berikt de tsjinner oer in oare wei.

Allinnich de middelste rige is ûnbekend op it momint fan ferbinen. De tsjinner skriuwt it yn syn peer-tabel, statusbestân of flowlog ôfhinklik fan 'e daemon: WireGuard neamt it it einpunt, in OpenVPN-statusbestân neamt it Real Address, en strongSwan rapportearret it as de ôfstiene host fan 'e IKE_SA. Dy wearde wurdt ferfarske as der in pakket fan in oare boarne komt, dus it feroaret sûnder dat immen wat opnij start.

De ûnderste rige is wat minsken ferkeard lêze as in identiteitsbewearing. It markearret in plak yn 'e tsjinnerkonfiguraasje, net in persoan, want de tsjinner hat it út syn eigen pool keazen. Twa brûkers kinne op ferskillende dagen itselde tunneladres krije, en ien kin twa fan dy fan twa apparaten hâlde.

Wêrom't de logde tuple feroaret wylst de tunnel oan bliuwt

Adresoersetting is in tabel mei in timer, net in permaninte bining. In thúsrûter hâldt syn UDP-mapping in skoft nei it lêste pakket, in operator-gateway recyclaget poarten neffens syn eigen skema, en in tillefoan dy't fan Wi-Fi nei LTE giet komt mei in hiel oare boarne werom. De standertwearden fan conntrack yn Linux binne hjir in nuttige mjitstêf: nf_conntrack_udp_timeout is 30 sekonden en de streamingfariant is 120, dus in stil tunnel kin syn mapping ferlieze lang foardat de brûker it merkt.

De tunnel oerlibbet om't it protokol de peer autentisearret, net it adres. WireGuard is nei de handshake steatleas, dus elk autentisearre pakket fernijt it bewarre einpunt en in werbining genêst op it folgjende pakket; dêrom bestiet persistent-keepalive = 25, om de mapping waarm te hâlden wylst it idle is. De --float fan OpenVPN docht itselde en lit in autentisearre klant fan in nij adres en poarte ferfetsje. Op 2.4- en 2.5-buils wêr't float standert út is, set in werbining de sesje werom en de klant ferbynt opnij.

IPsec komt dêr mei mear bewegende dielen. IKEv2 merkt oersetting op troch de boarne- en bestimminghashes yn 'e NAT-deteksjepayloads te fergelykjen, giet oer op UDP 4500-ynkapseling en folget keepalives nei de nije tuple. As keepalives blokkearre wurde, bliuwt de SA op papier oan wylst ferkear yn ien rjochting stilwei stopet.

Wat de tsjinner taskriuwe kin, en wat net

De myte dy't dea moat is dat oersetting jo foar de operator ferstoppet. It feroaret it label, net de waarnimming. In gateway efter operator-NAT sjocht 100.64.0.0/10-romte of ien iepenbier adres dat troch in soad abonnees dield wurdt, en kin de stream dochs oan in sertifikaatûnderwerp, in WireGuard-iepenbiere kaai, in tawiisd tunneladres, byte-tellers en in tiidfinster keppelje. Nimmen fan dy hat jo LAN-adres nedich.

De grinzen geane ek de oare kant út. In dield adres yn in log wiist nei in gateway, net nei in húshâlding; twa sesjes fan itselde oersette adres op ferskillende poarten binne ferskillende apparaten; itselde adres op twa ferskillende dagen kin twa ûnbesibbe abonnees wêze as de poarte recyclaget is. In tsjinner dy't allinnich peer-kaaien registrearret kin ien net oan in klant keppelje sûnder de akkountdatabase, en in tsjinner dy't allinnich adressen registrearret kin in laptop net fan in tillefoan efter deselde rûter ûnderskiede.

Fergelykje beide einen ynstee fan te rieden

Om út te meitsjen wat der barde, fange deselde ferbining oan beide einen op itselde momint en fergelykje de tuple, net it adres. By de klant, foar elke oersetting:

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

Lês dan de oersettingsynfier op 'e rûter of CGNAT-gateway, en wat úteinlik by de tsjinner oankomt:

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

Trije patronen ferklearje de measte mispenskings. De boarne-poarte by de tsjinner ferskilt fan 'e lokale poarte wylst de bestimming oerienkomt: gewoane poartoersetting. It boarne-adres by de tsjinner heart ta in ISP-blok dat net fan jo is: teminsten ien ekstra NAT-laach. Pakketten stopje nei in idle perioade en ferfetsje mei in nije poarte: de mapping is ferrûn, net in routingflater. As de tiidstimpels mear as in sekonde of twa útinoar lizze, fergelykje jo twa ferskillende pogingen.

Wêr't it ferskil dingen brekt

Underbrekkings dy't op tsjinnerflatens lykje begjinne meastentiids hjir. In tagongsregel fêstset oan jo thúsadres mislearret neidat de ISP-hier feroaret. In fail2ban-regel dy't op in oersette adres past, ferbant alle abonnees efter dy gateway tagelyk. In side-oan-side-peer mei in fêst ôfstien adres hâldt op mei kaaien fernijen neidat in mobylkeppeling feroaret. It tunnelprotokol wie goed; de oanname oer de bûtenste tuple wie dat net.

Deselde betizing docht him by de tsjinnerkant foar. As de VPN-doaze sels efter NAT sit, hawwe jo in poarttrochferwizing en in wurkjende trochferwizingspaad nedich; de strongSwan-trochferwizingsgids behannelet dat gefal foar IPsec. In tsjinner dy't allinnich op in privee-adres berikber is sjocht nea de oersette tuple dy't syn klanten presintearje, en dat is in oar probleem as dat klanten oerset wurde.

Wurkje dizze fjouwer kontrôles yn folchoarder troch en stop by de earste dy't mislearret:

• Fange oan beide einen tagelyk op; befêstigje dat boarne-poarte, bestimmingspoarte en tiidstimpels oerienkomme.
• Lês de peer-list fan 'e tsjinner foar it adres dat er no hâldt, net it adres dat jo ferwachten.
• Kontrolearje de conntrack- of NAT-tabel foar de ynfier en syn oerbleaune libbensdoer.
• Befêstigje dat it tunnelinterface-adres op 'e klant oerienkomt mei wat de tsjinner tawiisde, net it LAN-adres.

As beide opnames oer de tuple oerienkomme en de tunnel dochs mislearret, is oersetting net jo probleem; gean fierder nei de handshake en nei de routingtabel yn 'e tunnel.