Уваход у VPN на Mac праз сертыфікат: ідэнтычнасць, выкарыстанне ключа ці давер да шлюза?
За ўваходам па сертыфікаце стаяць тры рашэнні: якая ідэнтычнасць выбіраецца, ці можа кампанент VPN выкарыстоўваць свой ключ і ці давяраць шлюзу.
Уваходы ў VPN на аснове сертыфікатаў патрабуюць ад Mac чагосьці вузейшага за пароль: выкарыстаць гэты канкрэтны прыватны ключ, у гэтым кантэксце выканання, каб даказаць ідэнтычнасць таму шлюзу. Калі гэта не ўдаецца, паведамленне звычайна апісвае толькі апошняе, што пайшло не так, а гэта рэдка з'яўляецца прычынай. Праходжанне трох рашэнняў у тым парадку, у якім іх прымае сістэма, трымае дыягностыку сумленнай і не дазваляе ўспрымаць лакальную праблему правоў як збой праверкі ланцуга.
Прайдзіце ўваход у тым парадку, у якім гэта робіць Mac
Спачатку кліент выбірае ідэнтычнасць: сертыфікат у пары з прыдатным прыватным ключом, даступны праз падтрымліванае сховішча або пастаўшчыка ўліковых даных. Затым кампанент VPN просіць выканаць крыптаграфічную аперацыю з гэтым ключом, і лакальная мадэль аўтарызацыі адказвае. Толькі пасля поспеху абодвух адбываецца аддаленае рукапацісканне, дзе Mac ацэньвае шлюз, а шлюз ацэньвае доказ кліента.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Чытайце табліцу зверху ўніз і спыніцеся на першым радку, які не праходзіць. Усё ніжэй за збой не даказана, таму «сертыфікат не давераны» — такая распаўсюджаная і такая ненадзейная выснова.
Што насамрэч пакрывае лакальны дазвол
У мадэлі звязкі ключоў macOS абароненыя элементы нясуць правілы доступу, спецыфічныя для аперацыі, і спіс давераных праграм. Подпіс прыватным ключом — адна з такіх аперацый, і правілы датычаць выканальнага файла, які яе выконвае, а не сертыфіката як дакумента. Даведачнік Apple па кантролі доступу таксама праводзіць мяжу паміж гэтай мадэллю і звязкай ключоў iCloud ды схемамі груп доступу, таму парада, напісаная для аднаго, не пераносіцца на другое.
Адсюль вынікаюць два следствы. Бачнасць публічнага сертыфіката ў спісе не даказвае, што фонавы кампанент VPN наогул можа дабрацца да гэтага ключа. І дазвол, выдадзены прыкладанню інтэрфейсу, нічога не кажа пра асобны памочнік або пашырэнне сеткі, бо гэта розны код з рознымі ідэнтычнасцямі.
Вызначце фактычную рэалізацыю і яе падтрымліваемы механізм сумеснага выкарыстання ўліковых даных замест капіявання шляху выканальнага файла са старога кліента. Пацвердзіце, якую ідэнтычнасць сістэма прапануе ў першую чаргу:
security find-identity -v -p ssl-clientЧытанне кода errSecInteractionNotAllowed
Гэты статус паведамляе пра забароненнае ўзаемадзеянне з Серверам бяспекі і нічога не кажа пра ланцугі сертыфікатаў. Чытайце яго разам з аперацыяй, якая яго выклікала: запыт на подпіс з кантэксту, які не можа паказаць запрашэнне, скончыцца менавіта так, нават калі ключ і сертыфікат абсалютна сапраўдныя. Пачынаць трэба з аперацыі, якая гэта зафіксавала, а не са сховішча сертыфікатаў. Любое змяненне якароў даверу пакіне памылку роўна там, дзе яна была.
Таму ўспрымайце код як прычыну даследаваць кантэкст выканання і аўтарызацыю. Калі ж успрымаць яго як доказ недаверу да CA шлюза, вы трапіце ў няправільную палову праблемы, і змяненне, зробленае там, зусім не паўплывае на памылку.
Рамантуйце вузка, а не шырока
Пачніце з інструкцый уладальніка злучэння па рэгістрацыі або імпарце. Запішыце версію кліента, абсяг профілю, выбраныя ідэнтычнасць і першую значную лакальную памылку, бо менавіта гэтыя чатыры факты патрэбныя для перадачы ў падтрымку і ад іх залежыць наступнае параўнанне. Кіраваны профіль або ідэнтычнасць з апаратнай падтрымкай могуць патрабаваць, каб перадачу выправіў адміністратар або пастаўшчык, і ніякая колькасць лакальных пстрычак гэтага не замяняе.
Там, дзе прадукт чакае згоды карыстальніка, пацвердзіце, які кампанент просіць, і ўхваліце толькі гэты доступ праз падтрымліваемы працэс. Там, дзе кампанент не можа паказаць запыт у кантэксце, у якім ён працуе, забеспячэнне павінна ісці шляхам, які дакументуе пастаўшчык, а не праз дыялог, выцягнуты з нейкага іншага тэрмінальнага акна.
У старых парадах дзве змены ідуць разам, і абедзве занадта шырокія. Дазвол усім праграмам доступу да прыватнага ключа пашырае лакальнае выкарыстанне ключа далёка за межы патрабавання, а налада сертыфіката «Заўсёды давяраць» змяняе ацэнку сертыфікатаў для ўсяго на машыне. Ні адна з іх не выражае «гэтая ўхваленая рэалізацыя VPN з гэтай мэтавай ідэнтычнасцю».
Праверце лакальна, перш чым чытаць шлюз
Пасля рамонту пацвердзіце, што лакальная аперацыя ўдаецца, перш чым тлумачыць любы адказ з іншага боку. Калі подпіс цяпер працуе, наступная адмова па імені, ланцугу або допуску кліента — гэта новы вынік, а не паўтор, і ён належыць да іншага рашэння з іншым уладальнікам.
Карысная перадача называе, якое з трох рашэнняў не ўдалося, і на гэтым спыняецца. Яна ніколі не ўключае прыватны ключ і ніколі не скідвае староннія элементы звязкі ключоў у надзеі, што чысты аркуш дапаможа. Завядзіце гэтыя дзве звычкі да інцыдэнту, а не падчас яго, калі спакуса паспрабаваць усё адразу наймацнейшая. Тыкет з надпісам «перабудавалі звязку ключоў» не паведамляе наступнаму чытачу амаль нічога пра першапачатковую няспраўнасць.