Cisco VPN haltas post Hyper-V: malligi aŭ rekonstrui?

La kliento turniĝas ĉe securing communications kaj neniam montras saluton, kaj la sola ŝanĝo estis instalado de emulatoro. Tiu ŝablono montras al la virtuala adaptilo, ne al la profilo aŭ la pasvorto. La decido estas, ĉu la adaptilo estas ligita al Hyper-V ŝaltilo, kie ĝi ne devus esti, aŭ ĉu ĝi tute ne aperis.

Tiuj du statoj aspektas samaj en la kliento kaj bezonas malsamajn riparojn. Unu estas ligo, kiun vi povas malfari; la alia estas pelila problemo, kiun malligo ne tuŝos.

Kion atendas la fazo securing communications

Antaŭ ol la tunelo konstruiĝas, la kliento bezonas funkciantan lokan retan vojon al la enirejo. Ĝi instalas sian propran virtualan adaptilon kaj uzas ĝin kiel parton de tiu vojo. Se Hyper-V ligas tiun adaptilon al ŝaltilo kreita por emulatoro, la adaptilo povas ĉesi prezenti uzeblan itineron.

La kliento ne raportas, kiun adaptilon ĝi atendas. La protokolo kutime finiĝas ĉe la lasta atingita fazo, kaj la sama fiasko aperas por ĉiu enireja adreso. Tial la instalhistorio gravas pli ol la erarteksto. La protokolo tamen indas konserviĝi; ĝi diras la fazon, ne la kaŭzon.

Reenigi akreditaĵojn aŭ reinstali la profilon ne povas ŝanĝi ŝaltilan ligon. Se tiuj estas viaj unuaj du paŝoj, vi riparas la malĝustan tavolon.

Decido unu: ĉu la VPN-adaptilo estas ligita al la malĝusta ŝaltilo?

Malfermu Hyper-V Manager, poste Virtual Switch Manager, kaj legu la adaptilan liston por ĉiu ŝaltilo. La adaptilo Cisco ne devus aperi kiel aldonaĵo de emulatora ŝaltilo. Se ĝi aperas, tio estas via eraro, kaj la riparo estas forigi ĝin de tiu ŝaltilo.

Unue restartigu, por ke la kliento startu pure, ne duone ligite. Forigu la ligon, apliku ĝin, kaj lasu la aliajn adaptilojn trankvile ĝis vi testos. La ŝanĝo estas inversigebla kaj malinstalas nenion, sed notu, kiujn adaptilojn vi malligis.

Startigu la klienton kaj provu la konekton. Se ĝi ankoraŭ haltas, malligu la ceterajn virtualajn adaptilojn unu post unu kaj testu post ĉiu, por ke vi sciu, kiu gravis.

Decido du: ĉu la adaptilo funkcias sed sen adreso?

Rulu ipconfig /all el altigita komandprompto por ke kaŝitaj adaptiloj inkluziviĝu, kaj komparu la liston kun tio, kion vi memoras de antaŭ la instalado. Adaptilo sen adreso kaj kun stato de malkonektita medio kutime signifas, ke la pelilo ne startis. Tio ne ripariĝas per malligo. Notu la precizan staton antaŭ ol ŝanĝi ion.

Adaptilo, kiu funkcias sed estas ligita al la malĝusta ŝaltilo, estas la kazo el la antaŭa sekcio. La adresa stato estas kiel vi distingas la du.

Restarigu la emulatoron sen restarigi la difekton

Kiam la tunelo funkcias, religu la propran adaptilon de la emulatoro al ĝia ŝaltilo kaj konfirmu, ke la VM ricevas adreson. Ne religu la VPN-adaptilon. Testu kaj la emulatoron kaj la klienton ankoraŭ foje antaŭ ol nomi ĝin finita.

Sur administrata labortablo, diru al la administranto, kiun ligon vi ŝanĝis. Posta ĝisdatigo de la politiko povas restarigi la malnovan aldonon, kaj la halto revenos sen evidenta kaŭzo.

Notu la adaptilan nomon, la ŝaltilon al kiu ĝi estis ligita, kaj la staton ipconfig antaŭ kaj poste. Se la halto revenos post ĝisdatigo, tiu noto estas la diferenco inter kvinminuta kontrolo kaj rekomenco de nulo.