¿Compartes una conexión de Windows? La ruta de la VPN cambia debajo

Un portátil comparte su Wi-Fi, el host navega por el túnel sin quejarse y la tableta de ese uso compartido no llega a nada. El host dejó de ser solo un cliente en el momento en que se activó el uso compartido: ahora es un enrutador, y los paquetes reenviados se topan con un conjunto de reglas distinto. Lo que funciona en el host no dice nada del dispositivo que hay detrás. Ejecuta las comprobaciones desde el cliente descendente y la distinción deja de ser teórica.

El éxito del host no demuestra nada

El uso compartido de conexión asigna cuatro tareas a una máquina: asignación de direcciones, reenvío, traducción y filtrado. Un cliente de VPN que protege el tráfico generado localmente puede considerar el tráfico reenviado fuera de su ámbito, o bloquearlo a propósito como fuga. Ninguno de los dos comportamientos es un error, y ninguno está escrito en la pantalla donde se activó el uso compartido. Solo la prueba descendente te dice cuál tienes.

Muchos clientes reenvían solo el tráfico del host y nada más, así que revisa la sección de uso compartido en la documentación del cliente en lugar de confiar en que el túnel enrutará por la tableta. El síntoma visible es un dispositivo que se asocia, recibe una dirección y luego falla en la primera solicitud. Un cliente que se niega a reenviar sigue pareciendo perfectamente sano en el host.

Qué adaptador se comparte y cuál sirve a los clientes

Anota ambos adaptadores, porque llevan direcciones distintas y filtros distintos, y un cambio en el equivocado explica muchos resultados confusos. El host del uso compartido suele tomar una dirección fija en el lado descendente y ejecuta allí un pequeño servicio DHCP y DNS. Windows mantiene el reenvío por adaptador y no de forma global, así que el estado debe leerse interfaz por interfaz.

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

Si el reenvío aparece como Deshabilitado en el adaptador compartido, nada descendente funcionará haga lo que haga el túnel. Actívalo solo en una máquina cuya política le permita enrutar para otros dispositivos.

Reenvío, traducción y filtrado

Un paquete reenviado tiene que llegar al túnel, traducirse a algo que acepte el lado remoto y volver por la misma traducción. Cualquiera de esas tres etapas puede romperse, y cada rotura produce el mismo tiempo de espera del navegador. Una captura de paquetes, una consulta de rutas y un registro del lado remoto valen más que otra revisión del diálogo de uso compartido. Qué etapa falla es lo que te dice de quién es el cambio necesario.

El lado remoto también puede necesitar una ruta de retorno para la subred compartida, un rango que el servidor VPN nunca ha visto. Donde el cliente traduce, el servidor solo ve la dirección del túnel y no hace falta ruta de retorno. Donde no traduce, quien posee la puerta de enlace tiene que añadir esa ruta a propósito, y eso es una solicitud de cambio, no un ajuste del cliente.

Haz las comprobaciones en el cliente, no en el host

Haz cada comprobación en el cliente que falla, no en el host que funciona. Mantén la dirección de salida, la respuesta del resolutor y la prueba de la aplicación en la misma sesión, porque los resultados recogidos con una hora de diferencia no dicen nada sobre cómo se combinan las tres.

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

Compara la dirección de salida con la del propio host y anota si coinciden. Una respuesta distinta significa que la ruta reenviada evita el túnel, lo que es una cuestión de política con un responsable y no una solución rápida. Una respuesta coincidente junto a una aplicación que falla traslada el trabajo a la resolución de nombres o a la política del lado remoto. Tampoco te detengas en el resultado de IPv4: un uso compartido puede pasar todas las comprobaciones de IPv4 mientras IPv6 sale por otra salida, así que repite las comprobaciones de nombres y de salida con el registro AAAA y la prueba de conexión detallada.

En una máquina gestionada, confirma que el uso compartido está permitido, porque exponer el acceso a otro dispositivo es una decisión administrativa y no un interruptor de comodidad. Después de cualquier cambio admitido, repite las comprobaciones al reconectar y de nuevo durante una interrupción. Que el host se reconecte limpiamente no restaura una ruta reenviada que el cliente nunca admitió.