Зошто вашиот Mac VPN бара пристап до Keychain секој пат
Утврдете која компонента го предизвикува секое барање на Mac VPN, запрете ги дупликат обидите за поврзување и поправете го пристапот до Keychain без ресетирање на целиот привезок клучеви.
Еден клик на Connect треба да даде еден прозорец за најава. На Mac често дава три, и тие ретко делат ист сопственик: привезокот клучеви ги поседува локалните барања за акредитиви, 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 или на втор стартер. Ако сѐ уште се повторува по двете поминувања, корисното нешто за да му го дадете на вашиот администратор е табелата со три реда од првиот обид – сопственик, точен текст, фаза – а не слика од екранот на дијалогот.
Целта е помалку барања, а не тивки. Врска што ги крие чекорите за авторизација е врска што повеќе не можете да ја ревидирате, а следната ротација на сертификати ќе ве најде без идеја која компонента пропаѓа.