Čerstvé handshaky často stojí vedle prohlížečů, které na Windows 11 nic neotevřou. Handshake dokazuje jen to, že výměna UDP s protějškem proběhla. Nic neříká o trase, kterou Windows nainstaloval, o resolveru, který používá, ani o tom, zda výstup vůbec něco předává.

Čtyři podmínky rozhodují, která z těch vrstev selhala. Projít je popořadě trvá minuty, zatímco přepisování klíčů trvá déle a nic nemění.

Určete vrstvu, než se dotknete klíčů

Projděte tři cíle v tomto pořadí. Začněte adresou na straně tunelu, pak veřejnou IP jako číslem a skončete názvem hostitele. Kde se řada přeruší, tam se vrstva pojmenuje. Selhání v prvním kroku je směrování, ve druhém předávání nebo NAT a ve třetím překlad jmen.

Toto pořadí je celá metoda. Brání tomu, aby se závada DNS diagnostikovala jako rozbitý tunel, což je tady nejčastější špatný krok.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Když je čas handshake prázdný

Když je čas handshake prázdný, šifrovaná výměna nikdy neskončila. Závada tedy leží dřív než směrování. Podívejte se nejdřív na adresu koncového bodu a port, pak na to, zda síť filtruje UDP. Poskytovatel hostingu, který zahazuje provoz WireGuard, dělá přesně tohle, a stejně tak klient, který zkopíroval koncový bod ze starého profilu.

Bajty, které odcházejí, a žádné nepřicházejí, jsou jiný případ. To ukazuje na NAT nebo firewall, který vrací provoz na špatné místo.

Když trasa prohrává s fyzickým adaptérem

U plného tunelu musí sekce protějšku pokrývat cíle, které hodláte používat. Windows někdy ponechá výchozí trasu fyzického adaptéru i s nastaveným pravidlem pro vše. Rozdělení pravidla pro vše na 0.0.0.0/1 plus 128.0.0.0/1 vytvoří dva konkrétnější prefixy, které vyhrají vyhledání. Rozdělení je dokumentovaná obezlička, ne preference.

Potvrďte to pomocí route print nebo dotazem na veřejnou adresu. Zvolené rozhraní má být tunelový adaptér. Pokud fyzický pořád vyhrává, opravte rozsahy protějšku, než se dotknete serveru.

Když adresy fungují a jména selhávají

WireGuard přenáší IP pakety a na DNS nemá názor. Vložte řádek DNS = do sekce rozhraní nebo nastavte adaptér přes Windows. Bez něj ping na adresu projde, zatímco každé jméno hostitele selže, a uživatelé to hlásí jako žádný internet.

Zkontrolujte, které servery Windows po připojení skutečně používá. Zbytkový resolver na fyzickém adaptéru vysvětluje částečné selhání, kdy se některá jména přeloží a jiná ne. Ukliďte ho, místo abyste přidali druhý navrch.

Když je stroj s Windows výstupem

Internet Connection Sharing při zapnutí přepisuje adresování, což může přesunout sdílený adaptér do jiného rozsahu. Klient, který stále míří na původní adresu, pak přestane fungovat. Hodnoty registru ScopeAddress a StandaloneDHCPAddress tento rozsah řídí a nastavení se po restartu může vrátit.

Za pohled stojí dva další konflikty specifické pro Windows. Služba Routing and Remote Access může tunelu překážet. Instalátor sestavený pro špatnou architekturu selže se zprávou, která architekturu nikdy nezmíní.

Opravte vrstvu, kterou test pojmenoval, a pak zopakujte stejné tři cíle. Změna, která opraví test jména hostitele, ale rozbije adresu tunelu, byla použita na špatnou vrstvu.

Související články