WireGuard funksionon me të dhëna celulare, por jo në të njëjtin wifi
Një kërkesë nga brenda LAN-it drejt adresës publike të routerit ndjek një rrugë tjetër sesa një me të dhëna celulare. Provoni jashtë dhe më pas zgjidhni një rrugë lokale.
Tuneli ngrihet mbi të dhëna celulare dhe më pas qëndron te lidhja në shtëpi, me të njëjtin profil, të njëjtën çelës peer dhe pa asnjë ndryshim konfigurimi në mes. Diferenca qëndron në udhëtim: një kërkesë nga brenda LAN-it drejt adresës publike të routerit nuk është i njëjti udhëtim si një kërkesë që vjen nga interneti. Shumica e gateway-ve shtëpiake ose nuk e zbatojnë rrugën e kthimit ose e zbatojnë vetëm për protokolle të caktuara. Kjo e bën simptomën të duket si çelës i prishur ndërsa asgjë te çelësi nuk ka lëvizur. Përcaktoni cila rrugë dështoi përpara se të prekni një çelës, një ridrejtim porti ose një profil klienti.
Një adresë, dy rrugë të ndryshme
Nga jashtë, një paketë arrin adresën publike të routerit dhe një rregull ridrejtimi porti ia dorëzon dëgjuesit WireGuard në hostin e brendshëm. Nga brenda, klienti thërret të njëjtën adresë publike, kështu që paketa largohet nga klienti, arrin te routeri dhe duhet të kthehet përsëri drejt LAN-it. Është pikërisht në atë kthim ku dy rrugët ndahen, sepse routeri duhet të përkthejë një rrjedhë që del dhe rihyn në të njëjtin ndërfaqe. Shumë zbatime e hedhin poshtë në vend që ta përkthejnë, dhe klienti atëherë pret një shtrëngim duarsh që nuk u dërgua kurrë.
Sjellja zakonisht quhet NAT loopback ose hairpinning, dhe i përket routerit dhe jo WireGuard; RFC 4787 parashtron rastet e përkthimit në të cilat një gateway mund ta mbështesë ose jo. WireGuard vetë nuk ka mendim për rrugën, sepse sheh vetëm paketa që arrijnë në ndërfaqen e tij. Kur routeri e hedh rrjedhën, daemoni nuk merr kurrë asgjë, klienti raporton një afat kohor të shtrëngimit të duarve dhe regjistri i serverit mbetet bosh. Një regjistër bosh është pra një të dhënë se ku u ndal paketa, jo provë që serveri është poshtë. Është gjithashtu arsyeja pse riinstalimi nuk ndryshon asgjë.
E kundërta gjithashtu ka rëndësi: një regjistër serveri që tregon një përpjekje shtrëngimi duarsh nga adresa e LAN-it provon që paketa arriti dhe rruga është në rregull, gjë që e zhvendos hetimin te çelësat dhe adresat e lejuara. Lexoni regjistrin për atë që provon, jo për atë që shpresonit të shihnit.
Riprodhojeni përpara se të ndryshoni diçka
Provoni nga një rrjet i jashtëm i autorizuar me të njëjtin pajisje dhe të njëjtin profil, më pas përsëriteni provën brenda LAN-it pa redaktuar asgjë. Një shtrëngim duarsh i përfunduar jashtë dhe një klient që brenda nuk e lë kurrë pajisjen riprodhojnë gjendjen në vend që ta hamendësojnë. Të dyja përpjekjet duhet të përdorin të njëjtin profil, përndryshe krahasimi nuk provon asgjë.
Më pas shikoni se çfarë zgjidh emri i pikës fundore për këtë pajisje. Tre komandat e mëposhtme tregojnë gjithashtu cilën adresë klienti thirri në të vërtetë:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netKomanda e parë raporton pikën fundore që ndërfaqja po përdor tani, dhe dy të tjerat tregojnë se çfarë zgjidh emri në këtë makinë. Një klient që thërret një adresë publike ndërsa ndodhet në të njëjtin rrjet si serveri po ushtron rrugën hairpin. Një klient që thërret adresën e LAN-it nuk e bën këtë, dhe një dështim atje i përket një hetimi tjetër. Ai dallim vendos nëse seksioni vijues zbatohet fare.
Mënyra të mbështetura për të arritur një server aty pranë
Rregullimi më i pastër është një përgjigje me horizont të ndarë: emri publik zgjidhet në adresën publike për internetin dhe në adresën LAN të serverit për klientët brenda. Profili mban një emër të vetëm pike fundore dhe zgjidhësi zgjedh rrugën. Kjo kërkon kontroll mbi përgjigjen e brendshme DNS, të cilën një router shtëpiak zakonisht e ofron dhe një organizatë mund ta rregullojë me qëllim. Pa atë kontroll, zgjedhjet e mbetura janë një funksion routeri ose një profil i dytë.
Funksioni i routerit është reflektimi: gateway-i e përkthen rrjedhën nga brenda jashtë dhe e kthen përsëri brenda. Aty ku funksionon nuk kërkon asnjë ndryshim klienti, dhe aty ku nuk funksionon asnjë cilësim klienti nuk e shpëton. Provojeni duke vëzhguar regjistrin e serverit gjatë një përpjekjeje të brendshme në vend që të lexoni listën e funksioneve të routerit.
Redaktimi i profilit në një adresë private është diagnozë, jo projektim. Provon që serveri përgjigjet në LAN, dhe e prish të njëjtin profil në momentin që laptopi largohet nga shtëpia.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Mbani profilin të përdorshëm larg shtëpisë
Çfarëdo rruge që zgjidhni, lini rehat kontrollin e identitetit. Adresa e pikës fundore nuk është identiteti i peer-it, dhe një ndryshim adrese nuk justifikon kurrë pranimin e një çelësi publik të huaj që ndodh të përgjigjet. WireGuard vërteton me çelësin, kështu që një host i gabuar dështon në shtrëngimin e duarve në vend që të japë akses në diçka të papritur.
Nëse adresa publike lëviz, DNS dinamike është ajo që e mban emrin të dobishëm, dhe sjellja e rifreskimit të klientit vendos sa shpejt arrin ndryshimi. Provojeni nga jashtë pas një ndryshimi adrese, sepse rasti i LAN-it nuk mund ta vërtetojë. Kini kujdes nga një zgjidhës që ruan në cache përgjigjen e vjetër përtej jetëgjatësisë së regjistrimit. Një emër që ende tregon adresën e mëparshme duket saktësisht si një server që ra.
Shkruani cilin emër përdor profili dhe çfarë zgjidh në secilën anë të kufirit. Një profil që varet nga një funksion routeri që askush nuk e regjistroi është një telefonatë mbështetjeje që pret përditësimin e ardhshëm të firmware. Shënimi është gjithashtu ai që i thotë personit tjetër nëse një dështim i brendshëm është rasti i njohur hairpin apo diçka e re.