Le impostazioni lato appliance non possono far comportare un portatile non registrato come un endpoint gestito, e la maggior parte dei rollout Always-On si blocca proprio in questo divario. Cisco Secure Client applica i criteri tramite il profilo che risiede sulla macchina, quindi la distribuzione di quel profilo fa parte del piano di applicazione e non è un dettaglio. Segui i cinque passi qui sotto in ordine e fermati al primo che non regge, perché un passo successivo non può compensare una lacuna precedente.

Passo uno: decidi se la regola inizia prima dell'accesso

Always-On stabilisce il tunnel dopo che l'utente ha effettuato l'accesso, e la documentazione del fornitore dice chiaramente che non stabilisce una connessione quando nessuno effettua l'accesso. Se il requisito è un tunnel che esiste prima della schermata di accesso di Windows, questa è la funzionalità sbagliata e nessuna messa a punto del profilo lo cambia. Distribuire in anticipo il profilo non trasforma il comportamento dopo l'accesso in comportamento prima dell'accesso.

Scrivi il requisito come uno di quattro comportamenti distinti, poi verifica ciascuno separatamente. Una singola connessione riuscita dimostra solo il caso ordinario, e gli altri tre sono la fonte dei ticket di supporto. Segna quale riga serve davvero al tuo requisito, perché un team che necessita solo del comportamento dopo l'accesso può saltare l'argomento del prima. La tabella è un elenco di accettazione, non un elenco di desideri.

BehaviourWhat you are proving
First use on a new machineThe profile arrived before any user connection
After logonThe tunnel starts without the user opening the client
Trusted network entryThe client stays off where it should
Tunnel cannot establishThe failure policy does what you decided

Se il requisito è solo la seconda riga, il resto di questa pagina vale ancora, ma il test di accettazione è più economico.

Passo due: conferma che il profilo è già sull'endpoint

L'applicazione legge un profilo locale, quindi la prima domanda è se quel file esiste prima che l'utente si connetta. Un profilo scaricato durante la prima connessione riuscita arriva troppo tardi per una macchina che deve essere protetta dal primo accesso. Distribuiscilo con l'installer o con la gestione degli endpoint, e tratta la presenza del file come un controllo di build anziché come una speranza.

Get-Service vpnagent | Select-Object Status, StartType
Get-ChildItem 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile'
Get-Content 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile\profile.xml' | Select-String -Pattern AlwaysOn

Le installazioni più vecchie di AnyConnect conservano lo stesso file in una cartella con un nome diverso, quindi verifica il percorso per la versione client che distribuisci invece di copiare un percorso da un vecchio runbook. Il servizio deve essere in esecuzione e impostato per l'avvio automatico, perché un agente fermo è un endpoint senza applicazione, qualunque cosa dica il profilo.

Se il profilo manca, fermati qui. Correggere la politica di errore o l'elenco delle reti affidabili per una macchina senza profilo è lavoro su un percorso che non viene mai eseguito.

Passo tre: scegli deliberatamente il comportamento in caso di errore

Ciò che accade quando il tunnel non riesce a salire è una decisione separata dal fatto che il tunnel parta automaticamente. La politica di errore di connessione decide se l'endpoint può usare internet mentre l'instaurazione continua a fallire, e le due impostazioni vengono spesso confuse perché entrambe si trovano vicino alle opzioni Always-On. Scegline una di proposito e annota il motivo.

Bloccare tutta la connettività sembra rigoroso e crea una propria classe di incidenti: un utente su una rete in cui il gateway non è raggiungibile non può scaricare la correzione che ripristinerebbe il servizio. Consentire l'accesso a internet mantiene la macchina utilizzabile e indebolisce la garanzia che il traffico sia protetto. Entrambe le risposte possono essere corrette, ma nessuna è un valore predefinito che dovresti scoprire durante un'interruzione.

Il comportamento di nuovo tentativo appartiene alla stessa decisione. Un client che riprova all'infinito nasconde un gateway guasto al monitoraggio, mentre un client che rinuncia dopo un tentativo sembra guasto all'utente. Decidi per quanto tempo l'endpoint deve continuare a provare prima che la politica di errore subentri, e verifica quel tempo invece di presumerlo.

Passo quattro: definisci cosa conta come affidabile

Il rilevamento della rete affidabile usa i criteri nel profilo client, come domini DNS configurati o server DNS affidabili, per decidere che l'endpoint è già su una rete in cui il tunnel non è necessario. Quell'elenco è l'intera politica, quindi un elenco vuoto o ereditato rende la funzionalità inerte o imprevedibile.

Non sostituirlo con un'ipotesi sulla categoria di rete del firewall di Windows. Una macchina può trovarsi su una rete contrassegnata come dominio e trovarsi comunque in un luogo di cui non ti fidi, e una macchina con profilo pubblico può essere dentro il tuo edificio. I criteri di rilevamento dovrebbero descrivere direttamente le tue reti, non un loro sostituto.

Verifica la transizione in entrambe le direzioni, incluso il caso in cui l'endpoint passa da una rete affidabile a una non affidabile con una sessione aperta. La disconnessione e la riconnessione sono eventi separati, e una politica che gestisce solo il primo lascia una finestra in cui il tunnel è assente.

Passo cinque: rendi difficile annullare la politica dell'endpoint

L'applicazione sull'endpoint è forte quanto i controlli propri dell'endpoint. I diritti di amministratore locale consentono a un utente di fermare il servizio dell'agente, sostituire il profilo o disinstallare il client, e una directory di profilo in cui gli utenti normali possono scrivere è una politica che chiunque può modificare. Entrambi sono problemi di gestione degli endpoint che l'headend VPN non può risolvere per te. Chiedi al team desktop quale delle due condizioni si applica prima di promettere l'applicazione, e scrivi la risposta nel piano di distribuzione.

Decidi il livello di blocco tenendo presente il percorso di ripristino. Un profilo che impedisce all'utente di raggiungere internet e gli impedisce anche di riparare il client trasforma una chiamata al supporto in una visita in sede, quindi mantieni un percorso di ripristino documentato che non dipenda dal fatto che il tunnel sia attivo.

Mantieni attiva la convalida del certificato del gateway e distribuisci il profilo solo attraverso un canale di cui ti fidi. Un client bloccato che accetta un profilo da una fonte inaspettata ha spostato il confine di fiducia invece di applicarlo.

Articoli correlati