Si fa clic su Connetti e la finestra risponde quasi subito: impossibile inizializzare il sottosistema di connessione. Nulla ha raggiunto il gateway, quindi non c'è scambio di certificati, nessuna credenziale e nessuna selezione del gruppo tunnel dall'altra parte. Ciò significa che i log del concentratore mostreranno una sessione vuota e l'assistenza chiederà uno screenshot di una finestra che non ha mai contenuto nulla di utile. Lavorate invece sull'endpoint, in un ordine fisso, e fermatevi al primo passo che cambia l'esito.

La tempistica è la prova più preziosa che avete, e registrarla non costa nulla. Annotate se l'errore è apparso prima o dopo la richiesta delle credenziali e se è iniziato dopo un aggiornamento, un aggiornamento di Windows o un nuovo agente di sicurezza. Quelle tre risposte di solito dimezzano l'elenco dei candidati prima che tocchiate un'impostazione.

Leggete la tempistica prima di cambiare qualcosa

Tre punti di guasto sembrano uguali e non lo sono. Se la finestra compare nel momento in cui premete Connetti, il client non è riuscito ad avviare la propria infrastruttura, ed è questo che indica il messaggio. Se compare dopo aver digitato le credenziali, il gruppo tunnel è stato raggiunto e il problema è più avanti. Se il tunnel sale e poi cade, il sottosistema si è inizializzato bene e state inseguendo un bug completamente diverso. Confondere i tre fa perdere un pomeriggio in reinstallazioni che non possono aiutare.

Qui rientra solo il primo caso. Il messaggio viene generato prima di qualsiasi decisione di rete, quindi un indirizzo del gateway errato, un certificato scaduto o una password sbagliata non lo produrranno.

Passo 1: verificare che il servizio dell'agente sia in esecuzione

La finestra su cui fate clic è solo la parte anteriore; il lavoro avviene nel servizio Cisco AnyConnect Secure Mobility Agent, registrato come vpnagent. Se quel servizio è arrestato o disabilitato, l'interfaccia grafica non ha con chi parlare e segnala esattamente questo guasto di inizializzazione. Controllate stato e tipo di avvio da un prompt di PowerShell con privilegi elevati:

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

Un programma di installazione che ha rispettato un tipo di avvio impostato manualmente in precedenza è la ragione abituale per cui finisce disabilitato, quindi controllate StartType invece di premere solo Start. Se il servizio si avvia e si arresta in pochi secondi, leggete il registro System per le voci del Service Control Manager prima di fare clic su Ripara:

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

Un driver bloccato, un file messo in quarantena o un driver di filtro di un prodotto di sicurezza di terze parti si nominerà in quegli eventi. Ripara reinstalla sopra lo stesso file bloccato e non cambia nulla, per questo il registro eventi viene prima.

Passo 2: cancellare lo stato offline riportato dallo stack HTTP

Il client scarica il proprio profilo e valuta i criteri tramite i componenti HTTP di Windows, quindi un flag offline impostato nelle impostazioni Internet dell'utente può rompere l'inizializzazione mentre ogni browser continua a caricare pagine. Controllate il valore direttamente:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

Un valore di 1 significa che lo stack WinINet comunica ai chiamanti che il computer non ha connessione; questo stato è normalmente impostato dalla voce di menu Lavora offline di Internet Explorer o da uno script di automazione. Riportatelo a 0, disconnettetevi e riconnettetevi, e riprovate la connessione prima di cambiare qualsiasi altra cosa.

Se avete ereditato questo computer e non sapete dire perché il flag è stato impostato, annotatelo nel ticket. Qualcos'altro sulla macchina potrebbe averlo impostato di proposito e tornerà al prossimo accesso.

Passo 3: liberare l'adattatore virtuale da Hyper-V o ICS

Due ruoli di Windows possono trattenere i pezzi che servono al client per creare il proprio adattatore. Hyper-V è il primo: con i servizi dello switch virtuale in esecuzione, la creazione dell'adattatore può fallire in modi che si manifestano come questo errore. Arrestare i servizi è una diagnosi, non una correzione:

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

Se il client si connette con quei servizi arrestati, il conflitto è confermato e ora sapete cosa negoziare con il proprietario dell'host Hyper-V. Riavviate quei servizi dopo, a meno che la macchina non abbia più bisogno della virtualizzazione.

La condivisione di connessione Internet è il secondo proprietario. Se una connessione è condivisa, il client può fallire prima ancora di creare un tunnel. Verificatelo con Get-Service SharedAccess e, se è in esecuzione e impostata su automatico, esaminate gli adattatori cercando una connessione condivisa e disattivate la condivisione solo su quell'adattatore.

C'è anche una spiegazione meno costosa da escludere per prima. Una macchina senza alcun accesso a Internet funzionante mostra spesso questo messaggio invece di un errore di raggiungibilità, quindi verificate che Test-NetConnection verso l'indirizzo del gateway e verso un host pubblico riesca entrambi prima di dare la colpa al client.

Verificate, poi annullate ciò che non serviva

La verifica non è lo scudo verde nella barra delle applicazioni. Verificate che l'adattatore esista, abbia un indirizzo e faccia passare il traffico: Get-NetAdapter -Name "Cisco AnyConnect*" dovrebbe mostrarlo attivo, ipconfig /all dovrebbe mostrare l'indirizzo assegnato e i server DNS, e una richiesta reale a un nome interno dovrebbe risolversi attraverso il tunnel e non tramite il resolver locale.

Tenete un breve elenco di ogni modifica, con il valore trovato e il valore impostato. Se la connessione funziona dopo il terzo passo, ripristinate i servizi di Hyper-V e riprovate prima di chiudere il ticket, perché un espediente che disattiva in silenzio la virtualizzazione verrà annullato dal prossimo amministratore che se ne accorgerà.

Se nessuno dei tre passi sposta l'errore, smettete di modificare l'endpoint. Raccogliete la versione del client, lo stato del servizio, la tempistica indicata all'inizio di questa pagina e il pacchetto diagnostico che il client può produrre, poi consegnateli con l'ordine esatto che avete provato. Quel pacchetto vale più per il tecnico successivo di uno screenshot della finestra, ed è l'unico artefatto che mostra se il sottosistema ha fallito prima o dopo aver toccato la rete.

Articoli correlati