Jūs iedomājaties, ka VPN serveris nolasa jūsu klēpjdatora adresi no paketes un ieraksta to žurnālā. Tas, ko tas nolasa, ir tas, ko pēdējais NAT lēciens ievietoja ārējā galvenē, un telefonā, kas tiek izmantots kā piekļuves punkts, tas bieži ir adrese, ko dala simtiem citu abonentu. Jūsu ierīces pašas 192.168.x.x adrese nekad nešķērso internetu šajā galvenē, un tuneļa adresi serveris piešķir pēc tam, kad savienojums jau ir izveidots. Tāpēc, kad servera žurnāls un ip addr klēpjdatorā nesakrīt, neviens no tiem nav nepareizs; tie apraksta dažādus vienas sesijas slāņus.

Trīs adreses, un žurnālā ir tikai viena

Apjukums rodas, kad trīs adreses tiek savedītas vienā. Katrai ir cits īpašnieks, tā dzīvo citā galvenē un sasniedz serveri pa citu ceļu.

AddressWho assigns itWhere it sitsVisible to the VPN server
Device address, e.g. 192.168.1.24Your router via DHCPOuter header, before translationNo, rewritten in place
Translated address and portRouter, ISP CGNAT, or bothOuter header, after translationYes, this is the tuple it logs
Tunnel address, e.g. 10.8.0.6The VPN server itselfInner header, after decapsulationYes, but it chose it

Tikai vidējā rinda savienošanās brīdī nav zināma. Serveris to ieraksta savā partneru tabulā, stāvokļa failā vai plūsmas žurnālā atkarībā no dēmona: WireGuard to sauc par galapunktu, OpenVPN stāvokļa fails to apzīmē kā Real Address, un strongSwan to ziņo kā IKE_SA attālo resursdatoru. Šī vērtība tiek atjaunināta katru reizi, kad pienāk pakete no cita avota, tāpēc tā mainās, nevienam neko nepārstartējot.

Apakšējā rinda ir tas, ko cilvēki kļūdaini nolasa kā identitātes apgalvojumu. Tā iezīmē vietu servera konfigurācijā, nevis personu, jo serveris to izvēlējās no sava kopuma. Divi lietotāji dažādās dienās var saņemt vienu un to pašu tuneļa adresi, un viens var turēt divas no divām ierīcēm.

Kāpēc ierakstītais kortežs mainās, kamēr tunelis paliek aktīvs

Adrešu tulkošana ir tabula ar taimeri, nevis pastāvīga piesaiste. Mājas maršrutētājs savu UDP kartējumu tur vēl kādu laiku pēc pēdējās paketes, operatora vārteja pārstrādā portus pēc sava grafika, un tālrunis, kas pāriet no Wi-Fi uz LTE, atgriežas ar pavisam citu avotu. Linux conntrack noklusējuma vērtības šeit ir noderīgs mērs: nf_conntrack_udp_timeout ir 30 sekundes, bet straumēšanas variants ir 120, tāpēc kluss tunelis var zaudēt kartējumu daudz agrāk, nekā lietotājs to pamanīs.

Tunelis izdzīvo tāpēc, ka protokols autentificē partneri, nevis adresi. WireGuard pēc roku saspiestas ir bez stāvokļa, tāpēc jebkura autentificēta pakete atjaunina saglabāto galapunktu, un pārsaiste izlabojas nākamajā paketē; tāpēc pastāv persistent-keepalive = 25, lai kartējums dīkstāves laikā paliktu silts. OpenVPN --float dara to pašu un ļauj autentificētam klientam turpināt no jaunas adreses un porta. 2.4 un 2.5 būvējumos, kur float pēc noklusējuma ir izslēgts, pārsaiste atiestata sesiju, un klients pievienojas no jauna.

IPsec tur nokļūst ar vairāk kustīgām daļām. IKEv2 pamana tulkojumu, salīdzinot avota un galamērķa jaucējus NAT noteikšanas kravā, pāriet uz UDP 4500 iekapsulēšanu un seko keepalive līdz jaunajam kortežam. Kad keepalive tiek bloķēti, SA paliek aktīvs tikai uz papīra, kamēr trafiks vienā virzienā klusi apstājas.

Ko serveris var attiecināt un ko ne

Mīts, ko ir vērts nogalināt, ir tas, ka tulkošana jūs slēpj no operatora. Tā maina etiķeti, nevis novērojumu. Vārteja aiz operatora NAT redz 100.64.0.0/10 telpu vai vienu publisku adresi, ko dala daudzi abonenti, un joprojām var piesaistīt plūsmu sertifikāta subjektam, WireGuard publiskajai atslēgai, piešķirtajai tuneļa adresei, baitu skaitītājiem un laika logam. Nevienam no tiem nav vajadzīga jūsu LAN adrese.

Robežas darbojas arī pretējā virzienā. Kopīga adrese žurnālā norāda uz vārteju, nevis mājsaimniecību; divas sesijas no vienas pārtulkotās adreses dažādos portos ir dažādas ierīces; viena un tā pati adrese divās dažādās dienās var būt divi nesaistīti abonenti, ja ports tika pārstrādāts. Serveris, kas reģistrē tikai partneru atslēgas, bez kontu datubāzes nevar tās piesaistīt klientam, un serveris, kas reģistrē tikai adreses, nevar atšķirt klēpjdatoru no tālruņa aiz tā paša maršrutētāja.

Salīdziniet abus galus, nevis miniet

Lai noskaidrotu, kas notika, ierakstiet to pašu savienojumu abos galos vienā un tajā pašā mirklī un salīdziniet kortežu, nevis adresi. Klientā, pirms jebkādas tulkošanas:

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

Pēc tam izlasiet tulkošanas ierakstu maršrutētājā vai CGNAT vārtejā un to, kas beidzot nonāk serverī:

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

Trīs modeļi izskaidro lielāko daļu neatbilstību. Servera avota ports atšķiras no vietējā porta, kamēr galamērķis sakrīt: parasta portu tulkošana. Servera avota adrese pieder ISP blokam, kas nav jūsējais: vismaz viens papildu NAT slānis. Paketes apstājas pēc dīkstāves un atsākas ar jaunu portu: kartējums ir beidzies, nevis maršrutēšanas kļūda. Ja laikspiedoli atšķiras vairāk nekā par sekundi vai divām, jūs salīdzināt divus dažādus mēģinājumus.

Kur atšķirība salauž lietas

Pārtraukumi, kas izskatās kā servera kļūdas, parasti sākas šeit. Piekļuves noteikums, kas piesaistīts jūsu mājas adresei, neizdodas pēc ISP nomas maiņas. fail2ban noteikums, kas atbilst pārtulkotajai adresei, uzreiz aizliedz visus abonentus aiz šīs vārtejas. Vietnes-uz-vietni partneris ar fiksētu attālo adresi pārstāj atjaunināt atslēgas pēc mobilā savienojuma maiņas. Tuneļa protokols bija kārtībā; pieņēmums par ārējo kortežu ne.

Tas pats apjukums parādās arī servera pusē. Ja pati VPN kaste atrodas aiz NAT, jums vajag porta pāradresāciju un strādājošu pāradresācijas ceļu; strongSwan pāradresācijas rokasgrāmata aptver šo gadījumu IPsec. Serveris, kas pieejams tikai privātā adresē, nekad neredz pārtulkoto kortežu, ko piedāvā tā klienti, un tā ir cita problēma nekā klientu tulkošana.

Veiciet šīs četras pārbaudes pēc kārtas un apstājieties pie pirmās, kas neizdodas:

  • Ierakstiet abos galos vienlaikus; pārliecinieties, ka avota ports, galamērķa ports un laikspiedoli sakrīt.
  • Servera partneru sarakstā izlasiet adresi, kas tam šobrīd ir, nevis to, ko gaidījāt.
  • Pārbaudiet conntrack vai NAT tabulu par ierakstu un tā atlikušo mūžu.
  • Pārliecinieties, ka tuneļa saskarnes adrese klientā atbilst servera piešķirtajai, nevis LAN adresei.

Ja abi ieraksti sakrīt par kortežu un tunelis joprojām neizdodas, tulkošana nav jūsu problēma; pārejiet pie roku saspiestas un maršrutēšanas tabulas tuneļa iekšpusē.

Saistītie raksti