Always On VPN no es acceso a la LAN: lista de comprobación de recursos

Always On es un ciclo de vida de conexión: el perfil se conecta al iniciar sesión o antes, y se reconecta sin que el usuario pulse nada. Eso no significa que estén permitidos todos los destinos privados, protocolos y usuarios. La pregunta práctica es qué recursos entrega realmente el perfil desplegado, y esa respuesta exige una comprobación por recurso, no un vistazo a la insignia Conectado.

Paso 1: Anote el recurso antes de probarlo

Empiece con una ficha breve por aplicación, tomada del entorno real: nombre, prefijo de destino, servicio y puerto, rol del túnel, grupo de identidad y ruta del resolutor.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

La ficha obliga a cuatro preguntas separadas. La ruta decide adónde va la dirección; la política DNS decide cómo aprende el cliente la dirección; el filtro de tráfico decide si ese tráfico puede usar la conexión; el cortafuegos y los permisos de la aplicación de destino deciden si se acepta la petición. Ninguna de las cuatro se deduce de un túnel conectado.

Paso 2: Determine qué túnel debe transportarlo

Windows Always On VPN tiene un túnel de dispositivo y un túnel de usuario, configurados como perfiles separados con certificados y ámbitos separados. El túnel de dispositivo suele transportar solo la infraestructura previa al inicio de sesión, como administración y servicios de dominio; el acceso amplio de los empleados a las aplicaciones corresponde al túnel de usuario.

Los filtros de tráfico son una función del túnel de dispositivo, por eso el ejemplo de Microsoft los usa para tráfico de administración. Copiar ese ejemplo en un perfil general de recursos da un túnel que conecta pero transporta el conjunto equivocado. Confirme la conexión activa con Get-VpnConnection y pruebe bajo esa conexión.

Paso 3: Verifique la ruta para la dirección real

Resuelva el nombre una vez y compruebe la ruta: Find-NetRoute -RemoteIPAddress 10.20.5.10 informa de la interfaz elegida, el siguiente salto y la dirección de origen. Si la interfaz es el adaptador físico, el prefijo falta en el conjunto de rutas del túnel o el cliente lo excluyó con túnel dividido. Compare con la definición del perfil en lugar de añadir una ruta local.

Una route add local puede hacer pasar la prueba y desaparecer en la siguiente actualización de política, por eso el cambio va en el perfil administrado. Revise el prefijo en los perfiles de usuario y de dispositivo, y el ajuste de túnel dividido: el túnel completo no necesita ruta por prefijo, el dividido necesita una por cada prefijo privado.

Paso 4: Pruebe la resolución de nombres privados por separado

Los nombres privados son una ruta de política propia. El perfil puede entregar reglas NRPT y una lista de búsqueda de sufijos DNS, válidas mientras el túnel está activo. Lea con Get-DnsClientNrptPolicy qué recibió realmente el cliente y pruebe un nombre y una dirección en la misma sesión. Si fallan los nombres y las direcciones funcionan, es el resolutor; si fallan ambos, es la ruta.

Un nombre también puede resolverse a una dirección fuera de las rutas del túnel, lo que mezcla éxito y tiempo de espera. Compare la dirección devuelta con el prefijo de su ficha; si difieren, la zona privada responde con una dirección pública o alternativa y la ruta que coincide no es la diseñada.

Paso 5: Revise filtros, identidad y la puerta de la propia aplicación

Los filtros de tráfico limitan qué protocolos y puertos pueden usar el túnel de dispositivo, y un conjunto estrecho puede bloquear un recurso que la ruta transportaría. El perfil asigna la conexión a un grupo, pero el recurso tiene su propia autorización: un usuario que puede conectar no es aceptado automáticamente por el servidor de archivos.

Cambie el perfil administrado a través de su propietario, sea Intune, un despliegue ProfileXML o un script de operaciones, y vuelva a probar tras una reconexión normal y tras un reinicio: el fallo habitual es una ruta local obsoleta o un perfil aplicado una sola vez. Guarde la versión del perfil junto al resultado de la prueba.