Handshake si, internet non: que arranxar primeiro en Windows 11

A miúdo, en Windows 11, os handshakes recentes conviven con navegadores que non abren nada. O handshake só demostra que o intercambio UDP co par se completou. Non di nada sobre a ruta que instalou Windows, o resolutor que usa, nin sobre se a saída reenvía algo.

Catro condicións deciden cal desas capas fallou. Percorrelas en orde leva minutos, mentres que reescribir as claves leva máis tempo e non cambia nada.

Decida a capa antes de tocar as claves

Percorra tres destinos nesta orde. Empece por un enderezo do lado do túnel, siga cunha IP pública por número e remate cun nome de host. Onde se rompe a secuencia, alí se nomea a capa. Un fallo no primeiro paso é encamiñamento, no segundo é reenvío ou NAT e no terceiro é resolución de nomes.

Esa orde é todo o método. Evita que un fallo de DNS se diagnostique como un túnel roto, que é o desvío incorrecto máis habitual aquí.

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

Se o tempo de handshake está baleiro

Cando o tempo de handshake está baleiro, o intercambio cifrado nunca se completou. Polo tanto, o fallo está antes que o encamiñamento. Mire primeiro o enderezo do extremo e o porto, e despois se a rede filtra UDP. Un provedor de aloxamento que descarta o tráfico de WireGuard produce exactamente isto, e tamén un cliente que copiou un extremo dun perfil antigo.

Os bytes que saen sen que entre ningún son outro caso. Iso apunta a NAT ou a un cortalumes que devolve o tráfico ao lugar equivocado.

Se a ruta perde contra o adaptador físico

Para un túnel completo, a sección do par debe cubrir os destinos que espera usar. Windows ás veces conserva a ruta predeterminada do adaptador físico mesmo cunha regra xeral configurada. Dividir a regra xeral en 0.0.0.0/1 máis 128.0.0.0/1 crea dous prefixos máis específicos que gañan a busca. A división é un rodeo documentado, non unha preferencia.

Confírmeo con route print ou cunha consulta dun enderezo público. A interface escollida debería ser o adaptador do túnel. Se o físico segue gañando, corrixa os rangos do par antes de tocar o servidor.

Se os enderezos funcionan e os nomes fallan

WireGuard transporta paquetes IP e non ten opinión sobre DNS. Poña unha liña DNS = na sección de interface ou configure o adaptador desde Windows. Sen ela, un ping por enderezo funciona mentres todos os nomes de host fallan, e os usuarios relaciónano con que non hai internet.

Comprobe que servidores usa realmente Windows tras conectarse. Un resolutor sobrante no adaptador físico explica un fallo parcial, no que algúns nomes se resolven e outros non. Límpao en lugar de engadir un segundo por riba.

Se a máquina Windows é a saída

Internet Connection Sharing reescribe o enderezamento cando se activa, o que pode mover o adaptador compartido a outro rango. Un cliente que aínda apunta ao enderezo orixinal deixa entón de funcionar. Os valores do rexistro ScopeAddress e StandaloneDHCPAddress controlan ese rango, e o axuste pode reverter tras un reinicio.

Paga a pena mirar outros dous conflitos propios de Windows. O servizo Routing and Remote Access pode interferir co túnel. Un instalador creado para a arquitectura equivocada falla cunha mensaxe que nunca menciona a arquitectura.

Arranxe a capa que sinalou a proba e despois repita os mesmos tres destinos. Un cambio que arranxa a proba do nome de host pero rompe o enderezo do túnel aplicouse á capa equivocada.