Cisco VPN henger etter Hyper-V: fjern bindingen eller bygg på nytt?
Klienten stopper ved securing communications etter en emulatorinstallasjon. Sjekk om VPN-adapteren er bundet til feil Hyper-V-svitsj eller aldri startet.
Klienten spinner ved securing communications og viser aldri en påloggingsforespørsel, og det eneste som endret seg var en emulatorinstallasjon. Mønsteret peker på den virtuelle adapteren, ikke profilen eller passordet. Avgjørelsen er om adapteren er bundet til en Hyper-V-svitsj den ikke hører hjemme på, eller om den aldri kom opp.
De to tilstandene ser like ut i klienten og krever ulike reparasjoner. Den ene er en binding du kan angre; den andre er et driverproblem som fjerning av bindingen ikke rører.
Hva securing communications-fasen venter på
Før tunnelen bygges, trenger klienten en fungerende lokal nettverksvei til gatewayen. Den installerer sin egen virtuelle adapter og bruker den som en del av veien. Hvis Hyper-V kobler den adapteren til en svitsj som ble laget for en emulator, kan adapteren slutte å tilby en brukbar rute.
Klienten rapporterer ikke hvilken adapter den venter på. Loggen slutter vanligvis ved siste fase den nådde, og samme feil vises for hver gateway-adresse. Derfor er installasjonshistorikken viktigere enn feilteksten. Loggen er likevel verdt å ta vare på; den sier fasen, ikke årsaken.
Å skrive inn påloggingsinformasjon på nytt eller installere profilen på nytt kan ikke endre en svitsjbinding. Hvis det er dine to første trekk, reparerer du feil lag.
Avgjørelse én: er VPN-adapteren bundet til feil svitsj?
Åpne Hyper-V Manager, deretter Virtual Switch Manager, og les adapterlisten for hver svitsj. Cisco-adapteren skal ikke vises som et vedlegg til en emulatorsvitsj. Gjør den det, er det din feil, og reparasjonen er å fjerne den fra den svitsjen.
Start på nytt først slik at klienten starter rent i stedet for halvtilkoblet. Fjern bindingen, bruk den, og la de andre adapterne være i fred til du har testet. Endringen er reversibel og avinstallerer ingenting, men skriv ned hvilke adaptere du fjernet bindingen på.
Start klienten og prøv tilkoblingen. Hvis den fortsatt henger, fjern bindingen på de gjenværende virtuelle adapterne én om gangen og test etter hver, slik at du vet hvilken som betydde noe.
Avgjørelse to: er adapteren oppe, men uten adresse?
Kjør ipconfig /all fra en forhøyet ledetekst slik at skjulte adaptere også kommer med, og sammenlign listen med det du husker fra før installasjonen. En adapter uten adresse og med frakoblet mediestatus betyr vanligvis at driveren ikke startet. Det repareres ikke ved å fjerne bindingen. Noter den nøyaktige tilstanden før du endrer noe.
En adapter som er oppe, men koblet til feil svitsj, er tilfellet fra forrige avsnitt. Adressestatusen er hvordan du skiller de to.
Gjenopprett emulatoren uten å gjenopprette feilen
Når tunnelen virker, kobler du emulatorens egen adapter til svitsjen igjen og bekrefter at VM-en får en adresse. Ikke koble VPN-adapteren tilbake. Test både emulatoren og klienten én gang til før du kaller det ferdig.
På en administrert arbeidsstasjon, fortell administratoren hvilken binding du endret. En senere policyoppdatering kan gjenopprette den gamle tilkoblingen, og hengingen kommer tilbake uten tydelig årsak.
Noter adapternavnet, svitsjen den var bundet til, og ipconfig-tilstanden før og etter. Hvis hengingen kommer tilbake etter en oppdatering, er den noten forskjellen mellom en femminutters sjekk og å starte på nytt.