WireGuard deluje na mobilnih podatkih, ne pa na istem wifi omrežju
Zahteva iz notranjosti LAN-a na javni naslov usmerjevalnika gre po drugi poti kot zahteva prek mobilnih podatkov. Preizkusite od zunaj in nato izberite lokalno pot.
Predor se dvigne na mobilnih podatkih in nato ostane na povezovanju doma, z isto profilno nastavitvijo, istim ključem peer in brez spremembe konfiguracije vmes. Razlika je na poti: zahteva iz notranjosti LAN-a na javni naslov usmerjevalnika ni isto potovanje kot zahteva, ki prihaja iz interneta. Večina domačih prehodov bodisi sploh ne izvaja povratne poti bodisi jo izvaja le za določene protokole. Zaradi tega je simptom videti kot pokvarjen ključ, čeprav se na ključu ni nič spremenilo. Ugotovite, katera pot je odpovedala, preden se dotaknete ključa, posredovanja vrat ali profila odjemalca.
En naslov, dve različni poti
Od zunaj paket doseže javni naslov usmerjevalnika in pravilo za posredovanje vrat ga preda poslušalcu WireGuard na notranjem gostitelju. Od znotraj odjemalec pokliče isti javni naslov, zato paket zapusti odjemalca, prispe do usmerjevalnika in ga je treba obrniti nazaj proti LAN-u. Prav pri tem obračanju se poti razideta, ker mora usmerjevalnik prevesti tok, ki hkrati zapusti in znova vstopi skozi isti vmesnik. Mnoge izvedbe ga zavržejo, namesto da bi ga prevedle, in odjemalec nato čaka rokovanje, ki ni bilo nikoli poslano.
Tako vedenje se običajno imenuje NAT loopback ali hairpinning in pripada usmerjevalniku, ne WireGuardu; RFC 4787 opisuje primere prevajanja, pri katerih prehod to lahko podpira ali ne. WireGuard sam nima mnenja o poti, ker vidi le pakete, ki dosežejo njegov vmesnik. Ko usmerjevalnik tok zavrže, demon nikoli ničesar ne prejme, odjemalec sporoči potek rokovanja, dnevnik strežnika pa ostane prazen. Prazen dnevnik je zato namig, kje se je paket ustavil, ne dokaz, da je strežnik padel. To je tudi razlog, zakaj ponovna namestitev ničesar ne spremeni.
Tudi obratno je pomembno: dnevnik strežnika, ki kaže poskus rokovanja z naslova LAN-a, dokazuje, da je paket prispel in da je pot v redu, kar preusmeri preiskavo na ključe in dovoljene naslove. Berite dnevnik zaradi tega, kar dokazuje, ne zaradi tega, kar ste upali videti.
Najprej poustvarite, šele nato spreminjajte
Preizkusite iz pooblaščenega zunanjega omrežja z isto napravo in istim profilom, nato preizkus ponovite znotraj LAN-a, ne da bi karkoli urejali. Dokončano rokovanje zunaj in odjemalec, ki znotraj nikoli ne zapusti naprave, stanje poustvarita, namesto da bi ga ugibala. Oba poskusa morata uporabljati isti profil, sicer primerjava ničesar ne dokaže.
Nato poglejte, v kaj se razreši ime končne točke za to napravo. Naslednji trije ukazi pokažejo tudi, kateri naslov je odjemalec v resnici poklical:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netPrvi ukaz sporoči končno točko, ki jo vmesnik trenutno uporablja, druga dva pa pokažeta, v kaj se ime razreši na tem stroju. Odjemalec, ki kliče javni naslov, medtem ko je v istem omrežju kot strežnik, uporablja pot hairpin. Odjemalec, ki kliče naslov LAN-a, tega ne počne, in okvara tam pripada drugi preiskavi. Ta razlika odloči, ali naslednji razdelek sploh velja.
Podprti načini doseganja bližnjega strežnika
Najnatančnejša ureditev je odgovor z razdeljenim obzorjem: javno ime se razreši na javni naslov za internet in na naslov LAN-a strežnika za odjemalce znotraj. Profil obdrži eno ime končne točke, razreševalnik pa izbere pot. To zahteva nadzor nad notranjim odgovorom DNS, ki ga domači usmerjevalnik običajno ponuja, organizacija pa ga lahko namerno uredi. Brez tega nadzora ostaneta funkcija usmerjevalnika ali drugi profil.
Funkcija usmerjevalnika je odsev: prehod prevede tok od znotraj navzven in ga pošlje nazaj noter. Kjer deluje, ne potrebuje nobene spremembe odjemalca, kjer pa ne deluje, je nobena nastavitev odjemalca ne reši. Preizkusite jo tako, da med notranjim poskusom opazujete dnevnik strežnika, namesto da berete seznam funkcij usmerjevalnika.
Urejanje profila na zasebni naslov je diagnostika, ne načrt. Dokaže, da strežnik odgovarja v LAN-u, in pokvari isti profil v trenutku, ko prenosnik zapusti hišo.
| 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 |
Ohranite profil uporaben zunaj doma
Katero koli pot izberete, pustite preverjanje identitete pri miru. Naslov končne točke ni identiteta peer, sprememba naslova pa nikoli ne opraviči sprejema tujega javnega ključa, ki slučajno odgovori. WireGuard preverja s ključem, zato napačni gostitelj pade pri rokovanju, namesto da bi dal dostop do nečesa nepričakovanega.
Če se javni naslov premakne, je dinamični DNS tisti, ki ohrani ime uporabno, vedenje osveževanja odjemalca pa odloči, kako hitro sprememba prispe. Preizkusite to od zunaj po spremembi naslova, ker primer LAN-a tega ne more potrditi. Pazite na razreševalnik, ki predpomni stari odgovor dlje od življenjske dobe zapisa. Ime, ki še vedno kaže na prejšnji naslov, je videti natanko kot strežnik, ki je padel.
Zapišite, katero ime uporablja profil in v kaj se razreši na vsaki strani meje. Profil, ki je odvisen od funkcije usmerjevalnika, ki je nihče ni zabeležil, je klic podpori, ki čaka na naslednjo posodobitev vdelane programske opreme. Zapis tudi pove naslednji osebi, ali je notranja okvara znani primer hairpin ali kaj novega.