Ĉu administrata Mac-VPN-profilo ne volas foriĝi? Kontrolu ĉi tiujn kvin paŝojn
Antaŭ ol vi forigos administratajn Mac-VPN-profitulon, konfirmu kiu posedas ĝin, kion la ŝarĝo trudas kaj kial forigo estas blokita, per kvin ordigitaj kontroloj.
Via Mac tenas VPN-profitulon, kiu rifuzas foriĝi, aŭ ĝi foriĝas kaj revenas post restarto. Tio kutime estas administra demando, ne difektita kliento. La subaj kontroloj iras de posedo al ŝarĝo al reguloj pri rekonekto, kaj ĉiu povas haltigi vin antaŭ ol vi pasigos posttagmezon en la malĝusta panelo. Faru ilin laŭ ordo; la paŝo, kie la respondo ŝanĝiĝas, estas kie via parto finiĝas.
Konfirmu, ke la profilo estas administrata, ne nur konservita
Malfermu Sistemajn Agordojn kaj serĉu Profiloj aŭ Administrado de Aparatoj. Laŭ la versio de macOS la listo troviĝas sub Privateco kaj Sekureco (Profiloj) aŭ Ĝenerala (Administrado de Aparatoj). Profilo, kiu montras organizan nomon, mallongan priskribon kaj neniun minusbutonon, estis instalita de la organizo, ne aldonita de vi.
Du kontroloj en la terminalo rapide solvas la posedon. La unua raportas aliĝon, la dua listigas aparatajn profilojn:
sudo profiles status -type enrollment
sudo profiles -PSe aliĝo diras jes kaj la profilolisto estas malplena, ne konkludu, ke nenio estas instalita. Sur administrataj Mac-oj kelkaj ŝarĝoj liveritaj de MDM restas kaŝitaj de la ilo profiles, dum ili restas aktivaj. La panelo Administrado de Aparatoj estas la aŭtoritata vidmaniero de tio, kion la organizo puŝis, kaj malplena komandlinia listo sur aliĝinta Mac estas kontraŭdiro, kiun vi ne devus solvi per divenado.
Legu la ŝarĝon, ne la vidigatan nomon
VPN-profilo estas ujo, kaj la vidigata nomo diras malmulte pri tio, kio estas interne. Unu ŝarĝo povas porti la IKEv2-servilan adreson, la foran identigilon, la aŭtentigan metodon kaj atestilon kun sia propra UUID. Dua ŝarĝo en la sama profilo povas liveri la identecan atestilon, kiun la tunelo bezonas, kaj tial atestilo, kiu ŝajnas manki en Keychain, tamen povas alveni per la sama profilo.
Elĵetu la ŝarĝojn kaj legu la ŝlosilojn, kiuj gravas:
sudo profiles show -type configuration | grep -A3 -E "VPNType|ServerAddress|RemoteAddress|AuthenticationMethod|PayloadUUID"Notu la UUID-ojn de la ŝarĝoj antaŭ ol vi ŝanĝos ion ajn. Ili estas la identigiloj, kiujn administranto bezonas por trovi la precizan objekton, kaj ili ankaŭ diras al vi, ĉu la tunelo kaj la atestilo venas el la sama fonto aŭ el du malsamaj deplojoj.
Atentu, kio revenigas la tunelon
Se la tunelo restartas per si mem, la profilo preskaŭ certe enhavas regulon laŭ postulo. Regulo, kiu kongruas kun iu ajn fasado kaj la ago Connect, startas la tunelon kiam Wi-Fi konektiĝas, kiam la Mac vekiĝas el dormo aŭ kiam DNS-sondo malsukcesas. La kliento ne prezentas ŝaltilon, kiu superregas la ŝarĝon.
La servo-listo kaj la agordo por ĉiu servo venas de scutil:
scutil --nc list
scutil --nc show "Corporate VPN"En la eligo de show trovu OnDemandRules kaj legu la valoron Action de ĉiu ero. Connect levas la tunelon, Disconnect malkonstruas ĝin, kaj Ignore lasas la nunan staton senŝanĝa. Unua regulo, kiu kongruas kun ĉio kun Connect, estas la kutima kialo, ke tunelo ne restas mallevita post kiam vi malkonektas ĝin.
Se la konekto mankas en scutil --nc list, ĝi ne estas instalita kiel sistema VPN-servo. Tio indikas retan etendaĵon posedatan de klienta aplikaĵo, kie la profilo eble nur transdonas la agordon de la aplikaĵo kaj la aplikaĵo mem decidas, kiam konekti.
Decidu, ĉu forigo estas via tasko
Du mekanismoj blokas forigon. La ŝarĝo povas agordi PayloadRemovalDisallowed, kio faras la profilon neforigebla en la interfaco, kaj la Mac povas esti sub observo tiel, ke forigo de la administra profilo estas tute rifuzata. Neniu el la du estas cimo, kaj forigi nerilatajn atestilojn aŭ la administran profilon por devigi la aferon lasas vin kun multe pli granda problemo ol tiu, kun kiu vi komencis.
| 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 |
Por labora Mac, la subtena aŭ forira vojo de la administranto estas la ĝusta. Portu la profilan identigilon kun vi. Bileto, kiu diras nur «la VPN-profilo», ne sufiĉas por ke iu trovu la objekton, kiun vi celas.
Kolektu pruvojn antaŭ ol peti helpon
Notu kvin aferojn: la profilan identigilon, la UUID-ojn de la ŝarĝoj, la version kaj konstruon de macOS el sw_vers, la VPN-subtipon, kaj la precizan fiaskotekston kun tempindiko. Aldonu, ĉu la tunelo estas plena aŭ dividita kaj ĉu ĝi fiaskas ĉe konekto aŭ ĉe unua aliro al interna rimedo, ĉar tiuj du fiaskoj havas malsamajn posedantojn.
Por fiasko de reta etendaĵo kutime sufiĉas unu mallarĝa protokola demando:
log show --last 5m --predicate 'process == "nesessionmanager"'Kaptu la liniojn ĉirkaŭ la provo anstataŭ la tutan fenestron, kaj kaŝu servilajn nomojn kaj atestilajn subjektojn antaŭ ol vi afiŝos la rezulton ie ajn. La deploja gvidilo de Apple klarigas, por kio celiĝas administrataj VPN-ŝarĝoj kaj reguloj laŭ postulo, kaj tio estas pli bona argumento ol ekrankopio: Superrigardo de VPN.
Kiam ĉiuj kvin kontroloj estas faritaj, precize unu el tri aferoj veras. La profilo ne estas via por forigi, la ŝarĝo rekonektas la tunelon laŭ dizajno, aŭ la kliento tenas agordon, kiun la profilo neniam regis. Portu la identigilojn kaj la tempan linion al tiu, kiu posedas la aliĝon; tio estas bileto, pri kiu iu povas agi. Premi forigi denove ne estas.