Cisco VPN si blocca dopo Hyper-V: scollegare o ricostruire?

Il client gira su securing communications e non mostra mai la richiesta di accesso, e l'unica cosa cambiata è stata l'installazione di un emulatore. Questo schema indica l'adattatore virtuale, non il profilo o la password. La decisione è se l'adattatore è associato a un commutatore Hyper-V su cui non dovrebbe stare, o se non è mai comparso.

I due stati sembrano uguali nel client e richiedono riparazioni diverse. Uno è un'associazione che potete annullare; l'altro è un problema di driver che la disassociazione non toccherà.

Cosa attende la fase securing communications

Prima che il tunnel sia costruito, il client ha bisogno di un percorso di rete locale funzionante verso il gateway. Installa il proprio adattatore virtuale e lo usa come parte di quel percorso. Se Hyper-V collega quell'adattatore a un commutatore creato per un emulatore, l'adattatore può smettere di offrire una rotta utilizzabile.

Il client non segnala quale adattatore stia aspettando. Il registro di solito finisce all'ultima fase raggiunta, e lo stesso errore compare per ogni indirizzo di gateway. Per questo la cronologia delle installazioni conta più del testo dell'errore. Il registro vale comunque la pena di conservarlo; dice la fase, non la causa.

Reinserire le credenziali o reinstallare il profilo non può cambiare un'associazione al commutatore. Se queste sono le vostre prime due mosse, state riparando lo strato sbagliato.

Decisione uno: l'adattatore VPN è associato al commutatore sbagliato?

Aprite Hyper-V Manager, poi Virtual Switch Manager, e leggete l'elenco degli adattatori di ogni commutatore. L'adattatore Cisco non dovrebbe comparire come collegamento di un commutatore di emulatore. Se compare, è colpa vostra, e la riparazione è rimuoverlo da quel commutatore.

Riavviate prima, così il client parte pulito e non mezzo collegato. Rimuovete l'associazione, applicatela, e lasciate stare gli altri adattatori finché non avete provato. La modifica è reversibile e non disinstalla nulla, ma annotate quali adattatori avete disassociato.

Avviate il client e provate la connessione. Se si blocca ancora, disassociate gli adattatori virtuali rimanenti uno alla volta e provate dopo ciascuno, per sapere quale contava.

Decisione due: l'adattatore è attivo ma senza indirizzo?

Eseguite ipconfig /all da un prompt elevato perché siano inclusi anche gli adattatori nascosti, e confrontate l'elenco con quello che ricordate prima dell'installazione. Un adattatore senza indirizzo e con stato di supporto disconnesso di solito significa che il driver non si è avviato. Questo non si ripara disassociando. Annotate lo stato esatto prima di cambiare qualsiasi cosa.

Un adattatore attivo ma collegato al commutatore sbagliato è il caso della sezione precedente. Lo stato dell'indirizzo è ciò che distingue i due.

Ripristinate l'emulatore senza ripristinare il guasto

Quando il tunnel funziona, ricollegate l'adattatore proprio dell'emulatore al suo commutatore e confermate che la VM ottenga un indirizzo. Non ricollegate l'adattatore VPN. Provate ancora sia l'emulatore sia il client prima di considerarlo finito.

Su una postazione gestita, dite all'amministratore quale associazione avete modificato. Un successivo aggiornamento dei criteri può ripristinare il vecchio collegamento, e il blocco tornerà senza causa evidente.

Annotate il nome dell'adattatore, il commutatore a cui era associato e lo stato di ipconfig prima e dopo. Se il blocco torna dopo un aggiornamento, quella nota è la differenza tra un controllo di cinque minuti e ricominciare da zero.