WireGuard töötab mobiilsetel andmetel, kuid mitte samas wifi-võrgus
Päring LAN-i seest ruuteri avalikule aadressile käib teist teed kui päring mobiilsete andmete kaudu. Katsetage väljastpoolt ja valige siis kohalik tee.
Tunnel tõuseb mobiilsetel andmetel ja jääb siis kodus ühendamise peale, sama profiili, sama peer-võtmega ja ilma konfiguratsiooni muudatuseta nende vahel. Erinevus on teekonnas: päring LAN-i seest ruuteri avalikule aadressile ei ole sama teekond kui internetist saabuv päring. Enamik koduväravaid kas ei rakenda tagasiteed üldse või rakendab seda ainult teatud protokollide jaoks. See teeb sümptomi katkise võtme moodi, kuigi võtmes pole midagi muutunud. Tehke kindlaks, milline tee ebaõnnestus, enne kui puudutate võtit, pordiedastust või kliendiprofiili.
Üks aadress, kaks erinevat teed
Väljastpoolt jõuab pakett ruuteri avalikule aadressile ja pordiedastuse reegel annab selle sisemises hostis olevale WireGuardi kuulajale. Seestpoolt valib klient sama avaliku aadressi, seega pakett lahkub kliendist, jõuab ruuterini ja tuleb tagasi LAN-i suunas pöörata. Just sellel pöördel lähevad kaks teed lahku, sest ruuter peab tõlkima voogu, mis samal ajal väljub ja siseneb uuesti läbi sama liidese. Paljud rakendused viskavad selle tõlkimise asemel ära ja klient ootab siis kätlust, mida kunagi ei saadetud.
Seda käitumist nimetatakse tavaliselt NAT loopbackiks või hairpinninguks ja see kuulub ruuterile, mitte WireGuardile; RFC 4787 kirjeldab tõlkekäsitlusi, mille puhul värav võib seda toetada või mitte. WireGuard ise teekonna kohta arvamust ei oma, sest näeb ainult pakette, mis jõuavad tema liidesele. Kui ruuter voo ära viskab, ei saa deemon kunagi midagi, klient teatab kätluse ajalõpust ja serveri logi jääb tühjaks. Tühi logi on seega vihje, kuhu pakett jäi, mitte tõestus, et server on maas. See on ka põhjus, miks uuesti paigaldamine midagi ei muuda.
Ka vastupidine loeb: serveri logi, mis näitab kätlusekatset LAN-i aadressilt, tõestab, et pakett jõudis kohale ja tee on korras, mis viib uurimise võtmete ja lubatud aadresside juurde. Lugege logi selle järgi, mida see tõestab, mitte selle järgi, mida lootsite näha.
Esmalt taastage, alles siis muutke
Katsetage volitatud välisvõrgust sama seadme ja sama profiiliga, seejärel korrake katset LAN-i sees midagi redigeerimata. Lõpetatud kätlus väljas ja klient, mis sees kunagi seadmest ei lahku, taastoodavad olukorra selle oletamise asemel. Mõlemad katsed peavad kasutama sama profiili, muidu ei tõesta võrdlus midagi.
Seejärel vaadake, milleks lõpp-punkti nimi selle seadme jaoks laheneb. Kolm järgmist käsku näitavad ka, millist aadressi klient tegelikult valis:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netEsimene käsk teatab lõpp-punkti, mida liides praegu kasutab, ja kaks ülejäänut näitavad, milleks nimi selles masinas laheneb. Klient, mis valib avaliku aadressi serveriga samas võrgus olles, kasutab hairpin-teed. Klient, mis valib LAN-i aadressi, seda ei tee, ja sealne tõrge kuulub teise uurimise juurde. See erinevus otsustab, kas järgmine jaotis üldse kehtib.
Toetatud viisid lähedase serverini jõudmiseks
Kõige puhtam lahendus on jagatud horisondi vastus: avalik nimi laheneb interneti jaoks avalikuks aadressiks ja sees olevate klientide jaoks serveri LAN-i aadressiks. Profiil hoiab üht lõpp-punkti nime ja resolver valib tee. See nõuab kontrolli sisemise DNS-vastuse üle, mida koduruuter tavaliselt pakub ja organisatsioon saab sihilikult korraldada. Ilma selle kontrollita jäävad valikusse ruuteri funktsioon või teine profiil.
Ruuteri funktsioon on peegeldus: värav tõlgib voo seest välja ja saadab selle tagasi sisse. Kus see töötab, ei nõua see kliendi muudatust, ja kus see ei tööta, ei päästa seda ükski kliendi seade. Katsetage seda serveri logi jälgides sisemise katse ajal, mitte ruuteri funktsioonide loendit lugedes.
Profiili muutmine privaatseks aadressiks on diagnostika, mitte projekt. See tõestab, et server vastab LAN-is, ja rikub sama profiili hetkel, mil sülearvuti majast lahkub.
| 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 |
Hoidke profiil kodust eemal kasutatavana
Millise tee ka valite, jätke identiteedikontroll rahule. Lõpp-punkti aadress ei ole peer-identiteet ja aadressi muutumine ei õigusta kunagi kõrvalise avaliku võtme vastuvõtmist, mis juhuslikult vastab. WireGuard autendib võtmega, seega vale host ebaõnnestub kätlusel, selle asemel et anda juurdepääs millelegi ootamatule.
Kui avalik aadress liigub, hoiab dünaamiline DNS nime kasulikuna ja kliendi värskenduskäitumine otsustab, kui kiiresti muudatus kohale jõuab. Katsetage seda väljastpoolt pärast aadressi muutust, sest LAN-i juhtum ei saa seda kinnitada. Jälgige resolverit, mis vahemällu salvestab vana vastuse kirje elueast kauemaks. Nimi, mis osutab endiselt eelmisele aadressile, näeb välja täpselt nagu maha kukkunud server.
Kirjutage üles, millist nime profiil kasutab ja milleks see piiri kummalgi poolel laheneb. Profiil, mis sõltub ruuteri funktsioonist, mida keegi ei kirjutanud üles, on tugikõne, mis ootab järgmist püsivara uuendust. Märge ütleb ka järgmisele inimesele, kas sisemine tõrge on tuntud hairpin-juhtum või midagi uut.