vpncli ne funkcias en Windows? Lanĉu Cisco Secure Client ĝuste

Vi tajpas vpncli en Windows-invito kaj ricevas eraron, ke la komando ne estas rekonita, aŭ la fenestro malfermiĝas kaj poste haltas ĉe demando, kiun vi ne atendis. Ambaŭ simptomoj kutime venas de la sama loko: la maŝino havas pli ol unu Cisco VPN-klientan linion instalita, kaj la komando, kiun vi lanĉis, apartenas al la malĝusta. La solvo estas lanĉi la plenumeblon, kiu venas kun Secure Client, kaj poste respondi al la invitoj, kiujn la pordego efektive sendas.

La simptomo indikas du malsamajn klientojn

Cisco Secure Client enhavas Windows-komandlinian interfacon nomatan vpncli.exe. La pli malnova Cisco IPsec VPN Client liveris alian programon, vpnclient.exe, kun aliaj komandoj kaj aliaj pasvortaj ŝaltiloj. Gvidiloj, kiuj miksas la du, produktas komandojn, kiuj ŝajnas kredindaj kaj tuj malsukcesas. La instalita programa dosierujo estas la plej rapida maniero distingi ilin.

Se vpncli ne estas en PATH, tio ne estas pruvo, ke la komponanto mankas. La instalilo simple ne aldonas la dosierujon al PATH, do vi vokas la plenumeblon per ĝia plena vojo.

Lanĉu la plenumeblon, kiu apartenas al Secure Client

Por Secure Client 5.x-instalaĵo, la dokumentita loko estas la Secure Client-dosierujo sub Program Files (x86). En PowerShell la vokaoperatoro necesas, ĉar la vojo enhavas spacojn: & 'C:\Program Files (x86)\Cisco\Cisco Secure Client\vpncli.exe'. Se tiu dosiero mankas, kontrolu la instalitan version kaj ĝian dosierujon anstataŭ elŝuti malnovan klienton por plenigi la breĉon.

El cmd.exe la sama vojo funkcias sen la vokaoperatoro, sed ĝi ankoraŭ bezonas citilojn. Elektu unu ŝelon kaj restu en ĝi, ĉar la du pritraktas citilojn malsame, kaj duono de la malsukcesintaj ekzemploj interrete estas citila problemo.

Konektiĝu kaj respondu al tio, kion demandas la pordego

Ĉe la klienta invito, konektiĝu al la aprobita pordego aŭ al agordita kaŝnomo: connect vpn.example.com. Anstataŭigu la ekzemplon per via propra gastigantnomo. La kliento poste petas la akreditaĵojn, kiujn via disfaldiĝo postulas, kiuj povas inkluzivi elekton de atestilo, ĵetonkodon aŭ duan faktoron. Respondu al ĉiu invito laŭ la ordo, en kiu ĝi aperas.

La dokumentita ekzemplo de Cisco ankaŭ montras rubandon, kiu postulas eksplicitan respondon, do skripto, kiu liveras nur uzantnomon kaj pasvorton, povas halti ĉe tiu rubando. Legu la demandon sur la ekrano anstataŭ supozi, ke la sekva invito estas la pasvorto.

Kontrolu la seancon antaŭ ol fidi ĝin

Post kiam la konekto establiĝas, stats presas seancoinformojn: la pordegon, la asignitan adreson, la protokolon kaj la daŭron. Kontrolu ankaŭ unu celitan internan rimedon, ĉar seanco ekzistas antaŭ ol vi pruvis, ke ĝiaj itineroj, DNS kaj aplikaĵpermesoj plenumas la taskon. Notu la asignitan adreson, dum la seanco estas aktiva.

Lanĉu disconnect, kiam vi volas fini la VPN-seancon, kaj quit, kiam vi volas forlasi la interagan CLI. La du ne estas sinonimoj, kaj fermi la fenestron ne estas dokumentita anstataŭaĵo por iu ajn el ili.

Aŭtomatigo estas aparta decido

Funkcianta terminala ensaluto ne pruvas, ke planita tasko povas fini la saman aŭtentikigon. Notu la postulatan identecon, la plenumkonton, la atestilan aliron kaj ajnan uzantan interagon antaŭ ol transformi la seancon en fona tasko. Se la disfaldiĝo postulas retuman ensaluton aŭ aprobon, konfirmu la subtenatan laborfluon kun ĝia operatoro anstataŭ trakti la inviton kiel obstaklon.

Ne adaptu malnovajn ekzemplojn, kiuj metas pasvorton rekte en la komandlinion. Fiksaj linioj enigataj en interagan konversacion rompiĝas tuj kiam la pordego ŝanĝas siajn demandojn, kaj konservita akreditaĵo en skripto estas konkludo, kiu nur atendas esti skribita. La Cisco CLI-referenco dokumentas la subtenatajn komandojn por ĉi tiu kliento.

Kiam ensaluto malsukcesas, konservu la klientan version, la pordegon, la tempon kaj la ne-secretan erartekston. Tiuj kvar faktoj apartigas malĝustan plenumeblon disde aŭtentikiga rifuzo kaj disde konektita seanco, kiu ne atingas sian aplikaĵon.