A Cisco VPN lefagy Hyper-V után: oldjuk a kötést vagy építsük újra?

Az ügyfél pörög a securing communications szakasznál, és soha nem jelenít meg bejelentkezési kérést, és az egyetlen változás egy emulátor telepítése volt. Ez a minta a virtuális adapterre utal, nem a profilra vagy a jelszóra. A döntés az, hogy az adapter olyan Hyper-V kapcsolóhoz van-e kötve, amelyen nem kellene lennie, vagy egyáltalán nem jött fel.

Ez a két állapot ugyanúgy néz ki az ügyfélben, és különböző javítást igényel. Az egyik egy kötés, amelyet visszavonhat; a másik olyan illesztőprogram-probléma, amelyhez az oldás nem nyúl.

Mire vár a securing communications szakasz

Mielőtt az alagút felépül, az ügyfélnek működő helyi hálózati útvonalra van szüksége az átjáró felé. Telepíti a saját virtuális adapterét, és annak az útvonalnak a részeként használja. Ha a Hyper-V ezt az adaptert egy emulátorhoz létrehozott kapcsolóhoz csatolja, az adapter felhagyhat a használható útvonal biztosításával.

Az ügyfél nem jelenti, melyik adapterre vár. A napló általában az utolsó elért szakasznál ér véget, és ugyanaz a hiba jelenik meg minden átjárócímnél. Ezért fontosabb a telepítési előzmény, mint a hiba szövege. A naplót mégis érdemes megtartani; a szakaszt mondja meg, nem az okot.

A hitelesítő adatok újrabeírása vagy a profil újratelepítése nem változtat a kapcsoló kötésén. Ha ez az első két lépése, rossz réteget javít.

Első döntés: a VPN-adapter a rossz kapcsolóhoz van kötve?

Nyissa meg a Hyper-V Manager, majd a Virtual Switch Manager ablakot, és olvassa el az egyes kapcsolók adapterlistáját. A Cisco adapter nem jelenhet meg emulátor-kapcsoló csatolmányaként. Ha mégis, az az Ön hibája, és a javítás az, hogy eltávolítja arról a kapcsolóról.

Először indítson újra, hogy az ügyfél tisztán induljon, ne félig csatlakozva. Távolítsa el a kötést, alkalmazza, és hagyja békén a többi adaptert, amíg nem tesztelt. A változás visszafordítható és semmit nem távolít el, de írja fel, mely adaptereket oldotta le.

Indítsa el az ügyfelet, és próbálja ki a kapcsolatot. Ha még mindig elakad, oldja le a többi virtuális adaptert egyenként, és mindegyik után teszteljen, hogy tudja, melyik számított.

Második döntés: az adapter fut, de nincs címe?

Futtassa a ipconfig /all parancsot emelt parancssorból, hogy a rejtett adapterek is benne legyenek, és hasonlítsa össze a listát azzal, amire a telepítés előttről emlékszik. A cím nélküli, leválasztott adathordozó-állapotú adapter általában azt jelenti, hogy az illesztőprogram nem indult el. Ezt nem javítja az oldás. Jegyezze fel a pontos állapotot, mielőtt bármit megváltoztatna.

Az az adapter, amely fut, de a rossz kapcsolóhoz van csatolva, az előző szakasz esete. A cím állapota az, amivel a kettőt megkülönbözteti.

Állítsa helyre az emulátort a hiba helyreállítása nélkül

Amikor az alagút működik, csatolja vissza az emulátor saját adapterét a kapcsolójához, és erősítse meg, hogy a VM kap címet. Ne csatolja vissza a VPN-adaptert. Tesztelje még egyszer az emulátort és az ügyfelet is, mielőtt késznek tekinti.

Kezelt munkaállomáson mondja el az adminisztrátornak, melyik kötést változtatta meg. Egy későbbi házirend-frissítés visszaállíthatja a régi csatolást, és az elakadás nyilvánvaló ok nélkül visszatér.

Jegyezze fel az adapter nevét, a kapcsolót, amelyhez kötve volt, és a ipconfig állapotát előtte és utána. Ha az elakadás egy frissítés után visszatér, az a feljegyzés a különbség az ötperces ellenőrzés és az elölről kezdés között.