Handshake sí, internet no: què cal arreglar primer a Windows 11

Els handshakes recents sovint conviuen amb navegadors que no obren res a Windows 11. El handshake només demostra que l’intercanvi UDP amb el parell s’ha completat. No diu res sobre la ruta que ha instal·lat Windows, el resolutor que fa servir, ni sobre si la sortida arriba a reenviar alguna cosa.

Quatre condicions decideixen quina d’aquestes capes ha fallat. Recórrer-les en ordre es fa en minuts, mentre que reescriure les claus triga més i no canvia res.

Decidiu la capa abans de tocar les claus

Recorreu tres destinacions, en aquest ordre. Comenceu per una adreça del costat del túnel, després una IP pública pel número i acabeu amb un nom d’amfitrió. On la seqüència es trenca, s’hi identifica la capa. Una fallada al primer pas és encaminament, al segon és reenviament o NAT, i al tercer és resolució de noms.

Aquest ordre és tot el mètode. Evita que una fallada de DNS es diagnostiqui com un túnel trencat, que és el gir equivocat més habitual aquí.

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

Si el temps de handshake és buit

Quan el temps de handshake és buit, l’intercanvi xifrat no s’ha completat mai. Per tant, la fallada és anterior a l’encaminament. Mireu primer l’adreça del punt final i el port, després si la xarxa filtra UDP. Un proveïdor d’allotjament que descarta el trànsit de WireGuard produeix exactament això, i també un client que ha copiat un punt final d’un perfil antic.

Els bytes que surten sense que n’entri cap són un altre cas. Això apunta a NAT o a un tallafoc que retorna el trànsit al lloc equivocat.

Si la ruta perd contra l’adaptador físic

Per a un túnel complet, la secció del parell ha de cobrir les destinacions que espereu fer servir. Windows de vegades conserva la ruta per defecte de l’adaptador físic fins i tot amb una regla general configurada. Dividir la regla general en 0.0.0.0/1 més 128.0.0.0/1 crea dos prefixos més específics que guanyen la consulta. La divisió és una solució documentada, no una preferència.

Confirmeu-ho amb route print o amb una consulta d’una adreça pública. La interfície escollida ha de ser l’adaptador del túnel. Si el físic encara guanya, arregleu els rangs del parell abans de tocar el servidor.

Si les adreces funcionen i els noms fallen

WireGuard transporta paquets IP i no té opinió sobre DNS. Poseu una línia DNS = a la secció d’interfície o configureu l’adaptador des de Windows. Sense això, un ping per adreça funciona mentre tots els noms d’amfitrió fallen, i els usuaris ho reporten com que no hi ha internet.

Comproveu quins servidors fa servir realment Windows després de connectar. Un resolutor romanent a l’adaptador físic explica una fallada parcial, en què alguns noms es resolen i d’altres no. Netegeu-lo en lloc d’afegir-ne un segon a sobre.

Si la màquina Windows és la sortida

Internet Connection Sharing reescriu l’adreçament quan s’activa, cosa que pot moure l’adaptador compartit a un altre rang. Un client que encara apunta a l’adreça original llavors deixa de funcionar. Els valors del registre ScopeAddress i StandaloneDHCPAddress controlen aquest rang, i el paràmetre pot revertir després d’un reinici.

Val la pena mirar dos altres conflictes propis de Windows. El servei Routing and Remote Access pot interferir amb el túnel. Un instal·lador creat per a l’arquitectura equivocada falla amb un missatge que mai no menciona l’arquitectura.

Arregleu la capa que ha assenyalat la prova i repetiu les mateixes tres destinacions. Un canvi que arregla la prova del nom d’amfitrió però trenca l’adreça del túnel s’ha aplicat a la capa equivocada.