A WireGuard működik mobilneten, de ugyanazon a wifi-hálózaton nem

Az alagút mobilneten feljön, majd otthon kapcsolódás állapotban marad, ugyanazzal a profillal, ugyanazzal a peer-kulccsal és közben semmilyen konfigurációváltozással. A különbség az útvonalban van: a LAN belsejéből a router nyilvános címére menő kérés nem ugyanaz az utazás, mint az internetről érkező kérés. A legtöbb otthoni átjáró vagy egyáltalán nem valósítja meg a visszautat, vagy csak bizonyos protokollokra. Emiatt a tünet törött kulcsnak látszik, pedig a kulcsban semmi nem változott. Állapítsa meg, melyik útvonal hibázott, mielőtt kulcshoz, porttovábbításhoz vagy kliensprofilhoz nyúlna.

Egy cím, két különböző útvonal

Kívülről a csomag eléri a router nyilvános címét, és egy porttovábbítási szabály átadja a belső hoszton figyelő WireGuardnak. Belülről a kliens ugyanezt a nyilvános címet hívja, így a csomag elhagyja a klienst, eléri a routert, és vissza kell fordítani a LAN felé. Pont ebben a visszafordításban válik el a két útvonal, mert a routernek olyan folyamot kell lefordítania, amely egyszerre lép ki és lép be újra ugyanazon a csatolón. Sok megvalósítás eldobja a fordítás helyett, és a kliens ezután egy kézfogásra vár, amelyet soha nem küldtek el.

Ezt a viselkedést általában NAT loopbacknek vagy hairpinningnek nevezik, és a routerhez tartozik, nem a WireGuardhoz; az RFC 4787 azokat a fordítási eseteket írja le, amelyekben az átjáró támogathatja vagy nem. Maga a WireGuard nem nyilatkozik az útvonalról, mert csak a csatolójára érkező csomagokat látja. Amikor a router eldobja a folyamot, a démon soha nem kap semmit, a kliens kézfogási időtúllépést jelent, és a szervernapló üres marad. Az üres napló ezért arra utal, hol állt meg a csomag, nem bizonyítja, hogy a szerver leállt. Ez az oka annak is, hogy az újratelepítés semmin sem változtat.

A fordítottja is számít: az a szervernapló, amely a LAN-címről érkező kézfogási kísérletet mutatja, bizonyítja, hogy a csomag megérkezett és az útvonal rendben van, ami a vizsgálatot kulcsokra és engedélyezett címekre tereli. A naplót azért olvassa, amit bizonyít, és nem azért, amit remélt, hogy látni fog.

Előbb reprodukálja, csak utána változtasson

Teszteljen egy engedélyezett külső hálózatról ugyanazzal az eszközzel és ugyanazzal a profillal, majd ismételje meg a tesztet a LAN belsejében anélkül, hogy bármit szerkesztene. A kívül befejezett kézfogás és a belül az eszközt soha el nem hagyó kliens újra előállítja a helyzetet a találgatás helyett. Mindkét kísérletnek ugyanazt a profilt kell használnia, különben az összehasonlítás semmit nem bizonyít.

Ezután nézze meg, mire oldódik fel a végpont neve ennél az eszköznél. A következő három parancs azt is megmutatja, melyik címet hívta valójában a kliens:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

Az első parancs azt a végpontot jelenti, amelyet a csatoló éppen használ, a másik kettő pedig azt mutatja, mire oldódik fel a név ezen a gépen. Az a kliens, amely nyilvános címet hív, miközben ugyanabban a hálózatban van, mint a szerver, a hairpin útvonalat használja. Az a kliens, amely a LAN-címet hívja, nem ezt teszi, és az ottani hiba más vizsgálathoz tartozik. Ez a különbség dönti el, egyáltalán érvényes-e a következő szakasz.

Támogatott módok egy közeli szerver elérésére

A legtisztább elrendezés a megosztott horizontú válasz: a nyilvános név az internet számára a nyilvános címre, a belső kliensek számára a szerver LAN-címére oldódik fel. A profil egy végpontnevet tart, és a feloldó választja ki az útvonalat. Ehhez a belső DNS-válasz feletti ellenőrzés kell, amelyet egy otthoni router általában kínál, és egy szervezet szándékosan kialakíthat. E nélkül az ellenőrzés nélkül a routerfunkció vagy egy második profil marad.

A routerfunkció a tükrözés: az átjáró lefordítja a folyamot belülről kifelé, és visszaküldi befelé. Ahol működik, nem igényel kliensváltoztatást, ahol pedig nem működik, ott egyetlen kliensbeállítás sem menti meg. Tesztelje úgy, hogy belső kísérlet közben figyeli a szervernaplót, ahelyett hogy a router funkciólistáját olvasná.

A profil privát címre szerkesztése diagnózis, nem tervezés. Bizonyítja, hogy a szerver válaszol a LAN-ban, és ugyanazt a profilt töri el abban a pillanatban, amikor a laptop elhagyja a házat.

Tartsa a profilt otthonon kívül is használhatónak

Bármelyik útvonalat választja, hagyja békén az identitásellenőrzést. A végpont címe nem a peer identitása, és a címváltozás soha nem indokolja egy idegen nyilvános kulcs elfogadását, amely véletlenül válaszol. A WireGuard kulccsal hitelesít, ezért a rossz hoszt a kézfogáson bukik el, ahelyett hogy hozzáférést adna valami váratlanhoz.

Ha a nyilvános cím elmozdul, a dinamikus DNS az, ami használhatóvá teszi a nevet, és a kliens frissítési viselkedése dönti el, milyen gyorsan érkezik meg a változás. Tesztelje ezt kívülről a címváltozás után, mert a LAN-eset ezt nem tudja igazolni. Figyeljen az olyan feloldóra, amely a régi választ a rekord élettartamán túl is gyorsítótárazza. Az a név, amely még mindig az előző címre mutat, pontosan úgy néz ki, mint egy leállt szerver.

Jegyezze fel, melyik nevet használja a profil, és mire oldódik fel a határ mindkét oldalán. Az a profil, amely olyan routerfunkciótól függ, amelyet senki nem rögzített, olyan támogatási hívás, amely a következő firmware-frissítésre vár. A feljegyzés azt is megmondja a következő embernek, hogy a belső hiba az ismert hairpin-eset-e vagy valami új.