NAT vendos cilën adresë burimore sheh në të vërtetë serveri juaj VPN

Ju e imagjinoni serverin VPN duke lexuar adresën e laptopit tuaj nga paketa dhe duke e shkruar në një regjistër. Ajo që lexon është ajo që hopi i fundit NAT vendosi në krye të jashtme, dhe në një telefon të përdorur si hotspot kjo është shpesh një adresë e ndarë me qindra abonentë të tjerë. Adresa e vetë makinës tuaj 192.168.x.x nuk e kalon kurrë internetin në atë krye, dhe adresa e tunelit jepet nga serveri pasi lidhja është tashmë e vendosur. Pra, kur regjistri i serverit dhe ip addr në laptop nuk përputhen, asnjëri nuk është i gabuar; ata përshkruajnë shtresa të ndryshme të një sesioni.

Tre adresa, dhe vetëm një është në regjistër

Konfuzioni vjen nga zvogëlimi i tre adresave në një. Secila ka pronar tjetër, jeton në një krye tjetër dhe arrin serverin në një rrugë tjetër.

Vetëm rreshti i mesëm është i panjohur në momentin e lidhjes. Serveri e shkruan atë në tabelën e partnerëve, skedarin e statusit ose regjistrin e rrjedhave sipas demonit: WireGuard e quan pikë fundore, një skedar statusi i OpenVPN e etiketon si Real Address, dhe strongSwan e raporton si hostin e largët të IKE_SA. Kjo vlerë rifreskohet sa herë që vjen një paketë nga një burim tjetër, kështu që ndryshon pa rinisur askush asgjë.

Rreshti i poshtëm është ajo që njerëzit lexojnë gabimisht si një pretendim identiteti. Ai shënon një vend në konfigurimin e serverit, jo një person, sepse serveri e zgjodhi nga grupi i vet. Dy përdorues mund të marrin të njëjtën adresë tuneli në ditë të ndryshme, dhe njëri mund të mbajë dy prej tyre nga dy pajisje.

Pse tuple i regjistruar ndryshon ndërsa tuneli mbetet aktiv

Përkthimi i adresave është një tabelë me kohëmatës, jo një lidhje e përhershme. Një router shtëpiak e mban hartëzimin UDP për një kohë pas paketës së fundit, një portë e operatorit riciklon portat sipas orarit të vet, dhe një telefon që kalon nga Wi-Fi në LTE kthehet me një burim krejt tjetër. Vlerat e parazgjedhura të conntrack në Linux janë një pikë referimi e dobishme këtu: nf_conntrack_udp_timeout është 30 sekonda dhe varianti i transmetimit është 120, kështu që një tunel i qetë mund ta humbasë hartëzimin shumë përpara se përdoruesi ta vërë re.

Tuneli mbijeton sepse protokolli vërteton partnerin, jo adresën. WireGuard është pa gjendje pas shtrëngimit të duarve, kështu që çdo paketë e vërtetuar përditëson pikën fundore të ruajtur dhe rildhja shërohet në paketën tjetër; për këtë ekziston persistent-keepalive = 25, për ta mbajtur hartëzimin të ngrohtë gjatë pasivitetit. --float i OpenVPN bën të njëjtën gjë dhe lejon një klient të vërtetuar të vazhdojë nga një adresë dhe port i ri. Në ndërtimet 2.4 dhe 2.5 ku float është i fikur si parazgjedhje, rildhja rivendos sesionin dhe klienti rilidhet.

IPsec arrin atje me më shumë pjesë lëvizëse. IKEv2 e vëren përkthimin duke krahasuar hash-et e burimit dhe destinacionit në ngarkesat e zbulimit të NAT, kalon në inkapsulimin UDP 4500 dhe ndjek keepalive deri në tuple e re. Kur keepalive bllokohen, SA mbetet aktiv në letër ndërsa trafiku në një drejtim ndalon në heshtje.

Çfarë mund t'i atribuojë serveri, dhe çfarë jo

Miti që meriton të vritet është se përkthimi ju fsheh nga operatori. Ai ndryshon etiketën, jo vëzhgimin. Një portë pas NAT-it të operatorit sheh hapësirën 100.64.0.0/10 ose një adresë publike të ndarë nga shumë abonentë, dhe prapë mund ta lidhë rrjedhën me subjektin e certifikatës, çelësin publik të WireGuard, adresën e tunelit të caktuar, numëruesit e bajteve dhe një dritare kohore. Asnjë prej këtyre nuk ka nevojë për adresën tuaj LAN.

Kufijtë shkojnë edhe në drejtimin tjetër. Një adresë e ndarë në një regjistër tregon një portë, jo një familje; dy sesione nga e njëjta adresë e përkthyer në porta të ndryshme janë pajisje të ndryshme; e njëjta adresë në dy ditë të ndryshme mund të jenë dy abonentë të palidhur nëse porta u riciklua. Një server që regjistron vetëm çelësat e partnerëve nuk mund t'i lidhë ata me një klient pa bazën e të dhënave të llogarive, dhe një server që regjistron vetëm adresa nuk mund të dallojë një laptop nga një telefon pas të njëjtit router.

Krahasoni të dy skajet në vend që të hamendësoni

Për të sqaruar çfarë ndodhi, kapni të njëjtën lidhje në të dy skajet në të njëjtin moment dhe krahasoni tuple, jo adresën. Në klient, përpara çdo përkthimi:

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

Më pas lexoni hyrjen e përkthimit në router ose në portën CGNAT, dhe atë që më në fund arrin në server:

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

Tre modele shpjegojnë shumicën e mospërputhjeve. Porta e burimit në server ndryshon nga porta lokale ndërsa destinacioni përputhet: përkthim i zakonshëm i portave. Adresa e burimit në server i përket një blloku ISP që nuk është i juaji: të paktën një shtresë shtesë NAT. Paketat ndalen pas një periudhe pasiviteti dhe rifillojnë me një port të re: hartëzimi ka skaduar, jo një defekt rrugëtimi. Nëse vulat kohore janë më shumë se një ose dy sekonda larg, po krahasoni dy përpjekje të ndryshme.

Ku ndryshimi i prish gjërat

Ndërprerjet që duken si defekte serveri zakonisht fillojnë këtu. Një rregull hyrjeje i fiksuar në adresën tuaj të shtëpisë dështon pasi ndryshon qiraja e ISP-së. Një rregull fail2ban që përputhet me një adresë të përkthyer bllokon të gjithë abonentët pas asaj porte menjëherë. Një partner sajt-më-sajt me adresë të largët fikse ndalon rinovimin e çelësave pasi ndryshon një lidhje celulare. Protokolli i tunelit ishte në rregull; supozimi për tuple e jashtme nuk ishte.

I njëjti konfuzion shfaqet edhe në anën e serverit. Nëse vetë kutia VPN qëndron pas NAT, ju nevojitet përcjellje porte dhe një rrugë përcjelljeje funksionale; udhëzuesi i përcjelljes së strongSwan mbulon atë rast për IPsec. Një server i arritshëm vetëm në një adresë private nuk e sheh kurrë tuple e përkthyer që paraqesin klientët e tij, dhe ky është një problem tjetër nga përkthimi i klientëve.

Kaloni nëpër këto katër kontrolle me radhë dhe ndaloni në të parin që dështon:

• Kapni në të dy skajet në të njëjtën kohë; konfirmoni që porta e burimit, porta e destinacionit dhe vulat kohore përputhen.
• Lexoni listën e partnerëve të serverit për adresën që mban tani, jo atë që prisnit.
• Kontrolloni tabelën conntrack ose NAT për hyrjen dhe jetën e saj të mbetur.
• Konfirmoni që adresa e ndërfaqes së tunelit në klient përputhet me atë të caktuar nga serveri, jo me adresën LAN.

Nëse të dy kapjet bien dakord për tuple dhe tuneli prapë dështon, përkthimi nuk është problemi juaj; kaloni te shtrëngimi i duarve dhe te tabela e rrugëtimit brenda tunelit.