WireGuard veikia mobiliaisiais duomenimis, bet ne tame pačiame wifi tinkle
Užklausa iš LAN vidaus į viešą maršrutizatoriaus adresą eina kitu keliu nei užklausa mobiliaisiais duomenimis. Išbandykite iš išorės ir tada pasirinkite vietinį kelią.
Tunelis pakyla mobiliaisiais duomenimis ir paskui namuose lieka ties jungiamasi, su tuo pačiu profiliu, tuo pačiu peer raktu ir be jokio konfigūracijos pakeitimo tarp jų. Skirtumas yra kelyje: užklausa iš LAN vidaus į viešą maršrutizatoriaus adresą nėra ta pati kelionė kaip užklausa, ateinanti iš interneto. Dauguma namų tinklų vartų arba visai neįgyvendina grįžimo kelio, arba įgyvendina jį tik tam tikriems protokolams. Dėl to simptomas atrodo kaip sugedęs raktas, nors rakte niekas nepasikeitė. Nustatykite, kuris kelias nepavyko, prieš liesdami raktą, prievado persiuntimą ar kliento profilį.
Vienas adresas, du skirtingi keliai
Iš išorės paketas pasiekia viešą maršrutizatoriaus adresą, o prievado persiuntimo taisyklė perduoda jį WireGuard klausytojui vidiniame kompiuteryje. Iš vidaus klientas renkasi tą patį viešą adresą, todėl paketas palieka klientą, pasiekia maršrutizatorių ir turi būti atsuktas atgal į LAN. Būtent tame atsukime abu keliai išsiskiria, nes maršrutizatorius turi išversti srautą, kuris kartu išeina ir vėl įeina per tą pačią sąsają. Daugelis įgyvendinimų jį išmeta, o ne išverčia, ir klientas tada laukia rankos paspaudimo, kuris nebuvo niekada išsiųstas.
Toks elgesys paprastai vadinamas NAT loopback arba hairpinning ir priklauso maršrutizatoriui, o ne WireGuard; RFC 4787 aprašo vertimo atvejus, kai vartai gali tai palaikyti arba ne. Pats WireGuard neturi nuomonės apie kelią, nes mato tik paketus, pasiekiančius jo sąsają. Kai maršrutizatorius išmeta srautą, demonas niekada nieko negauna, klientas praneša apie rankos paspaudimo laiko pabaigą, o serverio žurnalas lieka tuščias. Tuščias žurnalas todėl yra užuomina, kur paketas sustojo, o ne įrodymas, kad serveris nukrito. Tai ir priežastis, kodėl perdiegimas nieko nekeičia.
Priešingybė taip pat svarbi: serverio žurnalas, rodantis rankos paspaudimo bandymą iš LAN adreso, įrodo, kad paketas atėjo ir kelias tvarkingas, o tai perkelia tyrimą prie raktų ir leidžiamų adresų. Skaitykite žurnalą dėl to, ką jis įrodo, o ne dėl to, ką tikėjotės pamatyti.
Pirmiausia atkurkite, tada keiskite
Išbandykite iš įgalioto išorinio tinklo su tuo pačiu įrenginiu ir tuo pačiu profiliu, tada pakartokite bandymą LAN viduje nieko neredaguodami. Užbaigtas rankos paspaudimas lauke ir klientas, kuris viduje niekada nepalieka įrenginio, atkuria būseną, o ne spėlioja. Abu bandymai turi naudoti tą patį profilį, kitaip palyginimas nieko neįrodo.
Tada pažiūrėkite, į ką išsprendžiamas galinio taško vardas šiam įrenginiui. Šios trys komandos taip pat parodo, kokį adresą klientas iš tikrųjų rinkosi:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netPirmoji komanda praneša galinį tašką, kurį sąsaja naudoja dabar, o kitos dvi parodo, į ką vardas išsprendžiamas šiame kompiuteryje. Klientas, kuris renkasi viešą adresą būdamas tame pačiame tinkle kaip serveris, naudoja hairpin kelią. Klientas, kuris renkasi LAN adresą, to nedaro, ir gedimas ten priklauso kitam tyrimui. Šis skirtumas nusprendžia, ar kitas skyrius apskritai taikomas.
Palaikomi būdai pasiekti netoliese esantį serverį
Švariausias išdėstymas yra padalinto horizonto atsakymas: viešas vardas išsprendžiamas į viešą adresą internetui ir į serverio LAN adresą klientams viduje. Profilis laiko vieną galinio taško vardą, o sprendėjas pasirenka kelią. Tam reikia kontrolės, kaip atsakoma vidiniu DNS, ką namų maršrutizatorius paprastai siūlo, o organizacija gali sąmoningai sutvarkyti. Be šios kontrolės lieka maršrutizatoriaus funkcija arba antras profilis.
Maršrutizatoriaus funkcija yra atspindys: vartai išverčia srautą iš vidaus į išorę ir nusiunčia jį atgal į vidų. Kur ji veikia, kliento pakeitimo nereikia, o kur neveikia, jokia kliento nuostata jos neišgelbės. Išbandykite ją stebėdami serverio žurnalą vidinio bandymo metu, o ne skaitydami maršrutizatoriaus funkcijų sąrašą.
Profilio pakeitimas į privatų adresą yra diagnostika, o ne projektas. Tai įrodo, kad serveris atsako LAN tinkle, ir sugadina tą patį profilį tą akimirką, kai nešiojamas kompiuteris išvažiuoja iš namų.
| 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 |
Išlaikykite profilį tinkamą naudoti ne namuose
Kad ir kokį kelią pasirinktumėte, palikite tapatybės patikrą ramybėje. Galinio taško adresas nėra peer tapatybė, o adreso pasikeitimas niekada nepateisina svetimo viešo rakto, kuris atsitiktinai atsako, priėmimo. WireGuard autentifikuoja raktu, todėl neteisingas kompiuteris nepraeina rankos paspaudimo, o ne suteikia prieigą prie ko nors netikėto.
Jei viešas adresas pasislenka, dinaminis DNS yra tai, kas palaiko vardą naudingu, o kliento atnaujinimo elgsena nusprendžia, kaip greitai pakeitimas atkeliaus. Išbandykite tai iš išorės po adreso pakeitimo, nes LAN atvejis to negali patvirtinti. Saugokitės sprendėjo, kuris kaupia seną atsakymą ilgiau nei įrašo gyvavimo laikas. Vardas, kuris vis dar rodo į ankstesnį adresą, atrodo lygiai taip pat kaip nukritęs serveris.
Užrašykite, kokį vardą naudoja profilis ir į ką jis išsprendžiamas kiekvienoje ribos pusėje. Profilis, kuris priklauso nuo maršrutizatoriaus funkcijos, kurios niekas neužfiksavo, yra pagalbos skambutis, laukiantis kito programinės aparatinės įrangos atnaujinimo. Užrašas taip pat pasako kitam žmogui, ar vidinis gedimas yra žinomas hairpin atvejis, ar kažkas naujo.