Handshake sí, internet no: qué arreglar primero en Windows 11

A menudo, en Windows 11, los handshakes recientes conviven con navegadores que no abren nada. El handshake solo demuestra que el intercambio UDP con el par se completó. No dice nada sobre la ruta que instaló Windows, el resolutor que usa, ni sobre si la salida reenvía algo.

Cuatro condiciones deciden cuál de esas capas falló. Recorrerlas en orden lleva minutos, mientras que reescribir las claves lleva más tiempo y no cambia nada.

Decida la capa antes de tocar las claves

Recorra tres destinos en este orden. Empiece por una dirección del lado del túnel, siga con una IP pública por número y termine con un nombre de host. Donde se rompe la secuencia, ahí se nombra la capa. Un fallo en el primer paso es enrutamiento, en el segundo es reenvío o NAT y en el tercero es resolución de nombres.

Ese orden es todo el método. Evita que un fallo de DNS se diagnostique como un túnel roto, que es el desvío equivocado más habitual aquí.

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

Si el tiempo de handshake está vacío

Cuando el tiempo de handshake está vacío, el intercambio cifrado nunca se completó. Por tanto, el fallo está antes que el enrutamiento. Mire primero la dirección del extremo y el puerto, y después si la red filtra UDP. Un proveedor de alojamiento que descarta el tráfico de WireGuard produce exactamente esto, y también un cliente que copió un extremo de un perfil antiguo.

Los bytes que salen sin que entre ninguno son otro caso. Eso apunta a NAT o a un cortafuegos que devuelve el tráfico al lugar equivocado.

Si la ruta pierde contra el adaptador físico

Para un túnel completo, la sección del par debe cubrir los destinos que espera usar. Windows a veces conserva la ruta predeterminada del adaptador físico incluso con una regla general configurada. Dividir la regla general en 0.0.0.0/1 más 128.0.0.0/1 crea dos prefijos más específicos que ganan la búsqueda. La división es un rodeo documentado, no una preferencia.

Confírmelo con route print o con una consulta de una dirección pública. La interfaz elegida debería ser el adaptador del túnel. Si el físico sigue ganando, corrija los rangos del par antes de tocar el servidor.

Si las direcciones funcionan y los nombres fallan

WireGuard transporta paquetes IP y no tiene opinión sobre DNS. Ponga una línea DNS = en la sección de interfaz o configure el adaptador desde Windows. Sin ella, un ping por dirección funciona mientras todos los nombres de host fallan, y los usuarios lo reportan como que no hay internet.

Compruebe qué servidores usa realmente Windows tras conectarse. Un resolutor sobrante en el adaptador físico explica un fallo parcial, en el que algunos nombres se resuelven y otros no. Límpielo en lugar de añadir un segundo encima.

Si la máquina Windows es la salida

Internet Connection Sharing reescribe el direccionamiento cuando se activa, lo que puede mover el adaptador compartido a otro rango. Un cliente que todavía apunta a la dirección original deja entonces de funcionar. Los valores del registro ScopeAddress y StandaloneDHCPAddress controlan ese rango, y el ajuste puede revertirse tras un reinicio.

Merece la pena mirar otros dos conflictos propios de Windows. El servicio Routing and Remote Access puede interferir con el túnel. Un instalador creado para la arquitectura equivocada falla con un mensaje que nunca menciona la arquitectura.

Arregle la capa que señaló la prueba y luego repita los mismos tres destinos. Un cambio que repara la prueba del nombre de host pero rompe la dirección del túnel se aplicó a la capa equivocada.