Administrert Mac VPN-profil let seg ikkje sletta? Sjekk desse fem trinna
Før du slettar ein administrert Mac VPN-profil, må du stadfesta kven som eig han, kva nyttelasta krev og kvifor fjerninga er blokkert, med fem kontrollar i rekkjefølgje.
Macen din held på ein VPN-profil som nektar å bli sletta, eller han blir sletta og kjem tilbake etter ein omstart. Dette er vanlegvis eit administrasjonsspørsmål, ikkje ein øydelagd klient. Kontrollane nedanfor går frå eigarskap til nyttelast til reglar for attoppkopling, og kvar av dei kan stoppa deg før du brukar ein ettermiddag i feil panel. Gjer dei i rekkjefølgje; trinnet der svaret endrar seg, er der din del sluttar.
Stadfest at profilen er administrert, ikkje berre lagra
Opne Systeminnstillingar og søk etter Profilar eller Einingadministrasjon. Avhengig av macOS-versjonen ligg lista under Personvern og tryggleik (Profilar) eller Generelt (Einingadministrasjon). Ein profil som viser eit organisasjonsnamn, ei kort skildring og ingen minusknapp, er installert av organisasjonen og ikkje lagt til av deg.
To kontrollar i terminalen avgjer eigarskapet raskt. Den første rapporterer registrering, den andre listar opp einingprofilar:
sudo profiles status -type enrollment
sudo profiles -PViss registreringa seier ja og profillista er tom, må du ikkje konkludera med at ingenting er installert. På administrerte Macar blir nokre MDM-leverte nyttelaster verande skjulte for verktøyet profiles medan dei framleis er aktive. Einingadministrasjonspanelet er den autoritative visninga av det organisasjonen har sendt ut, og ei tom kommandolinjeliste på ein registrert Mac er ei motseiing du ikkje bør løysa ved å gissa.
Les nyttelasta, ikkje visingsnamnet
Ein VPN-profil er ein behaldar, og det synlege namnet seier lite om kva som er inni. Ei nyttelast kan bera IKEv2-serveradressa, den eksterne identifikatoren, autentiseringsmetoden og eit sertifikat med eigen UUID. Ei anna nyttelast i same profil kan levera identitetssertifikatet tunnelen treng, og difor kan eit sertifikat som ser ut til å mangla i Keychain likevel koma gjennom same profil.
Dump nyttelastene og les nøklane som betyr noko:
sudo profiles show -type configuration | grep -A3 -E "VPNType|ServerAddress|RemoteAddress|AuthenticationMethod|PayloadUUID"Noter UUID-ane til nyttelastene før du endrar noko. Dei er identifikatorane ein administrator treng for å finna det nøyaktige objektet, og dei fortel deg òg om tunnelen og sertifikatet kjem frå same kjelde eller frå to ulike utrullingar.
Følg med på kva som bringar tunnelen tilbake
Viss tunnelen startar på nytt av seg sjølv, inneheld profilen nesten heilt sikkert ein regel på førespurnad. Ein regel som passar med kva som helst grensesnitt og handlinga Connect, startar tunnelen når Wi-Fi koplar til, når Macen vaknar frå dvale, eller når ein DNS-test mislukkast. Klienten tilbyr ikkje ein brytar som overstyrer nyttelasta.
Tenestelista og konfigurasjonen per teneste kjem frå scutil:
scutil --nc list
scutil --nc show "Corporate VPN"I show-utdataene finn du OnDemandRules og les Action-verdien for kvar oppføring. Connect reiser tunnelen, Disconnect river han ned, og Ignore lèt den noverande tilstanden vera. Ein første regel som passar med alt og har Connect, er den vanlege grunnen til at ein tunnel ikkje blir liggjande nede etter at du koplar frå.
Viss tilkoplinga manglar i scutil --nc list, er ho ikkje installert som ein system-VPN-teneste. Det peikar på ei nettverksutviding som ein klientapp eig, der profilen kanskje berre overleverer appkonfigurasjonen og appen sjølv avgjer når han skal kopla til.
Avgjer om fjerninga er di oppgåve
To mekanismar blokkerer sletting. Nyttelasta kan setja PayloadRemovalDisallowed, som gjer profilen ikkje-fjernbar i grensesnittet, og Macen kan vera under tilsyn slik at fjerning av administrasjonsprofilen blir avvist blankt. Ingen av dei er ein feil, og å sletta urelaterte sertifikat eller administrasjonsprofilen for å tvinga saka gjennom, lèt deg att med eit mykje større problem enn det du byrja med.
| What you see | Likely owner | Next action |
|---|---|---|
| Profile shows an organization name and no minus button | MDM enrollment | Ask the administrator to remove it or change its scope |
| Profile removable, personal IKEv2 settings | You | Remove it from VPN settings and re-add it if you still need it |
| Profile removed, returns after a reboot or check-in | MDM re-push | Request a scope change; deleting it again will not hold |
| Profile removed, tunnel still starts | On Demand rule or app login item | Remove the rule or the login item, then retry |
For ein arbeids-Mac er støtte- eller offboardingvegen til administratoren den rette. Ta med deg profilidentifikatoren. Ei sak som berre seier «VPN-profilen», er ikkje nok for nokon til å finna objektet du meiner.
Samle bevis før du ber om hjelp
Skriv ned fem ting: profilidentifikatoren, UUID-ane til nyttelastene, macOS-versjon og build frå sw_vers, VPN-undervejstypen og den nøyaktige feilteksten med tidsstempel. Legg til om tunnelen er full eller delt, og om han feilar ved tilkopling eller ved første tilgang til ein intern ressurs, sidan desse to feila har ulike eigarar.
For ein feil i ei nettverksutviding er éin smal loggførespurnad vanlegvis nok:
log show --last 5m --predicate 'process == "nesessionmanager"'Ta linjene rundt forsøket i staden for heile vindauget, og sladd servernamn og sertifikatsubjekt før du publiserer resultatet nokon stad. Utrullingsrettleiinga til Apple forklarar kva administrerte VPN-nyttelaster og reglar på førespurnad er meinte å gjera, og det er eit betre argument enn eit skjermbilete: Oversyn over VPN.
Når alle fem kontrollane er gjorde, er nøyaktig éin av tre ting sanne. Profilen er ikkje din å fjerna, nyttelasta koplar tunnelen til på nytt etter design, eller klienten har ein konfigurasjon som profilen aldri kontrollerte. Ta identifikatorane og tidslinja med til den som eig registreringa; det er ei sak nokon kan handle på. Å trykkja slett igjen er det ikkje.