Always On VPN non é acceso á LAN: lista de comprobación de recursos

Always On é un ciclo de vida de conexión: o perfil conéctase ao iniciar sesión ou antes, e reconéctase sen que o usuario prema nada. Iso non significa que estean permitidos todos os destinos privados, protocolos e usuarios. A pregunta práctica é que recursos entrega realmente o perfil despregado, e esa resposta esixe unha comprobación por recurso, non unha ollada á insignia Conectado.

Paso 1: Anote o recurso antes de probalo

Empece cunha ficha breve por aplicación, tomada do entorno real: nome, prefixo de destino, servizo e porto, papel do túnel, grupo de identidade e ruta do 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

A ficha obriga a catro preguntas separadas. A ruta decide cara a onde vai o enderezo; a política DNS decide como aprende o cliente o enderezo; o filtro de tráfico decide se ese tráfico pode usar a conexión; o cortafuegos e os permisos da aplicación de destino deciden se se acepta a petición. Ningunha das catro se deduce dun túnel conectado.

Paso 2: Determine que túnel debe transportalo

Windows Always On VPN ten un túnel de dispositivo e un túnel de usuario, configurados como perfís separados con certificados e ámbitos separados. O túnel de dispositivo adoita transportar só a infraestrutura previa ao inicio de sesión, como xestión e servizos de dominio; o acceso amplo dos empregados ás aplicacións corresponde ao túnel de usuario.

Os filtros de tráfico son unha función do túnel de dispositivo, por iso o exemplo de Microsoft os usa para tráfico de xestión. Copiar ese exemplo nun perfil xeral de recursos dá un túnel que conecta pero transporta o conxunto incorrecto. Confirme a conexión activa con Get-VpnConnection e probe baixo esa conexión.

Paso 3: Verifique a ruta para o enderezo real

Resolva o nome unha vez e comprobe a ruta: Find-NetRoute -RemoteIPAddress 10.20.5.10 informa da interface escollida, o seguinte salto e o enderezo de orixe. Se a interface é o adaptador físico, o prefixo falta no conxunto de rutas do túnel ou o cliente excluíuno cun túnel dividido. Compare coa definición do perfil en lugar de engadir unha ruta local.

Unha route add local pode facer pasar a proba e desaparecer na seguinte actualización de política, por iso o cambio vai no perfil xestionado. Revise o prefixo nos perfís de usuario e de dispositivo, e o axuste de túnel dividido: o túnel completo non necesita ruta por prefixo, o dividido necesita unha por cada prefixo privado.

Paso 4: Probe a resolución de nomes privados por separado

Os nomes privados son unha ruta de política propia. O perfil pode entregar regras NRPT e unha lista de busca de sufixos DNS, válidas mentres o túnel está activo. Lea con Get-DnsClientNrptPolicy que recibiu realmente o cliente e probe un nome e un enderezo na mesma sesión. Se fallan os nomes e os enderezos funcionan, é o resolutor; se fallan ambos, é a ruta.

Un nome tamén pode resolverse a un enderezo fóra das rutas do túnel, o que mestura éxito e tempo de espera. Compare o enderezo devolto co prefixo da súa ficha; se difiren, a zona privada responde cun enderezo público ou alternativo e a ruta que coincide non é a deseñada.

Paso 5: Revise filtros, identidade e a porta da propia aplicación

Os filtros de tráfico limitan que protocolos e portos poden usar o túnel de dispositivo, e un conxunto estreito pode bloquear un recurso que a ruta transportaría. O perfil asigna a conexión a un grupo, pero o recurso ten a súa propia autorización: un usuario que pode conectar non é aceptado automaticamente polo servidor de ficheiros.

Cambie o perfil xestionado a través do seu propietario, sexa Intune, un despregamento ProfileXML ou un script de operacións, e volva probar tras unha reconexión normal e tras un reinicio: o fallo habitual é unha ruta local obsoleta ou un perfil aplicado unha soa vez. Garde a versión do perfil xunto ao resultado da proba.