Kial via Mac-VPN petas Keychain-aliron ĉiufoje

Unu klako sur Connect devus produkti unu salutfenestron. Sur Mac ĝi ofte produktas tri, kaj ili malofte havas la saman posedanton: la ŝlosilaro posedas lokajn petskribojn de akreditaĵoj, la VPN-enirejo posedas aŭtentikigon, kaj la kliento posedas siajn proprajn sciigojn. Anstataŭ serĉi ŝaltilon, kiu silentigas ĉion, traktu ĉiun fenestron kiel apartan difekton kun sia propra riparo. La gvidilo sube trairas unu intencan konektoprovon kaj finiĝas per kontrolo, kiun vi povas ripeti.

Nomu la posedanton de ĉiu dialogo antaŭ ol ŝanĝi agordon

La unua paŝo estas librotenado, ne agordado. Faru unu konektoprovon kaj, por ĉiu aperanta fenestro, notu kvar kampojn: la aplikaĵan nomon en la dialogo, la ĝustan tekston sen io sekreta, la fazon en kiu ĝi aperis, kaj kio okazis kiam vi nuligis ĝin. Tri tiaj vicoj kovras preskaŭ ĉiun raporton, kiun mi vidis.

Posedado decidas la ĝustan riparon, kaj la malĝusta riparo kutime estas tio, kio igas unu peton tri:

Peto, kiu revenas ene de la sama provo, estas alia signalo ol tiu, kiu revenas ĉe la sekva provo. La unua kutime signifas, ke la konekto restartiĝis sub vi; la dua kutime signifas, ke oni denove petas konservitan akreditaĵon. Notu, kiun vi havas, antaŭ ol tuŝi la ŝlosilaron, ĉar la du preskaŭ nenion komunan havas.

Eltrovu, kiom da aferoj startigas la tunelon

Kvar mekanismoj povas startigi la saman VPN sur Mac: menuila ago, saluta ero, On Demand-regulo, kaj skripto aŭ agento. Kiam du el ili ekagas, la dua starto povas alveni dum la unua ankoraŭ atendas aŭtentikigon, kio produktas duoblan fenestron kaj neniun progreson. Unue listigu, kio estas agordita: scutil --nc list presas la VPN-servojn, kiujn Sistemaj Agordoj konas, kun ilia nuna stato. Klientoj, kiuj liveras sian propran retan etendaĵon, tenas profilojn ene de la aplikaĵo kaj eble ne aperas tie, do kontrolu ankaŭ la propran konektoliston de la kliento.

Poste serĉu konkurencajn startilojn. scutil --nc show "Work VPN" presas la agordan vortaron de enkonstruita servo, inkluzive de On Demand-reguloj; regulo, kiu rekonektiĝas ĉe iu ajn interfaca ŝanĝo, restartigos la tunelon — kaj remalfermos la aŭtentikigan peton — ĉiufoje kiam Wi-Fi migras aŭ ekrano vekas la retan stakon. Kontrolu salutajn erojn sub Sistemaj Agordoj > Ĝeneralaj > Salutaj Eroj, kaj listigu laŭ-uzantajn agentojn per ls ~/Library/LaunchAgents. Lasu trankvile ion ajn posedatan de MDM-administrata sekureca stako; forigo kutime estas repuŝata ĉe la sekva kontrolo.

Por vidi, kio efektive funkcias dum provo: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. Du klientaj helpiloj tie, kie vi atendas unu, klarigas "kial mi ricevis du petojn" multe pli ofte ol iu ajn akreditaĵa problemo.

Riparu ŝlosilaran aliron sen restarigi la ŝlosilaron

La peto venas de la alirregada listo de la konservita ero, ne de la VPN-protokolo. Ĉiu ero registras, kiuj aplikaĵoj rajtas legi ĝin sen demando. Post klienta ĝisdatigo, la helpilo, kiu demandas, povas havi alian nomon aŭ subskribon dum la ero ankoraŭ listigas la malnovan, do macOS denove demandas ĉe ĉiu konekto. Aprobi la novan helpilon por tiu sola ero estas la tuta riparo; aprobi ĉiun aplikaĵon ne estas.

Vi povas konfirmi, ke la ACL estas la kaŭzo sen tuŝi la VPN: security find-generic-password -s "service-name" -g legas la saman eron el terminalo. Se tiu komando ankaŭ starigas la peton, la dialogo apartenas al la ŝlosilaro kaj la tunelo estas nur la ellasilo. La gvidado de Apple pri la tri butonoj — Permesi unufoje, Permesi ĉiam, Rifuzi — indas unufoje legi, ĉar Rifuzi estas tio, kio igas la peton reveni tuj anstataŭ ĉe la sekva provo.

Se vi aprobis la malĝustan helpilon, malfermu la eron en Keychain Access, ŝaltu al Access Control, kaj forigu tiun enskribon; tio estas la malfaro. Forigi la salutan ŝlosilaron, aŭ lanĉi riparilon, kiu rekonstruas ĝin, ankaŭ forĵetas nerilatajn pasvortojn kaj estas multe pli granda ŝanĝo ol la problemo.

Tenu salutajn kaj politikajn paŝojn en la fluoj, kiuj posedas ilin

Retumila saluto aŭ MFA-defio apartenas al la enirejo. Se via organizo ofertas sesian daŭrecon aŭ atestilaŭtentikigon, uzu ĝin, ĉar tio estas la subtenata maniero aŭtentikiĝi malpli ofte. Tajpi fiksan kodon en klienton, aŭ konservi pasvorton en skripto por ke la peto neniam aperu, anstataŭigas interagan faktoron per statika sekreto kaj malsukcesas la sekvan fojon, kiam la politiko rotacias.

Organizaj sciigoj estas la sola kategorio, kiun vi ne devus subpremi. Ili kutime devigas sintenan kontrolon aŭ akcepton de akceptebla uzo, kaj kaŝi ilin povas meti la aparaton ekster konformecon eĉ dum la tunelo funkcias. Eraraj dialogoj estas la alia kategorio: konservu la unuan erartekston, ĉar dua dialogo ofte estas nur la sama malsukceso raportita post rea provo.

Kontrolu per unu provo, poste post restarto

Kun duoblaj startiloj forigitaj kaj la ŝlosilara enskribo riparita, faru unu solan provon: fermu ĉiun klientan instancon inkluzive de la menuila helpilo, konektu unufoje, kaj nombru la fenestrojn. Vi volas la ŝlosilaran aprobon, se la ero estis rekonstruita, kaj unu aŭtentikigan paŝon. Nenion pli. scutil --nc status "Work VPN" devus raporti Connected por enkonstruita servo.

Poste restartigu unufoje kaj ripetu. Peto, kiu revenas nur post restarto, montras al saluta ero aŭ On Demand-regulo, ne al akreditaĵoj; tiu, kiu revenas ene de la sesio, montras al la ACL aŭ al dua startilo. Se ĝi ankoraŭ ripetiĝas post ambaŭ provoj, la utila afero por doni al via administranto estas la tri-vica tabelo el la unua provo — posedanto, ĝusta teksto, fazo — ne ekrankopio de la dialogo.

Malpli da petoj estas la celo, ne silentaj. Konekto, kiu kaŝas siajn rajtigajn paŝojn, estas konekto, kiun vi ne plu povas aŭditi, kaj la sekva atestila rotacio trovos vin sen ideo, kiu komponento malsukcesas.