Kvifor Mac-VPN-en din ber om Keychain-tilgang kvar gong

Eitt klikk på Connect skal gje eitt påloggingsvindauge. På ein Mac gjev det ofte tre, og dei deler sjeldan eigar: nøkkelringen eig dei lokale førespurnadene om påloggingsinformasjon, VPN-gatewayen eig autentiseringa, og klienten eig sine eigne varsel. I staden for å leite etter ein brytar som får alt til å teie, handsam kvart vindauge som ein eigen feil med si eiga løysing. Vegleiinga nedanfor går gjennom eitt medvite tilkopingsforsøk og endar med ein kontroll du kan gjenta.

Namngje eigaren av kvar dialog før du endrar ei innstilling

Det første steget er bokføring, ikkje konfigurasjon. Gjer eitt tilkopingsforsøk, og for kvart vindauge som dukkar opp, skriv ned fire felt: appnamnet i dialogen, den nøyaktige teksten utan noko hemmeleg, fasen det dukka opp i, og kva som skjedde då du avbraut det. Tre slike rader dekkjer nesten kvar rapport eg har sett på.

Eigarskap avgjer rett løysing, og feil løysing er vanlegvis det som gjer éin førespurnad til tre:

Ein førespurnad som kjem tilbake i same forsøk, er eit anna signal enn ein som kjem tilbake ved neste forsøk. Den første tyder vanlegvis at tilkoplinga vart starta på nytt under deg; den andre tyder vanlegvis at lagra påloggingsinformasjon vert spurd om igjen. Noter kva du har før du rører nøkkelringen, for dei to har nesten ingenting til felles.

Finn ut kor mange ting som startar tunnelen

Fire mekanismar kan starte same VPN på ein Mac: ei menylinjehandling, eit påloggingselement, ein On Demand-regel og eit skript eller ein agent. Når to av dei utløysast, kan den andre starten kome medan den første framleis ventar på autentisering, noko som gjev eit dobbelt vindauge og ingen framgang. List først opp kva som er konfigurert: scutil --nc list skriv ut VPN-tenestene Systeminnstillingar kjenner, med gjeldande status. Klientar som leverer si eiga nettverksutviding held profilar inne i appen og vert kanskje ikkje viste der, så sjekk også klienten si eiga tilkopingsliste.

Sjå deretter etter konkurrerande startarar. scutil --nc show "Work VPN" skriv ut konfigurasjonsordboka til ei innebygd teneste, inkludert On Demand-reglar; ein regel som koplar til på nytt ved kvar grensesnittendring, startar tunnelen på nytt — og opnar autentiseringsførespurnaden igjen — kvar gong Wi-Fi flyttar seg eller ein skjerm vekkjer nettverksstakken. Sjekk påloggingselement under Systeminnstillingar > Generelt > Påloggingselement, og list agentar per brukar med ls ~/Library/LaunchAgents. Lat alt som er eigd av ein MDM-styrt tryggleiksstakk vere i fred; fjerning vert vanlegvis dytta tilbake ved neste sjekk.

For å sjå kva som faktisk køyrer under eit forsøk: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. To klienthjelparar der du ventar éin forklarer "kvifor fekk eg to førespurnader" langt oftare enn noko påloggingsproblem.

Reparer nøkkelringtilgang utan å nullstilla nøkkelringen

Førespurnaden kjem frå tilgangskontrollista til den lagra posten, ikkje frå VPN-protokollen. Kvar post registrerer kva program som kan lese han utan å spørje. Etter ein klientoppdatering kan hjelparen som spør, ha eit anna namn eller ei anna signatur medan posten framleis listar opp den gamle, så macOS spør igjen ved kvar tilkopling. Å godkjenne den nye hjelparen for nettopp den posten er heile løysinga; å godkjenne kvart program er det ikkje.

Du kan stadfeste at ACL er årsaka utan å røre VPN-en: security find-generic-password -s "service-name" -g les den same posten frå ein terminal. Viss den kommandoen også utløyser førespurnaden, høyrer dialogen til nøkkelringen og tunnelen er berre utløysaren. Apples rettleiing om dei tre knappane — Tillat éin gong, Tillat alltid, Avvis — er verd éi lesing, fordi Avvis er det som får førespurnaden til å kome tilbake med ein gong i staden for ved neste forsøk.

Viss du godkjende feil hjelpar, opne posten i Nøkkelringtilgang, byt til Tilgangskontroll og fjern den posten; det er tilbakerullinga. Sletting av påloggingsnøkkelringen, eller køyring av eit reparasjonsverktøy som byggjer han opp igjen, kastar også bort urelaterte passord og er ei mykje større endring enn problemet.

Hald påloggings- og policysteg i flyta som eig dei

Ei nettlesarpålogging eller MFA-utfordring høyrer til gatewayen. Viss organisasjonen din tilbyr sesjonsvedvaring eller sertifikatbasert autentisering, bruk det, fordi det er den støtta måten å autentisere sjeldnare på. Å skrive inn ein fast kode i ein klient, eller lagre eit passord i eit skript slik at førespurnaden aldri vert vist, byter ut ein interaktiv faktor med ein statisk løyndom og feilar neste gong policyen vert rotert.

Organisasjonsvarsel er den eine kategorien du ikkje bør undertrykkje. Dei handhevar vanlegvis ein tilstandssjekk eller ei stadfesting av akseptabel bruk, og å skjule dei kan setje eininga ut av samsvar sjølv medan tunnelen fungerer. Feildialogar er den andre kategorien: ta vare på den første feilteksten, fordi ein andre dialog ofte berre er same feil rapportert etter eit nytt forsøk.

Stadfest med eitt forsøk, deretter etter ein omstart

Med doble startarar fjerna og nøkkelringposten reparert, gjer eitt enkelt forsøk: avslutt kvar klientinstans inkludert menylinjehjelparen, kople til éin gong, og tel vindauga. Du vil ha nøkkelringgodkjenninga, viss posten vart bygd opp igjen, og eitt autentiseringstrinn. Ikkje noko meir. scutil --nc status "Work VPN" bør rapportere Connected for ei innebygd teneste.

Start deretter om éin gong og gjenta. Ein førespurnad som berre kjem tilbake etter ein omstart, peikar på eit påloggingselement eller ein On Demand-regel, ikkje på påloggingsinformasjon; ein som kjem tilbake i økta, peikar på ACL eller på ein andre startar. Viss han framleis gjentek seg etter begge gjennomgangane, er det nyttige å gje administratoren din tabellen med tre rader frå det første forsøket — eigar, nøyaktig tekst, fase — ikkje eit skjermbilete av dialogen.

Færre førespurnader er målet, ikkje tause. Ei tilkopling som skjuler autorisasjonstrinna sine, er ei tilkopling du ikkje lenger kan revidere, og den neste sertifikatrotasjonen vil finne deg utan aning om kva komponent som feilar.