Handskakning ja, internet nej: vad du ska rätta först i Windows 11

I Windows 11 står färska handskakningar ofta bredvid webbläsare som inte öppnar något. Handskakningen bevisar bara att UDP-utbytet med peeren slutfördes. Den säger ingenting om rutten Windows lade in, resolvern den använder, eller om utgången alls vidarebefordrar något.

Fyra villkor avgör vilket av dessa lager som misslyckades. Att gå igenom dem i ordning tar minuter, medan att skriva om nycklarna tar längre tid och inte ändrar något.

Avgör lagret innan du rör nycklarna

Gå igenom tre destinationer, i den här ordningen. Börja med en adress på tunnelsidan, sedan en offentlig IP som tal, och avsluta med ett värdnamn. Där kedjan bryts namnges lagret. Ett fel i första steget är routing, i det andra är det vidarebefordran eller NAT, och i det tredje är det namnutslagning.

Den ordningen är hela metoden. Den hindrar att ett DNS-fel diagnostiseras som en trasig tunnel, vilket är det vanligaste felspåret här.

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

Om handskakningstiden är tom

När handskakningstiden är tom slutfördes det krypterade utbytet aldrig. Felet ligger alltså före routingen. Titta först på slutpunktsadressen och porten, sedan på om nätverket filtrerar UDP. En leverantör som slänger WireGuard-trafik ger exakt detta, och detsamma gäller en klient som kopierat en slutpunkt från en gammal profil.

Byte som går ut utan att någon kommer in är ett annat fall. Det pekar på NAT eller en brandvägg som skickar tillbaka trafiken till fel plats.

Om rutten förlorar mot det fysiska nätverkskortet

För en full tunnel måste peer-avsnittet täcka de destinationer du förväntar dig att använda. Windows behåller ibland det fysiska nätverkskortets standardrutt även med en heltäckande regel satt. Att dela den heltäckande regeln i 0.0.0.0/1 plus 128.0.0.0/1 skapar två mer specifika prefix som vinner sökningen. Delningen är en dokumenterad omväg, inte en preferens.

Bekräfta med route print eller en sökning på en offentlig adress. Det valda gränssnittet bör vara tunnelkortet. Om det fysiska fortfarande vinner, rätta peer-intervallen innan du rör servern.

Om adresser fungerar och namn misslyckas

WireGuard bär IP-paket och har ingen åsikt om DNS. Sätt en rad DNS = i gränssnittsavsnittet, eller ställ in kortet via Windows. Utan den lyckas en ping på adress medan varje värdnamn misslyckas, och användare rapporterar det som inget internet.

Kontrollera vilka servrar Windows faktiskt använder efter anslutning. En kvarvarande resolver på det fysiska kortet förklarar ett delvis fel, där vissa namn löses upp och andra inte. Rensa den i stället för att lägga en andra ovanpå.

Om Windows-maskinen är utgången

Internet Connection Sharing skriver om adresseringen när det är påslaget, vilket kan flytta det delade kortet till ett annat intervall. En klient som fortfarande pekar på den ursprungliga adressen slutar då att fungera. Registervärdena ScopeAddress och StandaloneDHCPAddress styr det intervallet, och inställningen kan återgå efter en omstart.

Två andra Windows-specifika konflikter är värda en titt. Tjänsten Routing and Remote Access kan störa tunneln. Ett installationsprogram byggt för fel arkitektur misslyckas med ett meddelande som aldrig nämner arkitektur.

Rätta lagret som testet pekade på, och kör sedan samma tre destinationer igen. En ändring som reparerar värdnamnstestet men bryter tunneladressen tillämpades på fel lager.