Handshake ja, internet nee: wat om eerste op Windows 11 reg te maak

Onlangse handshakes staan op Windows 11 dikwels langs blaaiers wat niks oopmaak nie. Die handshake bewys net dat die UDP-uitruiling met die eweknie voltooi is. Dit sê niks oor die roete wat Windows ingestel het, die resolver wat dit gebruik, of of die uitgang enigiets aanstuur.

Vier toestande bepaal watter van daardie lae gefaal het. Om hulle in volgorde te werk neem minute, terwyl die herskryf van sleutels langer neem en niks verander nie.

Bepaal eers die laag voordat jy aan die sleutels raak

Werk deur drie bestemmings, in hierdie volgorde. Begin met ’n adres aan die tonnelkant, dan ’n publieke IP volgens nommer, en eindig met ’n gasheernaam. Waar die reeks breek, noem die laag. ’n Fout by die eerste stap is roetering, by die tweede is dit aanstuur of NAT, en by die derde is dit naamresolusie.

Daardie volgorde is die hele metode. Dit verhoed dat ’n DNS-fout as ’n stukkende tonnel gediagnoseer word, die algemeenste verkeerde draai hier.

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

As die handshaketyd leeg is

Wanneer die handshaketyd leeg is, het die geënkripteerde uitruiling nooit voltooi nie. Die fout lê dus vroeër as roetering. Kyk eerste na die eindpuntadres en poort, dan na of die netwerk UDP filtreer. ’n Gasheer wat WireGuard-verkeer laat val, lewer presies dit, en so ook ’n kliënt wat ’n eindpunt uit ’n ou profiel gekopieer het.

Grepe wat uitgaan sonder dat enige inkom, is ’n ander geval. Dit dui op NAT of ’n firewall wat verkeer na die verkeerde plek terugstuur.

As die roete teen die fisiese adapter verloor

Vir ’n vol tonnel moet die eweknie-afdeling die bestemmings dek wat jy verwag om te gebruik. Windows hou soms die fisiese adapter se verstekroete selfs met ’n allesomvattende reël ingestel. Om die allesomvattende reël in 0.0.0.0/1 plus 128.0.0.0/1 te split, skep twee meer spesifieke prefikse wat die opsoek wen. Die splitsing is ’n gedokumenteerde ompad, nie ’n voorkeur nie.

Bevestig met route print of ’n opsoek vir ’n publieke adres. Die gekose koppelvlak moet die tonneladapter wees. As die fisiese een steeds wen, maak die eweknie-reekse reg voordat jy aan die bediener raak.

As adresse werk en name faal

WireGuard dra IP-pakkette en het geen mening oor DNS nie. Sit ’n reël DNS = in die koppelvlak-afdeling, of stel die adapter deur Windows. Sonder een slaag ’n ping per adres terwyl elke gasheernaam faal, en gebruikers rapporteer dit as geen internet.

Kyk watter bedieners Windows ná die verbinding werklik gebruik. ’n Oorblywende resolver op die fisiese adapter verduidelik ’n gedeeltelike fout, waar sommige name oplos en ander nie. Maak dit skoon eerder as om ’n tweede een bo-op te sit.

As die Windows-masjien die uitgang is

Internet Connection Sharing herskryf adressering wanneer dit geaktiveer is, wat die gedeelde adapter na ’n ander reeks kan skuif. ’n Kliënt wat steeds na die oorspronklike adres wys, werk dan nie meer nie. Die registerwaardes ScopeAddress en StandaloneDHCPAddress beheer daardie reeks, en die instelling kan ná ’n herbegin terugval.

Twee ander Windows-spesifieke konflikte is ’n kyk werd. Die diens Routing and Remote Access kan die tonnel inmeng. ’n Installeerder wat vir die verkeerde argitektuur gebou is, faal met ’n boodskap wat nooit argitektuur noem nie.

Maak die laag reg wat die toets genoem het, en herhaal dan dieselfde drie bestemmings. ’n Verandering wat die gasheernaam-toets regmaak maar die tonneladres breek, is op die verkeerde laag toegepas.