VPN prisijungimas su sertifikatu Mac kompiuteryje: tapatybė, rakto naudojimas ar šliuzo pasitikėjimas?
Už prisijungimo su sertifikatu slypi trys sprendimai: kuri tapatybė pasirenkama, ar VPN komponentas gali naudoti savo raktą ir ar šliuzu pasitikima.
Prisijungimai prie VPN su sertifikatu prašo Mac kompiuterio kažko siauresnio nei slaptažodis: naudoti šį konkretų privatų raktą šiame vykdymo kontekste, kad tapatybė būtų įrodyta tam šliuzui. Kai nepavyksta, pranešimas paprastai aprašo tik paskutinį dalyką, kuris nuėjo ne taip, o jis retai būna priežastis. Trijų sprendimų peržiūra tokia tvarka, kokia juos priima sistema, išlaiko diagnozę sąžiningą ir neleidžia vietinės leidimų problemos traktuoti kaip grandinės patikrinimo nesėkmės.
Pereikite prisijungimą tokia tvarka, kokia jį atlieka Mac
Pirmiausia klientas pasirenka tapatybę: sertifikatas, suporuotas su tinkamu privačiu raktu, prieinamas per palaikomą saugyklą arba prisijungimo duomenų teikėją. Tada VPN komponentas paprašo atlikti kriptografinę operaciją tuo raktu, o vietinis autorizacijos modelis atsako. Tik po to, kai abu pavyksta, įvyksta nuotolinis rankos paspaudimas, kuriame Mac įvertina šliuzą, o šliuzas įvertina kliento įrodymą.
| 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 |
Skaitykite lentelę iš viršaus į apačią ir sustokite ties pirmąja nepavykusia eilute. Viskas žemiau nesėkmės neįrodyta, todėl „sertifikatu nepasitikima“ yra tokia dažna ir tokia nepatikima išvada.
Ką iš tikrųjų apima vietinis leidimas
macOS raktinės modelio atveju apsaugoti elementai turi konkrečiai operacijai skirtas prieigos taisykles ir patikimų programų sąrašą. Pasirašymas privačiu raktu yra viena iš tokių operacijų, o taisyklės taikomos ją atliekančiam vykdomajam failui, o ne sertifikatui kaip dokumentui. Apple prieigos kontrolės žinynas taip pat brėžia ribą tarp šio modelio ir iCloud raktinės bei prieigos grupių, todėl vienam skirtas patarimas neperkeliamas kitam.
Iš to kyla dvi pasekmės. Tai, kad viešas sertifikatas matomas sąraše, neįrodo, kad VPN foninė komponentė apskritai gali pasiekti tą raktą. O priekinei programai suteiktas leidimas nieko nesako apie atskirą pagalbininką ar tinklo plėtinį, nes tai kitas kodas su kitomis tapatybėmis.
Nustatykite tikrąją įgyvendinimo formą ir jo palaikomą prisijungimo duomenų bendrinimo mechanizmą, o ne kopijuokite vykdomojo failo kelią iš seno kliento. Pirmiausia patvirtinkite, kokią tapatybę sistema apskritai pasiūlys:
security find-identity -v -p ssl-clientKaip skaityti errSecInteractionNotAllowed
Ši būsena praneša apie neleistiną sąveiką su Security Server ir nieko nesako apie sertifikatų grandines. Skaitykite ją kartu su operacija, kuri ją sukėlė: pasirašymo užklausa, išsiųsta iš konteksto, kuris negali parodyti dialogo, nepavyks būtent taip, net kai raktas ir sertifikatas abu visiškai galioja. Pradėti reikia nuo operacijos, kuri ją užregistravo, o ne nuo sertifikatų saugyklos. Bet kokie pasitikėjimo inkaro pakeitimai paliks klaidą lygiai ten, kur ji buvo.
Taigi traktuokite kodą kaip priežastį ištirti vykdymo kontekstą ir autorizaciją. Traktuojant jį kaip įrodymą, kad šliuzo CA nepatikimas, nukreipiama į neteisingą problemos pusę, o ten atliktas pakeitimas klaidai visiškai nepaveiks.
Taisykite siaurai, o ne plačiai
Pradėkite nuo ryšio savininko registracijos arba importavimo instrukcijų. Užrašykite kliento versiją, profilio aprėptį, pasirinktą tapatybę ir pirmą svarbią vietinę klaidą, nes būtent šie keturi faktai reikalingi perdavimui paramai ir nuo jų priklauso vėlesnis palyginimas. Valdomas profilis arba aparatūra pagrįsta tapatybė gali reikalauti, kad administratorius arba teikėjas sutvarkytų perdavimą, ir joks vietinių paspaudimų kiekis to nepakeis.
Kai produktas tikisi vartotojo patvirtinimo, patikrinkite, kuri komponentė to prašo, ir patvirtinkite tik tą prieigą palaikomu srautu. Kai komponentė negali iškelti dialogo tame kontekste, kuriame veikia, aprūpinimas turi eiti dokumentuotu tiekėjo keliu, o ne dialogu, ištrauktu iš kitokio terminalo lango.
Senuose patarimuose du pakeitimai pateikiami kartu, ir abu yra per platūs. Suteikus kiekvienai programai prieigą prie privataus rakto, vietinis rakto naudojimas išplinta kur kas plačiau nei reikalavimas, o nustačius sertifikatą į Always Trust, pasikeičia sertifikatų vertinimas viskam kompiuteryje. Nė vienas jų neišreiškia „šio patvirtinto VPN įgyvendinimo, naudojančio šią numatytą tapatybę“.
Patikrinkite vietoje, prieš skaitydami šliuzą
Po taisymo patvirtinkite, kad vietinė operacija pavyksta prieš interpretuodami bet kokį atsakymą iš kitos pusės. Jei pasirašymas dabar veikia, vėlesnis vardo, grandinės ar kliento priėmimo atmetimas yra naujas rezultatas, o ne pasikartojimas, ir jis priklauso kitam sprendimui su kitu atsakinguoju.
Naudingas perdavimas įvardija, kuris iš trijų sprendimų nepavyko, ir ten sustoja. Jame niekada nėra privataus rakto, ir jis niekada neatstato nesusijusių raktinės elementų, tikėdamasis, kad švari pradžia padės. Šiuos du įpročius nustatykite prieš incidentą, o ne jo metu, kai pagunda išbandyti viską iš karto yra stipriausia. Bilietas su užrašu „raktinė perkurta“ beveik nieko nepasako kitam skaitytojui apie pirminį gedimą.