Mac VPN-bejelentkezés tanúsítvánnyal: identitás, kulcshasználat vagy átjáró-bizalom?
Három döntés áll a tanúsítványos bejelentkezés mögött: melyik identitást választja a rendszer, használhatja-e a VPN-összetevő a kulcsát, és megbízható-e az átjáró.
A tanúsítványalapú VPN-bejelentkezés szűkebb dolgot kér a Mactől, mint egy jelszót: ezt a konkrét titkos kulcsot használd, ebben a végrehajtási környezetben, hogy identitást bizonyíts annak az átjárónak. Amikor kudarcot vall, az üzenet általában csak az utolsó hibás lépést írja le, ami ritkán az okozója. A három döntés rendszer által követett sorrendjében való végigjárása őszintén tartja a diagnózist, és megakadályozza, hogy egy helyi engedélyproblémát láncérvényesítési hibaként kezeljünk.
Járjuk végig a bejelentkezést abban a sorrendben, ahogy a Mac teszi
Először az ügyfél identitást választ: egy használható titkos kulcshoz párosított tanúsítvány, amely a támogatott tárolón vagy hitelesítőadat-szolgáltatón keresztül érhető el. Ezután a VPN-összetevő kriptográfiai műveletet kér azzal a kulccsal, és a helyi jogosultsági modell válaszol. Csak ha mindkettő sikerül, történik meg a távoli kézfogás, ahol a Mac értékeli az átjárót, az átjáró pedig az ügyfél bizonyítékát.
| 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 |
Olvassuk a táblázatot fentről lefelé, és álljunk meg az első hibás sornál. A hiba alatti minden bizonyítatlan, ezért olyan gyakori és olyan megbízhatatlan következtetés, hogy „a tanúsítvány nem megbízható”.
Mit fed le valójában a helyi engedély
A macOS kulcskarikájának modelljében a védett elemek műveletspecifikus hozzáférési szabályokat és megbízható alkalmazások listáját hordozzák. A titkos kulccsal való aláírás egy ilyen művelet, és a szabályok arra a futtatható fájlra vonatkoznak, amely elvégzi, nem a tanúsítványra mint dokumentumra. Az Apple hozzáférés-vezérlési referenciája határt húz e modell, valamint az iCloud-kulcskarika és a hozzáférési csoportok elrendezése között is, ezért az egyikhez írt tanács nem vihető át a másikra.
Két következmény adódik. Egy nyilvános tanúsítvány listán való láthatósága nem bizonyítja, hogy a VPN háttér-összetevője egyáltalán elérheti azt a kulcsot. Az pedig, hogy egy előtér-alkalmazás engedélyt kapott, semmit sem mond egy külön segédről vagy hálózati kiterjesztésről, mert azok más kód, más identitással.
A tényleges megvalósítást és annak támogatott hitelesítőadat-megosztási mechanizmusát azonosítsuk, ahelyett hogy egy régi ügyfélből másolnánk ki egy futtatható fájl elérési útját. Először erősítsük meg, melyik identitást fogja a rendszer egyáltalán felajánlani:
security find-identity -v -p ssl-clienterrSecInteractionNotAllowed olvasása
Ez az állapot a Security Serverrel folytatott, nem engedélyezett interakciót jelenti, és semmit sem mond a tanúsítványláncokról. Azzal a művelettel együtt olvassuk, amely létrehozta: egy olyan környezetből kiadott aláírási kérés, amely nem tud felugró ablakot mutatni, így fog megbukni akkor is, ha a kulcs és a tanúsítvány egyaránt tökéletesen érvényes. A kiindulópont az a művelet, amely naplózta, nem a tanúsítványtároló. A bizalmi horgonyokon eszközölt bármilyen változtatás pontosan ott hagyja a hibát, ahol volt.
Tehát a kódot okként kezeljük a végrehajtási környezet és a jogosultság vizsgálatára. Ha bizonyítéknak tekintjük arra, hogy az átjáró CA-ja nem megbízható, a probléma rossz felére jutunk, és az ott tett változtatás egyáltalán nem hat a hibára.
Szűken javítsunk, ne tágan
Kezdjük a kapcsolat tulajdonosának regisztrációs vagy importálási utasításaival. Rögzítsük az ügyfél verzióját, a profil hatókörét, a választott identitást és az első releváns helyi hibát, mert ez a négy tény az, amire egy támogatási átadásnak szüksége van, és amitől egy későbbi összehasonlítás függ. Egy felügyelt profil vagy hardverrel támogatott identitás megkövetelheti, hogy a rendszergazda vagy a szolgáltató javítsa az átadást, és ezt semmilyen mennyiségű helyi kattintás nem pótolja.
Ahol a termék felhasználói jóváhagyást vár, ellenőrizzük, melyik összetevő kéri, és csak azt a hozzáférést hagyjuk jóvá a támogatott folyamaton keresztül. Ahol az összetevőnek nincs módja felugró ablakot kérni abban a környezetben, amelyben fut, az előkészítésnek a gyártó által dokumentált útvonalat kell követnie, nem egy másik terminálablakból kicsalt párbeszédablakot.
Két változtatást szokás együtt javasolni a régi tanácsokban, és mindkettő túl tág. Ha minden alkalmazás hozzáférhet a titkos kulcshoz, a helyi kulcshasználat jóval túllépi a követelményt, a tanúsítvány Always Trust értékre állítása pedig mindenre megváltoztatja a tanúsítványértékelést a gépen. Egyik sem fejezi ki azt, hogy „ez a jóváhagyott VPN-megvalósítás, ezzel a szándékolt identitással”.
Helyben ellenőrizzünk, mielőtt az átjárót olvassuk
Javítás után erősítsük meg, hogy a helyi művelet sikerül mielőtt bármilyen választ értelmeznénk a túloldalról. Ha az aláírás most működik, egy későbbi név-, lánc- vagy ügyfél-belépési elutasítás új eredmény, nem visszatérés, és egy másik döntéshez tartozik, más felelőssel.
Egy hasznos átadás megnevezi, melyik három döntés bukott meg, és ott megáll. Soha nem tartalmazza a titkos kulcsot, és soha nem állít vissza nem kapcsolódó kulcskarika-elemeket abban a reményben, hogy egy tiszta lap segít. Ezt a két szokást a incidens előtt alakítsuk ki, ne közben, amikor a legerősebb a kísértés, hogy mindent egyszerre próbáljunk ki. Egy jegy, amely azt mondja, „újraépítettük a kulcskarikát”, szinte semmit sem mond a következő olvasónak az eredeti hibáról.