Cisco VPN hänger efter Hyper-V: ta bort bindningen eller bygga om?
Klienten fastnar vid securing communications efter en emulatorinstallation. Kontrollera om VPN-adaptern är bunden till fel Hyper-V-växel eller aldrig startade.
Klienten snurrar vid securing communications och visar aldrig en inloggningsfråga, och det enda som ändrades var en emulatorinstallation. Mönstret pekar på den virtuella adaptern, inte på profilen eller lösenordet. Beslutet är om adaptern är bunden till en Hyper-V-växel den inte hör hemma på, eller om den aldrig kom upp.
De två tillstånden ser likadana ut i klienten och kräver olika reparationer. Det ena är en bindning du kan ångra; det andra är ett drivrutinsproblem som borttagning av bindningen inte rör.
Vad securing communications-fasen väntar på
Innan tunneln byggs behöver klienten en fungerande lokal nätverksväg till gatewayen. Den installerar sin egen virtuella adapter och använder den som en del av vägen. Om Hyper-V kopplar den adaptern till en växel som skapats för en emulator kan adaptern sluta erbjuda en användbar väg.
Klienten rapporterar inte vilken adapter den väntar på. Loggen slutar oftast vid den senaste fasen den nådde, och samma fel syns för varje gateway-adress. Därför är installationshistoriken viktigare än feltexten. Loggen är ändå värd att spara; den säger fasen, inte orsaken.
Att ange uppgifterna igen eller installera om profilen kan inte ändra en växelbindning. Om det är dina två första drag reparerar du fel lager.
Beslut ett: är VPN-adaptern bunden till fel växel?
Öppna Hyper-V Manager, sedan Virtual Switch Manager, och läs adapterlistan för varje växel. Cisco-adaptern ska inte visas som en anslutning till en emulatorväxel. Gör den det är det ditt fel, och reparationen är att ta bort den från den växeln.
Starta om först så att klienten startar rent i stället för halvt ansluten. Ta bort bindningen, tillämpa den, och låt de andra adaptrarna vara tills du har testat. Ändringen är reversibel och avinstallerar inget, men skriv ned vilka adaptrar du tog bort bindningen på.
Starta klienten och prova anslutningen. Om den fortfarande hänger, ta bort bindningen på de återstående virtuella adaptrarna en i taget och testa efter varje, så att du vet vilken som spelade roll.
Beslut två: är adaptern uppe men utan adress?
Kör ipconfig /all från en förhöjd kommandotolk så att dolda adaptrar ingår, och jämför listan med det du minns från före installationen. En adapter utan adress och med frånkopplad mediastatus betyder oftast att drivrutinen inte startade. Det repareras inte genom att ta bort bindningen. Notera det exakta tillståndet innan du ändrar något.
En adapter som är uppe men kopplad till fel växel är fallet från föregående avsnitt. Adresstillståndet är hur du skiljer de två åt.
Återställ emulatorn utan att återställa felet
När tunneln fungerar kopplar du tillbaka emulatorns egen adapter till dess växel och bekräftar att VM:en får en adress. Koppla inte tillbaka VPN-adaptern. Testa både emulatorn och klienten en gång till innan du kallar det klart.
På en hanterad arbetsstation, berätta för administratören vilken bindning du ändrade. En senare policyuppdatering kan återställa den gamla anslutningen, och hängningen kommer tillbaka utan tydlig orsak.
Notera adapterns namn, växeln den var bunden till och ipconfig-tillståndet före och efter. Om hängningen kommer tillbaka efter en uppdatering är den anteckningen skillnaden mellan en femminuterskontroll och att börja om.