Cisco VPN hænger efter Hyper-V: fjern binding eller genopbyg?

Klienten kører i ring ved securing communications og viser aldrig en loginprompt, og det eneste, der ændrede sig, var en emulatorinstallation. Det mønster peger på den virtuelle adapter, ikke på profilen eller adgangskoden. Beslutningen er, om adapteren er bundet til en Hyper-V-switch, den ikke burde være på, eller om den slet ikke kom op.

De to tilstande ser ens ud i klienten og kræver forskellige reparationer. Den ene er en binding, du kan fortryde; den anden er et driverproblem, som fjernelse af bindingen ikke rører.

Hvad securing communications-fasen venter på

Før tunnelen bygges, har klienten brug for en fungerende lokal netværksvej til gatewayen. Den installerer sin egen virtuelle adapter og bruger den som en del af den vej. Hvis Hyper-V knytter den adapter til en switch, der blev oprettet til en emulator, kan adapteren holde op med at tilbyde en brugbar rute.

Klienten rapporterer ikke, hvilken adapter den venter på. Loggen slutter typisk ved den sidste fase, den nåede, og den samme fejl ses for hver gateway-adresse. Derfor betyder installationshistorikken mere end fejlteksten. Loggen er stadig værd at gemme; den fortæller fasen, ikke årsagen.

At indtaste legitimationsoplysninger igen eller geninstallere profilen kan ikke ændre en switchbinding. Hvis det er dine første to træk, reparerer du det forkerte lag.

Beslutning et: er VPN-adapteren bundet til den forkerte switch?

Åbn Hyper-V Manager, derefter Virtual Switch Manager, og læs adapterlisten for hver switch. Cisco-adapteren bør ikke fremgå som en tilknytning til en emulatorswitch. Gør den det, er det din fejl, og reparationen er at fjerne den fra den switch.

Genstart først, så klienten starter rent i stedet for halvtilsluttet. Fjern bindingen, anvend den, og lad de andre adaptere være, indtil du har testet. Ændringen er reversibel og afinstallerer intet, men skriv ned, hvilke adaptere du fjernede bindingen fra.

Start klienten, og prøv forbindelsen. Hvis den stadig går i stå, skal du fjerne bindingen på de resterende virtuelle adaptere en ad gangen og teste efter hver, så du ved, hvilken der betød noget.

Beslutning to: er adapteren oppe, men uden adresse?

Kør ipconfig /all fra en forhøjet prompt, så skjulte adaptere også kommer med, og sammenlign listen med det, du husker fra før installationen. En adapter uden adresse og med afbrudt medietilstand betyder normalt, at driveren ikke startede. Det repareres ikke ved at fjerne bindingen. Notér den præcise tilstand, før du ændrer noget.

En adapter, der er oppe, men knyttet til den forkerte switch, er tilfældet fra forrige afsnit. Adressetilstanden er, hvordan du skelner de to.

Gendan emulatoren uden at gendanne fejlen

Når tunnelen virker, skal du knytte emulatorens egen adapter til dens switch igen og bekræfte, at VM'en får en adresse. Sæt ikke VPN-adapteren tilbage. Test både emulatoren og klienten en gang til, før du kalder det færdigt.

På en administreret arbejdsstation skal du fortælle administratoren, hvilken binding du ændrede. En senere politikopdatering kan gendanne den gamle tilknytning, og hængningen vender tilbage uden tydelig årsag.

Notér adapterens navn, den switch den var bundet til, og ipconfig-tilstanden før og efter. Hvis hængningen kommer tilbage efter en opdatering, er den note forskellen mellem et femminutters tjek og at starte forfra.