Cisco VPN se blochează după Hyper-V: deconectezi legătura sau reconstruiești?

Clientul se învârte la securing communications și nu afișează niciodată cererea de autentificare, iar singurul lucru care s-a schimbat a fost instalarea unui emulator. Acest tipar indică adaptorul virtual, nu profilul sau parola. Decizia este dacă adaptorul este legat de un comutator Hyper-V pe care nu ar trebui să fie, sau dacă nu a apărut deloc.

Cele două stări arată la fel în client și necesită reparații diferite. Una este o legătură pe care o puteți anula; cealaltă este o problemă de driver pe care dezlegarea nu o atinge.

Ce așteaptă etapa securing communications

Înainte de a se construi tunelul, clientul are nevoie de o cale de rețea locală funcțională către gateway. Își instalează propriul adaptor virtual și îl folosește ca parte a acelei căi. Dacă Hyper-V atașează acel adaptor la un comutator creat pentru un emulator, adaptorul poate înceta să ofere o rută utilizabilă.

Clientul nu raportează la ce adaptor așteaptă. Jurnalul se termină de obicei la ultima etapă atinsă, iar aceeași eroare apare pentru fiecare adresă de gateway. De aceea istoricul instalărilor contează mai mult decât textul erorii. Jurnalul merită totuși păstrat; spune etapa, nu cauza.

Reintroducerea acreditărilor sau reinstalarea profilului nu pot schimba o legătură de comutator. Dacă aceștia sunt primii doi pași, reparați stratul greșit.

Prima decizie: adaptorul VPN este legat de comutatorul greșit?

Deschideți Hyper-V Manager, apoi Virtual Switch Manager, și citiți lista de adaptoare pentru fiecare comutator. Adaptorul Cisco nu ar trebui să apară ca atașament al unui comutator de emulator. Dacă apare, este greșeala dumneavoastră, iar reparația este să-l scoateți din acel comutator.

Reporniți mai întâi ca clientul să pornească curat, nu pe jumătate conectat. Scoateți legătura, aplicați-o și lăsați celelalte adaptoare în pace până nu testați. Schimbarea este reversibilă și nu dezinstalează nimic, dar notați ce adaptoare ați dezlegat.

Porniți clientul și încercați conexiunea. Dacă încă se blochează, dezlegați adaptoarele virtuale rămase unul câte unul și testați după fiecare, ca să știți care a contat.

A doua decizie: adaptorul este activ, dar fără adresă?

Rulați ipconfig /all dintr-o consolă ridicată pentru ca adaptoarele ascunse să fie incluse, și comparați lista cu ce vă amintiți dinainte de instalare. Un adaptor fără adresă și cu starea de suport deconectat înseamnă de obicei că driverul nu a pornit. Asta nu se repară prin dezlegare. Notați starea exactă înainte de a schimba ceva.

Un adaptor activ, dar atașat la comutatorul greșit, este cazul din secțiunea anterioară. Starea adresei este ce distinge cele două.

Restabiliți emulatorul fără a restabili defectul

Când tunelul funcționează, atașați din nou adaptorul propriu al emulatorului la comutatorul său și confirmați că VM-ul primește o adresă. Nu reatașați adaptorul VPN. Testați încă o dată atât emulatorul, cât și clientul, înainte de a considera lucrul încheiat.

Pe o stație de lucru administrată, spuneți administratorului ce legătură ați schimbat. O actualizare ulterioară de politici poate restabili vechiul atașament, iar blocajul revine fără o cauză evidentă.

Notați numele adaptorului, comutatorul de care era legat și starea ipconfig înainte și după. Dacă blocajul revine după o actualizare, acea notă este diferența dintre o verificare de cinci minute și a o lua de la capăt.