Cisco Secure Client sur Mac: fenestro, aŭtomata konekto aŭ rekonekto?

Io rilata al Cisco aperas post kiam vi ensalutas, kaj ĝi eble konektas ion aŭ eble ne. La fenestro, la aŭtomata konekto kaj la rekonekto post retŝanĝo estas tri apartaj kondutoj kun tri apartaj posedantoj. Plej multaj frustritaj provoj forigi lanĉan eron komenciĝas per tiuj tri kunfanditaj en unu plendon. Apartigu ilin unue, kaj la ŝanĝpeto skribiĝos mem.

Nomu la konduton, kiun vi efektive vidas

Observu unu ensaluton sen tuŝi ion ajn kaj notu, kio okazas, laŭ ordo. Fenestro, kiu malfermiĝas sen konekto, estas unu kazo; fenestro, kiu malfermiĝas kaj konektas, estas alia; kaj konekto, kiu revenas post retŝanĝo, estas tria. Demandu, kio efektive starigas la tunelon, anstataŭ kio aperas sur la ekrano, ĉar la fenestro kaj la tunelo havas malsamajn posedantojn. Du specoj de pruvoj respondas tion, kaj nur unu el ili vidas ĉi tiun klienton:

scutil --nc list
ps aux | grep -i [v]pnagentd
ifconfig | grep -A3 utun

Legu la tri eligojn kune, ĉar scutil --nc list listigas la VPN-agordojn de la sistemo kaj malplena listo nur signifas, ke neniu sistema VPN-servo posedas tunelon. Cisco Secure Client ne registras unu: ĝi finiĝas tra vpnagentd kaj utun-interfaco, do la procezo kaj la interfaco estas la pruvoj, kiuj vidas ĝin. Kiam vpnagentd funkcias kaj utun-interfaco tenas adreson, la tunelo ekzistas eĉ kun fermita fenestro; kiam nek estas, la aŭtomata konekto estas malŝaltita kaj la fenestro estas la sola afero diskutinda. La fasado ankaŭ povas funkcii dum aparta fona servo posedas la tunelon, do la poseddemando apartenas al la profilaj sekcioj, ne al ĉi tiu.

La fenestro ĉe ensaluto estas lanĉa demando

Saluta fenestro venas de lanĉa agento aŭ de la propra prefero de la aplikaĵo malfermiĝi ĉe ensaluto, kaj neniu el ambaŭ estas la sama mekanismo kiel la konekta politiko. Identigu la instalitan produkton kaj version antaŭ ol redakti ion, ĉar dokumentado por pli malnovaj eldonoj priskribas dosierojn, kiujn aktuala instalaĵo eble ne uzas. Malŝalti la aŭtomatan konekton ne nepre malhelpas la fenestron malfermiĝi, kaj haltigi la fenestron ne haltigas rekonekton. Uzu la subtenatan lanĉan regilon de la kliento aŭ la softvaran procezon de via administranto, en tiu ordo.

Sur administrata Mac, konfirmu, ĉu la konduto venas per instalita agorda profilo, antaŭ ol trakti ĝin kiel lokan preferon. La sistemo povas listigi la profilojn, kiujn ĝi havas, kaj administrata ensaluta ero ne estas via por forigi:

profiles show -type configuration

Kie la agordo estas uzantokontrolebla, ŝanĝu ĝin en la preferoj de la kliento kaj elsalutu por testi. Kie ĝi estas ŝlosita, nur la posedanto de la profilo povas ŝanĝi ĝin. Forigi dosierojn loke kreas diverĝon, kiun la sekva ĝisdatigo silente riparas, kio igas ĝin la malplej daŭra solvo disponebla. Griza markobutono ne estas difektita kliento; ĝi estas politika deklaro.

Auto Connect on Start estas aparta prefero

La konekta gvidilo de Cisco nomas Auto Connect on Start la prefero, kiu regas konekprovon kiam la kliento lanĉiĝas, kaj priskribas ĝin kiel malŝaltita defaŭlte. Enmetita profilo povas ŝalti ĝin, kio klarigas, kial du Mac-oj kun la sama kliento kondutas malsame ĉe ensaluto. Serĉu tiun preferon en la agordoj de la kliento antaŭ ol supozi ion pri lanĉaj eroj.

Ŝanĝu ĝin per la subtenata regilo kaj testu per plena elsaluto anstataŭ relanĉo, ĉar iuj komponantoj startas nur kun la ensaluta seanco. Poste konfirmu, ke la permana konekto ankoraŭ funkcias, ĉar prefero, kiu subpremas la aŭtomatan provon, ne devas forpreni vian kapablon konektiĝi. Se la kliento tamen tuj rekonektiĝas, vi rigardas la rekonektan konduton. Tio estas la sekva demando, kaj ĝi havas malsaman posedanton.

Auto Reconnect apartenas al tria agordo

Rekonekto regas tion, kio okazas post kiam establita seanco perdas sian vojon: fermo de kovrilo, ŝanĝo de Wi-Fi-reto, falo de drata ligo. Cisco dokumentas ĝin aparte de la starta konduto, do starta ŝanĝo ne tuŝos ĝin. Testu ĝin malligante la reton por momento kaj observante, ĉu la tunelo revenas sen ago.

Rekonekto, kiu ignoras intencan malligon, kutime estas politiko, ne cimo. Iuj enkondukoj postulas ĉiam-funkcian aranĝon, kiu apartenas al politika konversacio anstataŭ al ĉirkaŭvojo. Forigi la komponanton, kiu devigas ĝin, povas rompi laŭstatajn kontrolojn kaj poste esti restarigita de la sekva administra puŝo. Se la postulo estas legitima, demandu, kion ĝi garantiu kaj ĉu pli mallarĝa agordo kontentigas ĝin; se ne, la posedanto de la profilo povas ŝanĝi ĝin en unu loko anstataŭ vi ŝanĝi ĝin sur kvardek porteblaj komputiloj.

Petu la plej malgrandan ŝanĝon, poste kontrolu ĝin

Skribu la peton kun kvar faktoj: kiun klientan version vi uzas, kiun macOS-version vi uzas, kio aperas post ensaluto, kaj ĉu tunelo formiĝas sen ago. Poste esprimu la deziratan rezulton en unu frazo, kiun kolego povus efektivigi sen demandi vin. Teni la klienton havebla sed fermi ĝian fenestron estas alia peto ol malhelpi aŭtomatan konekton. Preciza peto ricevas politikŝanĝon, dum la malpreciza ricevas ĉirkaŭvojon, kiun neniu posedas.

Post la ŝanĝo, elsalutu kaj reensalutu, poste plenumu la permanan konekan laborfluon, de kiu vi dependas. Se rekonekto estis en la amplekso, testu ĝin aparte laŭ ajna proceduro, kiun via administranto permesas.

Kontrolu, ke la sekurecaj moduloj, kiujn la organizo postulas, ankoraŭ funkcias, ĉar silenta forigo estas facile preteratentebla ĝis revizio trovos ĝin. La rezulto, kiun vi volas, estas la petita starta konduto kun funkcianta kliento, ne forestanta piktogramo kaj mistero. Notu, kiu el la tri kondutoj ŝanĝiĝis, por ke la sekva persono povu distingi realan riparon de koincido.