¿Sin internet en una VPN de Windows? El conjunto de direcciones es el sospechoso

Windows muestra el túnel como conectado y lo etiqueta como Sin acceso a internet, lo que la gente lee como una manía de Windows. Es una afirmación sobre lo que recibió el cliente: ninguna puerta de enlace predeterminada utilizable, ningún resolutor que funcione o ningún camino de vuelta para las direcciones dentro del túnel. Cuando el servidor es una conexión entrante de Windows, un solo ajuste explica la mayoría de estos informes. La etiqueta no es un diagnóstico, pero reduce la búsqueda a tres lugares.

Lee el arrendamiento antes de cambiarlo

Ejecuta ipconfig /all en el cliente y encuentra el adaptador VPN entre las entradas. La dirección, la puerta de enlace predeterminada y el servidor DNS que enumera son los datos que necesitas, y a menudo difieren de lo que el administrador supone que se entregó.

Tres patrones corresponden a tres fallos. Una dirección en 169.254.0.0/16 significa que el cliente no recibió nada y se asignó una dirección local de enlace. Una dirección plausible sin puerta de enlace significa que el conjunto se sirvió sin la opción que da al cliente una ruta predeterminada. Un arrendamiento completo que aún no llega a nada apunta a reenvío o traducción en el lado del servidor.

Anota los valores antes de tocar el servidor. El siguiente paso los compara con el rango que el servidor cree que reparte, y la memoria es un mal sustituto de un arrendamiento.

Por qué la asignación automática puede dejar sin puerta de enlace

La entrada Conexiones entrantes tiene sus propias propiedades IPv4, separadas del adaptador físico. El valor predeterminado de allí ofrece asignar direcciones automáticamente, lo que depende del asignador integrado de la conexión para proporcionar una dirección, una máscara, una puerta de enlace y DNS.

En una estación de trabajo aislada ese asignador no tiene ámbito del que extraer, salvo que otra cosa en la máquina aporte uno, así que el cliente puede acabar con una dirección local de enlace o con una dirección pero sin puerta de enlace. La conexión parece establecida porque el enlace se levantó, mientras que la configuración detrás es incompleta.

Por eso cambiar a un rango especificado arregla tantos de estos informes. Dejas de pedirle a un servicio que quizá no se ejecute que invente un arrendamiento y empiezas a declarar tú mismo el arrendamiento.

La misma confusión aparece cuando alguien espera que el servidor DHCP del router LAN atienda a los clientes del túnel. El descubrimiento por difusión no cruza un túnel enrutado, así que ese servidor nunca ve la petición. Suponer lo contrario es la razón más común por la que se culpa a un conjunto de un cliente que nunca le preguntó nada.

Define un rango explícito que el servidor pueda enrutar

Elige un bloque pequeño dentro de una subred que el servidor pueda alcanzar, fuera del rango que reparte el router LAN y fuera de cualquier otro conjunto de la red. Si el servidor está en 172.20.10.0/24 y el router tiene 172.20.10.1, un bloque corto cerca de la parte alta de esa subred, digamos de 172.20.10.201 a 172.20.10.209, mantiene los arrendamientos del túnel lejos del reparto que el router ya gestiona.

Introdúcelo en las propiedades IPv4 de la conexión entrante, vuelve a conectar el cliente y lee el adaptador otra vez antes de cambiar cualquier otra cosa. La segunda lectura es la que te dice si el conjunto era el fallo o solo un fallo entre varios.

Estos comandos imprimen la configuración resultante y las rutas que el cliente tiene ahora:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

La puerta de enlace del arrendamiento debería ser una dirección que tenga el servidor, y la ruta predeterminada del cliente debería apuntar a ella. Si el arrendamiento es completo pero no existe ninguna ruta, el servidor asignó sin empujar una puerta de enlace, y los ajustes del conjunto siguen siendo el lugar donde mirar.

Una dirección no es un camino a internet

Recibir un arrendamiento solo mueve paquetes del cliente al servidor. Para acceder a internet el servidor debe reenviar esos paquetes y traducirlos hacia su propio enlace ascendente, y eso es una configuración aparte con sus propios modos de fallo.

El uso compartido de conexión a internet es el atajo. Convierte el adaptador orientado a internet en una puerta de enlace compartida y ejecuta su propio direccionamiento, que puede reescribir la dirección de ese adaptador y dejar una regla NAT existente apuntando a un valor que ya no existe. Anota la configuración original antes de activarlo.

La alternativa enrutada mantiene el direccionamiento estable y te pide configurar el reenvío y la traducción de forma explícita. Ninguno de los dos enfoques es incorrecto; mezclarlos a medias produce un túnel con arrendamiento y sin salida, que es exactamente el síntoma con el que empezaste. Elige un modelo y termínalo antes de añadir el otro.

Descarta primero el camino exterior

Ningún conjunto puede ayudar si el túnel no se forma nunca. El protocolo decide qué debe llevar el camino: PPTP quiere TCP 1723 y GRE, que es el protocolo IP 47 y no un puerto; L2TP/IPsec quiere UDP 1701 más 500 y 4500; SSTP quiere TCP 443.

Un router que reenvía el puerto pero no el protocolo produce un intento de conexión que nunca se autentica. Eso es un fallo distinto de un túnel que se forma y luego no llega a nada, y los dos no deben depurarse juntos.

Prueba desde la misma LAN y desde la red remota. Si el intento desde la LAN funciona y el remoto nunca llega a la autenticación, el problema es el camino exterior. Si ambos se autentican y solo el cliente remoto no tiene internet, vuelve al conjunto y a la salida.