Mac постојано бара VPN лозинка: приврзок со клучеви или сметка?
Mac може да бара лозинка на приврзокот со клучеви за најава, администраторска лозинка или самата VPN сметка. Прочитајте чиј е дијалогот, па поправете го вистинското складиште.
Го отклучувате Mac, го отворате VPN клиентот и лист за лозинка се појавува пред тунелот воопшто да започне. Ја внесувате лозинката на портата и таа или се одбива, или листот се враќа по миг. Потоа повторно прашува по будење од спиење, одјавување или ажурирање на клиентот. Тој лист ретко е VPN серверот што бара акредитиви; обично macOS бара дозвола да чита, отклучи или смени локален запис, а лозинката му припаѓа на сопственикот на тој запис, не на вашата VPN сметка.
Поврзете го листот со идентитетот зад него
Четири барања изгледаат речиси исто, а само едно се однесува на портата. Формулацијата, процесот што бара пристап и ставката наведена подолу ви кажуваат со кое се соочувате.
| What the sheet says | Whose password it wants | What it does not do |
|---|---|---|
| Enter the password for the login keychain | The local keychain password, normally your Mac login password | It does not authenticate you to the VPN server |
| An app wants to use confidential information stored in your keychain | Approval for that app to retrieve one item | It does not grant privileges at the gateway |
| macOS wants to make changes, and asks for administrator authorization | An admin account on this Mac, for the named setting | It does not change the VPN account password |
| The client itself asks for a username and password to connect | The remote account, certificate or profile credential | It does not unlock anything local |
Дијалогот за локален пристап не докажува ништо за серверот. Одбивањето од портата се појавува во клиентот со текстот за грешка на добавувачот, не како системски лист што нуди отклучување на приврзок со клучеви. Обратното е исто толку често: внесувањето на лозинката на портата во лист на приврзокот со клучеви го остава записот заклучен и додава неуспешен обид.
Дијалогот именува сопственик, складиште и дејство
Барањата на приврзокот со клучеви се однесуваат на преземање, не на автентикација кон нешто далечно. Описот на Apple за дијалогот за барање е тесен: Дозволи еднаш, Секогаш дозволи и Одбиј контролираат дали таа апликација смее да ја чита зачуваната ставка. Ниту едно од трите не дава привилегија на портата ниту го менува тоа што серверот мисли за вашата лозинка.
Кога барателот е клиент што штотуку се ажурирал, повторното одобрување е очекувано: новата верзија веќе не одговара на списокот за контрола на пристап на ставката, па macOS повторно прашува. Одговорете Дозволи еднаш додека дијагностицирате. Секогаш дозволи е трајна дозвола за таа апликација и погрешен одговор за помошен процес што не сте го очекувале; одбијте и проверете кај добавувачот ако бинарната датотека не е клиентот што сте го инсталирале.
Барањето за администраторско овластување е трет вид. Именува системско поставување или заштитено складиште што се менува, а акредитивот што го бара е администраторска сметка на овој Mac. Не секоја лична ставка на приврзокот со клучеви го бара тоа; оние зад мрежната конфигурација обично го бараат, бидејќи конфигурацијата му припаѓа на системот, не на вашата сесија за најава.
Каде може да живее VPN лозинка на Mac
Приврзокот со клучеви е едно можно складиште, не дефиниција на складиште. Вградена VPN конфигурација создадена во Системски поставувања ги чува акредитивите со мрежната конфигурација, како управувано системско поставување. Клиент од трета страна обично чува ставка во вашиот приврзок со клучеви за најава: општа лозинка со клуч по име на услуга или интернет лозинка со клуч по сервер, протокол и сметка. Многу понови апликации наместо тоа го користат приврзокот со клучеви за заштита на податоци, чии ставки никогаш не се појавуваат во Пристап до приврзокот со клучеви.
Луѓето го бараат името на VPN во Пристап до приврзокот со клучеви, не наоѓаат ништо и заклучуваат дека лозинката не е зачувана. Белешката TN3137 на Apple вели дека постои повеќе од една имплементација на приврзок со клучеви; отсуството од тој список е нормално, не доказ за расипана ставка.
Ни видовите записи не се заменливи. Лозинка на сметка, лозинка на приватен клуч, клиентски сертификат и заедничка тајна на IPsec не успеваат различно и се поправаат на различни места; повторното внесување на зачувана лозинка не прави ништо за одбиен сертификат. Ако Mac е запишан во управување, профилот е уште еден сопственик: VPN товарот може да носи акредитиви и повторно да ги применува при освежување, па бришењето локална ставка е привремено додека администраторот не го смени.
Кога лозинката за најава и лозинката на приврзокот со клучеви се разидуваат
Приврзокот со клучеви за најава обично ја користи вашата лозинка за најава на Mac, затоа двете можат да се разидуваат. Администратор што ја ресетира вашата лозинка од друга сметка, процес за обновување или промена во именикот можат да го остават приврзокот заклучен на старата вредност, и тогаш macOS бара лозинка што штотуку не сте ја поставиле.
При најава може да видите предупредување дека системот не можел да го отклучи приврзокот со клучеви. Ажурирањето бара стара лозинка, што е добро ако ја помните и бескорисно ако не. Двете чесни поправки се Пристап до приврзокот со клучеви, Уреди, Промени лозинка за приврзок со клучеви "login", или нов приврзок со клучеви за најава со повторно внесени потребни акредитиви. Втората опција ги уништува зачуваните ставки.
Не ресетирајте го целиот приврзок со клучеви затоа што еден VPN одбива стари акредитиви: тоа отстранува неповрзани сметки и понатаму не ја идентификува ставката.
Една команда го решава прашањето локално наспроти далечно. Побарајте ја ставката директно од приврзокот со клучеви:
security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -gКористете го серверот и сметката од поставувањата на вашиот клиент. Ако истиот лист за одобрување се појави кога самите го прашувате приврзокот со клучеви, барањето е локално и серверот е набљудувач. Ако таква ставка не постои, клиентот не ја чува лозинката каде што претпоставивте. Знамето -g ја печати тајната во терминалот, затоа избегнувајте споделување екран.
Ажурирајте го записот што клиентот навистина го чита
Ако сметката се сменила на портата, сменете ја прво таму, потоа ажурирајте го зачуваниот запис преку поставувањата на клиентот. Рачното уредување на ставка од приврзокот со клучеви е несигурно: клиентот може да чита друг пар услуга и сметка, а управуваниот профил ќе го пребрише вашето уредување.
За ставка осомничена како застарена, усогласете услуга, сметка и протокол пред да избришете нешто:
security delete-generic-password -s "Client Name" -a [email protected]Бришењето на слично именувана ставка од друга врска е чест самонанесен прекин. Отстранувањето е само локално: тоа не отповикува сесија на портата, не откачува сертификат на уред и не ја менува лозинката на сметката.
Потврдете дека поправката преживува рестарт
Поврзете се, разбудете се од спиење, одјавете се и повторно најавете се, па рестартирајте еднаш. Чиста секвенца без лист и статус на клиентот што ја именува очекуваната сметка се единствениот доказ што се смета. Каде барањето се враќа ви кажува кој слој сте го пропуштиле: по ажурирање тоа е одобрувањето, по промена на мрежа сопственото барање на клиентот, по рестарт профил што повторно применува состојба.
Проверете го клиентот за поставување запомни лозинка или секогаш прашај пред повторно да го допрете приврзокот со клучеви. Некои конфигурации, особено IKEv2 со автентикација по корисник, прашуваат по дизајн при секое поврзување; поправката на приврзокот нема да помогне.
Запишете која ставка сте ја смениле, кое складиште ја поседувало и на која сметка припаѓала, за следното барање да се лоцира за секунди. Страницата на Apple Барања за пристап до приврзокот со клучеви е референца за тоа што ги овластуваат тие три копчиња.