Handshake ja, internet nee: wat je op Windows 11 eerst moet repareren

Op Windows 11 staan verse handshakes vaak naast browsers die niets openen. De handshake bewijst alleen dat de UDP-uitwisseling met de peer is voltooid. Hij zegt niets over de route die Windows installeerde, de resolver die het gebruikt, of over of de uitgang überhaupt iets doorstuurt.

Vier voorwaarden bepalen welke van die lagen faalde. Ze in volgorde doorlopen kost minuten, terwijl sleutels herschrijven langer duurt en niets verandert.

Bepaal de laag voordat je de sleutels aanraakt

Loop drie bestemmingen langs, in deze volgorde. Begin met een adres aan de tunnelkant, dan een openbaar IP als getal, en eindig met een hostnaam. Waar de reeks breekt, daar wordt de laag benoemd. Een fout in de eerste stap is routing, in de tweede is het doorsturen of NAT, en in de derde is het naamresolutie.

Die volgorde is de hele methode. Hij voorkomt dat een DNS-storing als een kapotte tunnel wordt gediagnosticeerd, wat hier de meest voorkomende verkeerde afslag is.

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

Als de handshake-tijd leeg is

Wanneer de handshake-tijd leeg is, is de versleutelde uitwisseling nooit voltooid. De storing zit dus eerder dan routing. Kijk eerst naar het endpointadres en de poort, daarna of het netwerk UDP filtert. Een provider die WireGuard-verkeer laat vallen veroorzaakt precies dit, en een client die een endpoint uit een oud profiel kopieerde ook.

Bytes die vertrekken zonder dat er iets binnenkomt zijn een ander geval. Dat wijst op NAT of een firewall die verkeer naar de verkeerde plek terugstuurt.

Als de route verliest van de fysieke adapter

Voor een volledige tunnel moet het peer-gedeelte de bestemmingen dekken die je verwacht te gebruiken. Windows houdt soms de standaardroute van de fysieke adapter, zelfs met een allesomvattende regel ingesteld. De allesomvattende regel splitsen in 0.0.0.0/1 plus 128.0.0.0/1 maakt twee specifiekere prefixen die de opzoeking winnen. De splitsing is een gedocumenteerde omweg, geen voorkeur.

Bevestig met route print of een opzoeking van een openbaar adres. De gekozen interface zou de tunneladapter moeten zijn. Als de fysieke nog steeds wint, herstel dan de peer-bereiken voordat je de server aanraakt.

Als adressen werken en namen falen

WireGuard draagt IP-pakketten en heeft geen mening over DNS. Zet een regel DNS = in het interfacegedeelte, of stel de adapter in via Windows. Zonder die regel slaagt een ping op adres terwijl elke hostnaam faalt, en gebruikers melden dat als geen internet.

Controleer welke servers Windows na het verbinden echt gebruikt. Een achtergebleven resolver op de fysieke adapter verklaart een gedeeltelijke fout, waarbij sommige namen wel en andere niet oplossen. Ruim hem op in plaats van een tweede erbovenop te zetten.

Als de Windows-machine de uitgang is

Internet Connection Sharing herschrijft de adressering wanneer het aan staat, waardoor de gedeelde adapter naar een ander bereik kan verschuiven. Een client die nog naar het oorspronkelijke adres wijst, werkt dan niet meer. De registerwaarden ScopeAddress en StandaloneDHCPAddress beheren dat bereik, en de instelling kan na een herstart terugvallen.

Twee andere Windows-specifieke conflicten zijn een blik waard. De service Routing and Remote Access kan de tunnel storen. Een installatieprogramma voor de verkeerde architectuur faalt met een bericht dat architectuur nooit noemt.

Herstel de laag die de test noemde, en voer daarna dezelfde drie bestemmingen opnieuw uit. Een wijziging die de hostnaamtest repareert maar het tunneladres breekt, is op de verkeerde laag toegepast.