Il portatile si unisce al Wi-Fi dell’ufficio, e il profilo Always On che si connetteva da casa resta spento. Nulla nel registro eventi lo chiama guasto, perché dal punto di vista del client la rete è affidabile e il tunnel è inutile. Il rilevamento della rete affidabile è la funzione che prende questa decisione, e confronta valori precisi invece di riconoscere un SSID familiare. Quando la decisione è sbagliata, bisogna vedere quale confronto è passato.

Che cosa confronta realmente il trigger

Tre elementi devono coincidere prima che il client tratti una rete come affidabile. Primo, il suffisso DNS specifico della connessione che Windows registra per l’adattatore fisico deve comparire nell’elenco dei suffissi del profilo. Secondo, il profilo di connessione che Windows mantiene per quella rete deve essere quello atteso dalla politica, perché la corrispondenza avviene su quel profilo e non su un nome digitato dall’utente in una finestra wireless. Terzo, la rete deve essere classificata come richiede la politica, il che in pratica significa una rete di dominio o privata, oppure un dispositivo la cui politica è arrivata tramite gestione. Toglietene uno qualsiasi e il trigger scatta.

È un test più stretto del confronto con l’indirizzo di uscita pubblico della VPN, e molto più stretto che fidarsi di un SSID. Un punto di accesso che ripete il nome aziendale non soddisfa da solo i confronti di suffisso e profilo. Significa anche che la funzione non dice nulla sulla sicurezza di una rete; dice se questo dispositivo ritiene di essere già a casa.

Leggete lo stato attuale prima di modificare il profilo

Cominciate da ciò che Windows ritiene adesso. Il cmdlet del profilo di connessione riporta il nome della rete, l’interfaccia e la categoria assegnata da Windows, ossia il terzo confronto qui sopra. Poi leggete il profilo VPN e cercate l’elenco dei suffissi affidabili, usando un dump completo delle proprietà invece di indovinarne i nomi:

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

Se quel dump non espone il suffisso affidabile sulla vostra build, tornate all’XML del profilo, che è la copia autorevole quando la superficie delle proprietà differisce tra le versioni. Leggete l’XML dalla politica di gestione o dall’archivio dei profili di tutti gli utenti, e confrontate le sue voci di suffisso con il suffisso dell’adattatore riportato sopra. Annotate entrambi i valori prima di toccarne uno.

Provate il confine in entrambe le direzioni

Provate sull’attacco aziendale previsto e su un’altra rete approvata, e annotate se il tunnel si è alzato. Poi provate lo stesso dispositivo dopo l’uscita. Un portatile che si attiva a casa e si sopprime in ufficio si comporta come progettato, mentre uno che non si attiva mai da nessuna parte ha un altro difetto. Verificate che le risorse dietro il tunnel siano raggiungibili quando si attiva, perché un tunnel avviato non è prova di un percorso funzionante.

Non aggiungete un suffisso ampio solo per far sparire una notifica. Un suffisso presente su molte reti insegna al client a sopprimere il tunnel quasi ovunque, e il carico di supporto che ne segue è peggiore della notifica. Cambiate i criteri tramite il proprietario del profilo, che in una flotta gestita è l’amministratore MDM e non la persona davanti al portatile.

Tenete entrambe le reti di prova nel registro insieme al risultato. Un confine mai provato è solo un’affermazione.

Distinguete la soppressione dal blocco

Un tunnel non avviato non è una connessione bloccata. Il rilevamento della rete affidabile controlla l’attivazione automatica, mentre il filtraggio del traffico e il comportamento del kill-switch sono impostazioni di politica separate con i propri modi di guasto. Un dispositivo su una rete affidabile può inviare traffico fuori dal tunnel legittimamente, e chiamarlo fuga senza leggere la politica confonde due progetti. Controllate le regole di traffico del profilo prima di accusare il rilevamento di una fuga.

La stessa distinzione spiega la lamentela opposta. Gli utenti che segnalano che la VPN si è fermata a caso descrivono di solito un cambio di rete che soddisfaceva i criteri, non un guasto del servizio. Il suffisso corrispondente e la categoria di rete sono le prove da raccogliere, ed entrambe compaiono nell’output qui sopra.

Raccogliete queste prove prima di cambiare la politica. Un interruttore che nasconde il sintomo nasconde anche la causa.

Annotate su cosa si basava la decisione

Scrivete il suffisso corrispondente, il nome del profilo di connessione e la categoria di rete nelle note di distribuzione di ogni sede. Quando il tunnel non si alza, quella traccia trasforma un mistero in un confronto: o è cambiato uno dei tre valori, o è cambiata la politica. Dà anche al prossimo ingegnere un modo per confermare il progetto invece di disattivare il rilevamento per chiudere il ticket.

Rivedete l’elenco dei suffissi quando una sede viene rinominata o un dominio viene consolidato, perché una voce obsoleta continua a sopprimere il tunnel in silenzio. Il riferimento Microsoft sul rilevamento della rete affidabile elenca gli elementi del profilo e i prerequisiti di distribuzione, ed è il documento da citare quando qualcuno propone di ampliare l’elenco.

Articoli correlati