Always On VPN no és accés a la LAN: una llista de comprovació de recursos

Always On és un cicle de vida de connexió: el perfil es connecta en o abans de l’inici de sessió i es reconnecta sense que l’usuari premi res. No significa que tota destinació privada, protocol i usuari estiguin permesos. La pregunta pràctica és quins recursos lliura el perfil desplegat, i cal comprovar-ho recurs per recurs, no mirar la insígnia Connectat.

Pas 1: Anoteu el recurs abans de provar-lo

Comenceu amb una fitxa breu per aplicació, treta de l’entorn real: nom, prefix de destinació, servei i port, rol del túnel, grup d’identitat i camí 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 fitxa força quatre preguntes. La ruta decideix on va l’adreça; la política DNS decideix com el client la coneix; el filtre de trànsit decideix si aquest trànsit pot usar la connexió; el tallafoc i els permisos de l’aplicació de destinació decideixen si la petició s’accepta. Cap de les quatre no ve d’un túnel connectat.

Pas 2: Determineu quin túnel l’ha de portar

Windows Always On VPN té un túnel de dispositiu i un túnel d’usuari, configurats com a perfils separats amb certificats i àmbits separats. El túnel de dispositiu només porta la infraestructura prèvia a l’inici de sessió, com ara gestió i serveis de domini; l’accés ampli dels empleats a les aplicacions pertany al túnel d’usuari.

Els filtres de trànsit són una funció del túnel de dispositiu, per això l’exemple de Microsoft els usa per al trànsit de gestió. Copiar aquest exemple en un perfil general de recursos dóna un túnel que connecta però porta el conjunt equivocat. Confirmeu la connexió activa amb Get-VpnConnection i proveu sota aquesta connexió.

Pas 3: Verifiqueu la ruta per a l’adreça real

Resoleu el nom un cop i comproveu la ruta: Find-NetRoute -RemoteIPAddress 10.20.5.10 informa de la interfície triada, el següent salt i l’adreça d’origen. Si la interfície és l’adaptador físic, el prefix no és al conjunt de rutes del túnel o el client l’ha exclòs amb túnel dividit. Compareu amb la definició del perfil en lloc d’afegir una ruta local.

Una route add local pot fer passar la prova i desaparèixer en la propera actualització de política, per això el canvi va al perfil gestionat. Reviseu el prefix als perfils d’usuari i de dispositiu i el paràmetre de túnel dividit: el túnel complet no necessita ruta per prefix, el dividit en necessita una per cada prefix privat.

Pas 4: Proveu la resolució de noms privats a part

Els noms privats són un camí de política propi. El perfil pot lliurar regles NRPT i una llista de cerca de sufixos DNS, vàlides mentre el túnel és actiu. Llegiu amb Get-DnsClientNrptPolicy què ha rebut el client i proveu un nom i una adreça a la mateixa sessió. Si fallen els noms i les adreces funcionen, és el resolutor; si fallen tots dos, és la ruta.

Un nom també pot resoldre’s a una adreça fora de les rutes del túnel, cosa que barreja èxit i temps d’espera. Compareu l’adreça retornada amb el prefix de la fitxa; si difereixen, la zona privada respon amb una adreça pública o alternativa i la ruta que coincideix no és la dissenyada.

Pas 5: Reviseu filtres, identitat i la porta de l’aplicació

Els filtres de trànsit limiten quins protocols i ports poden usar el túnel de dispositiu, i un conjunt estret pot bloquejar un recurs que la ruta portaria. El perfil assigna la connexió a un grup, però el recurs té la seva autorització: un usuari que pot connectar no és acceptat automàticament pel servidor de fitxers.

Canvieu el perfil gestionat a través del seu propietari, sigui Intune, un desplegament ProfileXML o un script d’operacions, i torneu a provar després d’una reconnexió normal i d’un reinici: la fallada habitual és una ruta local obsoleta o un perfil aplicat una sola vegada. Guardeu la versió del perfil al costat del resultat.