Handshake ja, internet nej: hvad du skal rette først på Windows 11

Friske handshakes står ofte ved siden af browsere, der ikke åbner noget, på Windows 11. Handshaket beviser kun, at UDP-udvekslingen med peer’en blev gennemført. Det siger intet om den rute, Windows lagde ind, den resolver den bruger, eller om udgangen overhovedet videresender noget.

Fire forhold afgør, hvilket af de lag fejlede. At gennemgå dem i rækkefølge tager minutter, mens omskrivning af nøgler tager længere tid og ændrer intet.

Afgør laget, før du rører nøglerne

Gå gennem tre destinationer i denne rækkefølge. Start med en adresse på tunnelsiden, derefter en offentlig IP som tal, og slut med et værtsnavn. Hvor kæden knækker, navngiver laget. En fejl i første trin er routing, i andet er det videresendelse eller NAT, og i tredje er det navneopslag.

Den rækkefølge er hele metoden. Den forhindrer, at en DNS-fejl bliver diagnosticeret som en brudt tunnel, hvilket er det mest almindelige forkerte spor her.

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

Hvis handshake-tiden er tom

Når handshake-tiden er tom, blev den krypterede udveksling aldrig gennemført. Fejlen ligger derfor tidligere end routing. Se først på endpoint-adressen og porten, derefter på om netværket filtrerer UDP. En udbyder, der dropper WireGuard-trafik, giver præcis dette, og det samme gør en klient, der har kopieret et endpoint fra en gammel profil.

Bytes der forlader uden at nogen kommer ind, er et andet tilfælde. Det peger på NAT eller en firewall, der sender trafik tilbage til det forkerte sted.

Hvis ruten taber til den fysiske adapter

For en fuld tunnel skal peer-afsnittet dække de destinationer, du forventer at bruge. Windows beholder nogle gange den fysiske adapters standardrute, selv når en altomfattende regel er sat. Deler man den altomfattende regel i 0.0.0.0/1 plus 128.0.0.0/1, opstår to mere specifikke præfikser, som vinder opslaget. Opdelingen er en dokumenteret omvej, ikke en præference.

Bekræft med route print eller et opslag på en offentlig adresse. Den valgte grænseflade bør være tunneladapteren. Hvis den fysiske stadig vinder, ret peer-intervallerne, før du rører serveren.

Hvis adresser virker og navne fejler

WireGuard bærer IP-pakker og har ingen mening om DNS. Sæt linjen DNS = i grænsefladeafsnittet, eller sæt adapteren via Windows. Uden den lykkes et ping på en adresse, mens hvert værtsnavn fejler, og brugere rapporterer det som ingen internet.

Tjek hvilke servere Windows faktisk bruger efter forbindelsen. En resterende resolver på den fysiske adapter forklarer en delvis fejl, hvor nogle navne slår op og andre ikke. Ryd den op i stedet for at tilføje en anden ovenpå.

Hvis Windows-maskinen er udgangen

Internet Connection Sharing omskriver adresseringen, når det er slået til, hvilket kan flytte den delte adapter til et andet interval. En klient, der stadig peger på den oprindelige adresse, holder så op med at virke. Registerværdierne ScopeAddress og StandaloneDHCPAddress styrer det interval, og indstillingen kan rulle tilbage efter en genstart.

To andre Windows-specifikke konflikter er værd at se på. Tjenesten Routing and Remote Access kan forstyrre tunnelen. En installationspakke bygget til den forkerte arkitektur fejler med en besked, der aldrig nævner arkitektur.

Ret det lag, testen pegede på, og kør derefter de samme tre destinationer igen. En ændring, der reparerer værtsnavnetesten men ødelægger tunneladressen, blev anvendt på det forkerte lag.