Macin VPN-kirjautuminen varmenteella: identiteetti, avaimen käyttö vai yhdyskäytävän luottamus?
Varmenteella kirjautumisen takana on kolme päätöstä: mikä identiteetti valitaan, saako VPN-komponentti käyttää avaintaan ja luotetaanko yhdyskäytävään.
Varmenteeseen perustuvat VPN-kirjautumiset pyytävät Macilta kapeampaa asiaa kuin salasanaa: käytä tätä tiettyä yksityistä avainta tässä suoritusympäristössä identiteetin todistamiseksi tuolle yhdyskäytävälle. Kun se epäonnistuu, viesti kuvaa yleensä vain viimeisen pieleen menneen asian, joka on harvoin syy. Kolmen päätöksen läpikäyminen siinä järjestyksessä, jossa järjestelmä ne tekee, pitää diagnoosin rehellisenä ja estää paikallisen käyttöoikeusongelman käsittelyn ketjun validoinnin epäonnistumisena.
Käy kirjautuminen läpi samassa järjestyksessä kuin Mac
Ensin asiakas valitsee identiteetin: käyttökelpoisella yksityisellä avaimella varustettu varmenne, joka on saatavilla tuetusta säilöstä tai tunnistetietojen tarjoajasta. Sitten VPN-komponentti pyytää salaustoimituksen tekemistä kyseisellä avaimella, ja paikallinen valtuutusmalli vastaa. Vasta kun molemmat onnistuvat, tapahtuu etäkättely, jossa Mac arvioi yhdyskäytävää ja yhdyskäytävä arvioi asiakkaan todisteen.
| 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 |
Lue taulukko ylhäältä alas ja pysähdy ensimmäiselle riville, joka epäonnistuu. Kaikki epäonnistumisen alapuolella on todistamatonta, minkä vuoksi «varmenne ei ole luotettu» on niin yleinen ja niin epäluotettava johtopäätös.
Mitä paikallinen käyttöoikeus todella kattaa
macOS:n avainnipun mallissa suojatut kohteet kantavat toimintokohtaisia käyttösääntöjä ja luotettujen sovellusten luetteloa. Yksityisellä avaimella allekirjoittaminen on yksi näistä toiminnoista, ja säännöt koskevat sitä suorittavaa suoritettavaa tiedostoa, eivät varmennetta asiakirjana. Applen käyttöoikeuksien hallinnan viite vetää myös rajan tämän mallin sekä iCloud-avainnipun ja käyttöoikeusryhmäjärjestelyjen välille, joten toiselle kirjoitettu neuvo ei siirry toiselle.
Tästä seuraa kaksi asiaa. Julkisen varmenteen näkyminen luettelossa ei todista, että VPN:n taustakomponentti pääsee kyseiseen avaimeen lainkaan. Ja etuosassa toimivalle sovellukselle myönnetty käyttöoikeus ei kerro mitään erillisestä apurista tai verkkolaajennuksesta, koska ne ovat eri koodia eri identiteeteillä.
Tunnista todellinen toteutus ja sen tuettu tunnistetietojen jakamismekanismi sen sijaan, että kopioisit suoritettavan tiedoston polun vanhasta asiakkaasta. Vahvista, minkä identiteetin järjestelmä ylipäätään tarjoaa:
security find-identity -v -p ssl-clientKoodin errSecInteractionNotAllowed lukeminen
Tuo tila ilmoittaa kielletystä vuorovaikutuksesta turvapalvelimen kanssa eikä kerro mitään varmenneketjuista. Lue se yhdessä sen aiheuttaneen toiminnon kanssa: kehotteita näyttämättömästä ympäristöstä lähetetty allekirjoituspyyntö epäonnistuu tällä tavalla, vaikka avain ja varmenne olisivat molemmat täysin kelvollisia. Aloituspaikka on se toiminto, joka kirjasi sen, ei varmennevarasto. Kaikki muutokset luottamusankkureihin jättävät virheen täsmälleen sinne, missä se oli.
Kohtele siis koodia syynä tutkia suoritusympäristöä ja valtuutusta. Sen pitäminen todisteena siitä, että yhdyskäytävän CA ei ole luotettu, lähettää sinut ongelman väärälle puoliskolle, eikä siellä tekemäsi muutos vaikuta virheeseen lainkaan.
Korjaa kapeasti, ei laajasti
Aloita yhteyden omistajan rekisteröinti- tai tuontiohjeista. Kirjaa asiakasversio, profiilin laajuus, valittu identiteetti ja ensimmäinen merkityksellinen paikallinen virhe, koska juuri nämä neljä seikkaa tukipalveluun siirto tarvitsee ja niistä myöhempi vertailu riippuu. Hallittu profiili tai laitteistopohjainen identiteetti voi edellyttää, että ylläpitäjä tai palveluntarjoaja korjaa siirron, eikä mikään paikallinen napsauttelu korvaa sitä.
Missä tuote odottaa käyttäjän hyväksyntää, vahvista mikä komponentti sitä pyytää ja hyväksy vain kyseinen käyttöoikeus tuetun kulun kautta. Missä komponentti ei voi nostaa kehotetta ympäristössä, jossa se toimii, valmistelun on seurattava toimittajan dokumentoimaa reittiä, ei toisesta pääteikkunasta houkuteltua valintaikkunaa.
Vanhemmissa neuvoissa kaksi muutosta niputetaan yhteen, ja molemmat ovat liian laajoja. Yksityisen avaimen käyttöoikeuden antaminen jokaiselle sovellukselle laajentaa paikallista avaimen käyttöä paljon vaatimusta pidemmälle, ja varmenteen asettaminen aina luotetuksi muuttaa varmenteiden arviointia kaikelle koneella. Kumpikaan ei ilmaise «tätä hyväksyttyä VPN-toteutusta tällä aiotulla identiteetillä».
Tarkista paikallisesti ennen yhdyskäytävän lukemista
Vahvista korjauksen jälkeen, että paikallinen toiminto onnistuu, ennen kuin tulkitset mitään vastausta toiselta puolelta. Jos allekirjoittaminen nyt toimii, myöhempi nimen, ketjun tai asiakkaan hyväksynnän hylkäys on uusi tulos eikä toistuma, ja se kuuluu toiseen päätökseen toisella omistajalla.
Hyödyllinen siirto nimeää, mikä kolmesta päätöksestä epäonnistui, ja pysähtyy siihen. Se ei koskaan sisällä yksityistä avainta eikä koskaan palauta aiheeseen liittymättömiä avainnipun kohteita toiveena, että puhdas tila auttaisi. Vakiinnuta ne kaksi tapaa ennen tapahtumaa eikä sen aikana, jolloin kiusaus kokeilla kaikkea kerralla on voimakkain. Tiketti, joka sanoo «rakensimme avainnipun uudelleen», ei kerro seuraavalle lukijalle alkuperäisestä viasta juuri mitään.