Защо вашият Mac VPN иска достъп до Keychain всеки път
Определете кой компонент предизвиква всеки прозорец на Mac VPN, спрете дублиращите се опити за свързване и поправете достъпа до Keychain, без да нулирате целия ключодържател.
Едно щракване върху Connect трябва да даде един прозорец за вход. На Mac често дава три и те рядко имат един и същ собственик: локалните подкани за идентификационни данни са на Keychain, VPN шлюзът отговаря за удостоверяването, а клиентът — за собствените си известия. Вместо да търсите превключвател, който заглушава всичко, третирайте всеки прозорец като отделен дефект със своя поправка. Ръководството по-долу минава през един целенасочен опит за свързване и завършва с проверка, която можете да повторите.
Наименувайте собственика на всеки диалог, преди да променяте настройка
Първата стъпка е отчетност, не конфигурация. Направете един опит за свързване и за всеки появил се прозорец запишете четири полета: името на приложението в диалога, точния текст без нищо тайно, фазата, в която се появи, и какво се случи, когато го отмените. Три такива реда покриват почти всеки доклад, който съм виждал.
Собствеността определя правилната поправка, а грешната поправка обикновено превръща една подкана в три:
| Window | Who owns it | Correct fix | What not to do |
|---|---|---|---|
| “wants to use your confidential information stored in…” | The item's access control list in your login keychain | Approve the specific client helper, once, after checking the name | Resetting the login keychain, or granting Always Allow to every application |
| “Sign in to <organization>” or an MFA push | The gateway's identity provider | Use the client's supported session renewal, or re-authenticate | Scripting a fixed password or code into the client |
| “Connection failed”, “Update required”, a policy banner | The client or your organization | Read the first error and fix its cause | Hiding notices by editing a preference file the client rewrites |
Подкана, която се връща в рамките на същия опит, е различен сигнал от тази, която се връща при следващия опит. Първата обикновено означава, че връзката е рестартирала под вас; втората обикновено означава, че отново се пита за запазени идентификационни данни. Отбележете коя от двете имате, преди да пипате ключодържателя, защото те почти нямат общо.
Разберете колко неща стартират тунела
Четири механизма могат да стартират един и същ VPN на Mac: действие от лентата с менюта, елемент за вход, правило On Demand и скрипт или агент. Когато два от тях се задействат, второто стартиране може да дойде, докато първото още чака удостоверяване, което създава дублиран прозорец и никакъв напредък. Първо избройте какво е конфигурирано: scutil --nc list отпечатва VPN услугите, които Системни настройки познават, с текущия им статус. Клиентите със собствено мрежово разширение държат профилите в приложението и може да не се появят там, затова проверете и собствения списък с връзки на клиента.
След това потърсете конкуриращи се стартери. scutil --nc show "Work VPN" отпечатва речника с конфигурация на вградена услуга, включително правилата On Demand; правило, което се свързва отново при всяка промяна на интерфейса, ще рестартира тунела — и ще отвори отново подканата за удостоверяване — всеки път, когато Wi-Fi се мести или дисплей събуди мрежовия стек. Проверете елементите за вход в Системни настройки > Общи > Елементи за вход и избройте агентите за потребител с ls ~/Library/LaunchAgents. Не пипайте нищо, собственост на управляван от MDM стек за сигурност; премахването му обикновено се връща при следващата проверка.
За да видите какво всъщност работи по време на опит: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. Два клиентски помощника там, където очаквате един, обясняват „защо получих две подкани“ много по-често от всеки проблем с идентификационните данни.
Поправете достъпа до ключодържателя, без да го нулирате
Подканата идва от списъка за контрол на достъпа на запазения елемент, не от VPN протокола. Всеки елемент записва кои приложения могат да го четат без питане. След актуализация на клиента помощникът, който пита, може да носи друго име или подпис, докато елементът още изброява стария, затова macOS пита отново при всяка връзка. Одобряването на новия помощник за този един елемент е цялата поправка; одобряването на всяко приложение не е.
Можете да потвърдите, че причината е ACL, без да пипате VPN: security find-generic-password -s "service-name" -g чете същия елемент от терминал. Ако тази команда също предизвика подканата, диалогът принадлежи на ключодържателя, а тунелът е само задействащото условие. Apple указанията за трите бутона — Разреши веднъж, Винаги разреши, Откажи — си струват едно четене, защото именно Откажи кара подканата да се появи отново веднага, а не при следващия опит.
Ако сте одобрили грешния помощник, отворете елемента в Keychain Access, превключете на Access Control и премахнете този запис; това е връщането назад. Изтриването на ключодържателя за вход или пускането на инструмент за ремонт, който го преизгражда, също изхвърля несвързани пароли и е много по-голяма промяна от проблема.
Дръжте стъпките за вход и политика в потоците, които им принадлежат
Влизането през браузър или предизвикателството MFA принадлежат на шлюза. Ако организацията ви предлага запазване на сесията или удостоверяване чрез сертификат, използвайте го, защото това е поддържаният начин да се удостоверявате по-рядко. Въвеждането на фиксиран код в клиент или запазването на парола в скрипт, за да не се появява никога подканата, заменя интерактивен фактор със статична тайна и се проваля при следващото завъртане на политиката.
Известията на организацията са единствената категория, която не бива да заглушавате. Те обикновено налагат проверка на състоянието или потвърждение за допустима употреба и скриването им може да извади устройството от съответствие дори когато тунелът работи. Диалозите за грешки са другата категория: запазете текста на първата грешка, защото вторият диалог често е просто същият провал, съобщен след повторен опит.
Проверете с един опит, после след рестарт
След като дублиращите стартери са премахнати и записът в ключодържателя е поправен, направете един опит: затворете всеки екземпляр на клиента, включително помощника в лентата с менюта, свържете се веднъж и пребройте прозорците. Искате одобрението на ключодържателя, ако елементът е преизграден, и една стъпка за удостоверяване. Нищо повече. scutil --nc status "Work VPN" трябва да отчете Connected за вградена услуга.
След това рестартирайте веднъж и повторете. Подкана, която се връща само след рестарт, сочи към елемент за вход или правило On Demand, а не към идентификационни данни; тази, която се връща в сесията, сочи към ACL или към втори стартер. Ако все още се повтаря след двата прохода, полезното, което да дадете на администратора, е таблицата с три реда от първия опит — собственик, точен текст, фаза — а не екранна снимка на диалога.
По-малко подкани е целта, не безмълвни такива. Връзка, която крие стъпките си за оторизация, е връзка, която вече не можете да одитирате, и следващото завъртане на сертификатите ще ви завари без идея кой компонент се проваля.