Always On VPN non è accesso alla LAN: lista di controllo delle risorse

Always On è un ciclo di vita della connessione: il profilo si connette all’accesso o prima e si riconnette senza che l’utente prema nulla. Non significa che ogni destinazione privata, protocollo e utente sia consentito. La domanda pratica è quali risorse consegni davvero il profilo distribuito, e la risposta richiede un controllo per risorsa, non uno sguardo al badge Connected.

Passo 1: annotate la risorsa prima di provarla

Iniziate con una scheda breve per applicazione, presa dall’ambiente reale: nome, prefisso di destinazione, servizio e porta, ruolo del tunnel, gruppo di identità e percorso del resolver.

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 scheda impone quattro domande distinte. La rotta decide dove va l’indirizzo; la policy DNS decide come il client apprende l’indirizzo; il filtro di traffico decide se quel traffico può usare la connessione; il firewall e i permessi dell’applicazione di destinazione decidono se la richiesta viene accettata. Nessuna delle quattro deriva da un tunnel connesso.

Passo 2: stabilite quale tunnel deve trasportarla

Windows Always On VPN ha un tunnel di dispositivo e un tunnel utente, configurati come profili separati con certificati e ambiti separati. Il tunnel di dispositivo di solito trasporta solo l’infrastruttura necessaria prima dell’accesso, come gestione e servizi di dominio; l’accesso ampio dei dipendenti alle applicazioni spetta al tunnel utente.

I filtri di traffico sono una funzione del tunnel di dispositivo, per questo l’esempio Microsoft li usa per il traffico di gestione. Copiare quell’esempio in un profilo generico di risorse dà un tunnel che si connette ma trasporta l’insieme sbagliato. Confermate la connessione attiva con Get-VpnConnection e provate sotto quella connessione.

Passo 3: verificate la rotta per l’indirizzo reale

Risolvete il nome una volta, poi controllate la rotta: Find-NetRoute -RemoteIPAddress 10.20.5.10 riporta l’interfaccia scelta, il salto successivo e l’indirizzo sorgente. Se l’interfaccia è l’adattatore fisico, il prefisso manca nell’insieme di rotte del tunnel o il client lo ha escluso con il tunnel diviso. Confrontate con la definizione del profilo invece di aggiungere una rotta locale.

Un route add locale può far passare il test e sparire al successivo aggiornamento della policy, quindi la modifica va nel profilo gestito. Controllate il prefisso sia nel profilo utente sia in quello del dispositivo, e l’impostazione del tunnel diviso: il tunnel completo non richiede una rotta per prefisso, quello diviso ne richiede una per ogni prefisso privato.

Passo 4: provate la risoluzione dei nomi privati a parte

I nomi privati hanno un proprio percorso di policy. Il profilo può fornire regole NRPT e un elenco di ricerca dei suffissi DNS, validi finché il tunnel è attivo. Leggete con Get-DnsClientNrptPolicy cosa ha ricevuto davvero il client, poi provate un nome e un indirizzo nella stessa sessione. Se falliscono i nomi mentre gli indirizzi funzionano, è il resolver; se falliscono entrambi, è la rotta.

Un nome può anche risolversi in un indirizzo fuori dalle rotte del tunnel, cosa che mescola successo e timeout. Confrontate l’indirizzo restituito con il prefisso della scheda; se differiscono, la zona privata risponde con un indirizzo pubblico o alternativo e la rotta che combacia non è quella progettata.

Passo 5: controllate filtri, identità e il cancello dell’applicazione

I filtri di traffico limitano quali protocolli e porte possono usare il tunnel di dispositivo, e un insieme stretto può bloccare una risorsa che la rotta trasporterebbe. Il profilo assegna la connessione a un gruppo, ma la risorsa ha la propria autorizzazione: un utente che può connettersi non è accettato automaticamente dal file server.

Modificate il profilo gestito tramite il suo proprietario, che sia Intune, una distribuzione ProfileXML o uno script operativo, poi riprovate dopo una riconnessione normale e dopo un riavvio: il guasto abituale è una rotta locale obsoleta o un profilo applicato una sola volta. Tenete la versione del profilo accanto al risultato del test.