WireGuard funguje na mobilních datech, ale ne ve stejné wifi síti

Tunel se zvedne na mobilních datech a pak doma zůstane na připojování, se stejným profilem, stejným peer klíčem a bez změny konfigurace mezi tím. Rozdíl je v cestě: požadavek zevnitř LAN na veřejnou adresu routeru není stejná cesta jako požadavek přicházející z internetu. Většina domácích bran buď zpětnou cestu vůbec neimplementuje, nebo ji implementuje jen pro určité protokoly. Proto symptom vypadá jako rozbitý klíč, i když se na klíči nic nezměnilo. Určete, která cesta selhala, dřív než sáhnete na klíč, přesměrování portu nebo profil klienta.

Jedna adresa, dvě různé cesty

Zvenku paket dorazí na veřejnou adresu routeru a pravidlo přesměrování portu ho předá posluchači WireGuardu na interním hostiteli. Zevnitř klient volá stejnou veřejnou adresu, takže paket opustí klienta, dorazí k routeru a musí se obrátit zpět směrem k LAN. Právě na tom obrácení se obě cesty rozcházejí, protože router musí přeložit tok, který zároveň vychází a znovu vstupuje přes stejné rozhraní. Mnoho implementací ho zahodí místo přeložení a klient pak čeká na podání ruky, které nebylo nikdy odesláno.

Tomuto chování se obvykle říká NAT loopback nebo hairpinning a patří routeru, ne WireGuardu; RFC 4787 popisuje případy překladu, ve kterých to brána může nebo nemusí podporovat. Samotný WireGuard na cestě nemá názor, protože vidí jen pakety, které dorazí na jeho rozhraní. Když router tok zahodí, démon nikdy nic nedostane, klient hlásí vypršení času podání ruky a protokol serveru zůstane prázdný. Prázdný protokol je proto stopa, kde se paket zastavil, ne důkaz, že server spadl. To je také důvod, proč přeinstalace nic nemění.

Opak platí také: protokol serveru, který ukazuje pokus o podání ruky z adresy LAN, dokazuje, že paket dorazil a cesta je v pořádku, což přesouvá vyšetřování ke klíčům a povoleným adresám. Čtěte protokol pro to, co dokazuje, ne pro to, co jste doufali vidět.

Nejdřív to zreprodukujte, potom měňte

Vyzkoušejte to z autorizované vnější sítě se stejným zařízením a stejným profilem, pak test zopakujte uvnitř LAN, aniž byste cokoli upravovali. Dokončené podání ruky venku a klient, který uvnitř zařízení nikdy neopustí, stav reprodukují místo hádání. Oba pokusy musí používat stejný profil, jinak srovnání nic nedokazuje.

Pak se podívejte, na co se jméno koncového bodu pro toto zařízení překládá. Následující tři příkazy také ukazují, kterou adresu klient skutečně volal:

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

První příkaz hlásí koncový bod, který rozhraní právě používá, a další dva ukazují, na co se jméno na tomto stroji překládá. Klient, který volá veřejnou adresu, zatímco sedí ve stejné síti jako server, používá cestu hairpin. Klient, který volá adresu LAN, to nedělá, a selhání tam patří jinému vyšetřování. Tento rozdíl rozhoduje, zda se následující část vůbec vztahuje.

Podporované způsoby, jak dosáhnout blízkého serveru

Nejčistší uspořádání je odpověď s rozděleným horizontem: veřejné jméno se překládá na veřejnou adresu pro internet a na adresu LAN serveru pro klienty uvnitř. Profil drží jedno jméno koncového bodu a resolver volí cestu. To vyžaduje kontrolu nad interní odpovědí DNS, kterou domácí router obvykle nabízí a organizace ji může záměrně zařídit. Bez této kontroly zůstává funkce routeru nebo druhý profil.

Funkcí routeru je odraz: brána přeloží tok zevnitř ven a pošle ho zpět dovnitř. Kde funguje, nevyžaduje změnu klienta, a kde nefunguje, žádné nastavení klienta ji nezachrání. Otestujte ji sledováním protokolu serveru během vnitřního pokusu, místo čtení seznamu funkcí routeru.

Úprava profilu na soukromou adresu je diagnostika, ne návrh. Dokazuje, že server odpovídá v LAN, a rozbije tentýž profil ve chvíli, kdy notebook opustí dům.

Udržte profil použitelný mimo domov

Ať zvolíte kteroukoli cestu, nechte ověřování identity na pokoji. Adresa koncového bodu není identita peer a změna adresy nikdy neospravedlňuje přijetí cizího veřejného klíče, který náhodou odpovídá. WireGuard ověřuje klíčem, takže špatný hostitel selže na podání ruky, místo aby dal přístup k něčemu neočekávanému.

Pokud se veřejná adresa pohne, dynamický DNS je to, co drží jméno užitečné, a chování obnovy u klienta rozhoduje, jak rychle změna dorazí. Otestujte to zvenku po změně adresy, protože případ LAN to nemůže potvrdit. Dávejte pozor na resolver, který kešuje starou odpověď déle než životnost záznamu. Jméno, které stále ukazuje na předchozí adresu, vypadá přesně jako server, který spadl.

Zapište, které jméno profil používá a na co se překládá na každé straně hranice. Profil, který závisí na funkci routeru, kterou nikdo nezaznamenal, je volání podpory čekající na další aktualizaci firmwaru. Poznámka také říká dalšímu člověku, zda je vnitřní selhání známý případ hairpin, nebo něco nového.