Cisco VPN hang ná Hyper-V: ontbind of herbou?

Die kliënt draai by securing communications en wys nooit ’n aanmeldprompt nie, en die enigste ding wat verander het, was ’n emulator-installasie. Daardie patroon dui op die virtuele adapter, nie die profiel of die wagwoord nie. Die besluit is of die adapter aan ’n Hyper-V-skakelaar gebind is waar dit nie hoort nie, of of dit glad nie opgekom het nie.

Daardie twee toestande lyk in die kliënt dieselfde en verg verskillende herstellings. Die een is ’n binding wat jy kan ongedaan maak; die ander is ’n drywerprobleem waaraan ontbinding nie raak nie.

Waarop die securing-communications-stadium wag

Voordat die tonnel gebou word, het die kliënt ’n werkende plaaslike netwerkpad na die gateway nodig. Dit installeer sy eie virtuele adapter en gebruik dit as deel van daardie pad. As Hyper-V daardie adapter aan ’n skakelaar koppel wat vir ’n emulator geskep is, kan die adapter ophou om ’n bruikbare roete te bied.

Die kliënt rapporteer nie aan watter adapter dit wag nie. Die log eindig gewoonlik by die laaste stadium wat dit bereik het, en dieselfde fout verskyn vir elke gateway-adres. Daarom maak die installasiegeskiedenis meer saak as die foutteks. Die log is steeds werd om te hou; dit sê vir jou die stadium, nie die oorsaak nie.

Om weer aanmeldgegewens in te voer of die profiel te herinstalleer kan nie ’n skakelaarbinding verander nie. As dit jou eerste twee stappe is, herstel jy die verkeerde laag.

Besluit een: is die VPN-adapter aan die verkeerde skakelaar gebind?

Maak Hyper-V Manager oop, dan Virtual Switch Manager, en lees die adapterlys vir elke skakelaar. Die Cisco-adapter behoort nie as ’n aanhegsel van ’n emulatorskakelaar te verskyn nie. As dit wel doen, is dit jou fout, en die herstel is om dit van daardie skakelaar te verwyder.

Herbegin eers sodat die kliënt skoon begin eerder as halfgekoppel. Verwyder die binding, pas dit toe, en laat die ander adapters alleen totdat jy getoets het. Die verandering is omkeerbaar en verwyder niks, maar skryf neer watter adapters jy ontbind het.

Begin die kliënt en probeer die verbinding. As dit steeds hang, ontbind die oorblywende virtuele adapters een op ’n slag en toets ná elkeen, sodat jy weet watter een saak gemaak het.

Besluit twee: is die adapter op maar sonder adres?

Voer ipconfig /all uit vanaf ’n verhoogde opdragprompt sodat verborge adapters ingesluit word, en vergelyk die lys met wat jy van voor die installasie onthou. ’n Adapter sonder adres en met ’n media-ontkoppelde toestand beteken gewoonlik dat die drywer nie begin het nie. Dit word nie deur ontbinding herstel nie. Let op die presiese toestand voordat jy iets verander.

’n Adapter wat op is maar aan die verkeerde skakelaar gekoppel is, is die geval uit die vorige afdeling. Die adrestoestand is hoe jy die twee onderskei.

Herstel die emulator sonder om die fout te herstel

Wanneer die tonnel werk, koppel die emulator se eie adapter weer aan sy skakelaar en bevestig dat die VM ’n adres kry. Moenie die VPN-adapter weer koppel nie. Toets beide die emulator en die kliënt nog een keer voordat jy dit as klaar beskou.

Op ’n bestuurde werkstasie, sê vir die administrateur watter binding jy verander het. ’n Latere beleidsverfrissing kan die ou aanhegsel herstel, en die hang sal terugkeer sonder duidelike oorsaak.

Teken die adapternaam, die skakelaar waaraan dit gebind was, en die ipconfig-toestand voor en ná aan. As die hang ná ’n opdatering terugkom, is daardie rekord die verskil tussen ’n vyfminuutkontrole en om heeltemal oor te begin.