Hindi Mabura ang Pinamamahalaang Profile ng VPN sa Mac? Tingnan ang 5 Hakbang na Ito

Patuloy na itinatago ng iyong Mac ang isang profile ng VPN na ayaw mabura, o nabubura ito at bumabalik pagkatapos ng restart. Karaniwan, tanong ito ng pamamahala, hindi ng sira ang client. Ang mga pagsusuri sa ibaba ay lumilipat mula sa pagmamay-ari patungo sa payload at sa mga patakaran sa muling pagkonekta, at ang bawat isa ay maaaring pumigil sa iyo bago mo sayangin ang isang hapon sa maling panel. Gawin ang mga ito nang sunod-sunod; ang hakbang kung saan nagbabago ang sagot ang siyang dulo ng bahagi mo.

Tiyakin na pinamamahalaan ang profile, hindi lamang naka-save

Buksan ang System Settings at hanapin ang Profiles o Device Management. Depende sa bersyon ng macOS, nasa ilalim ito ng Privacy & Security (Profiles) o General (Device Management). Ang profile na nagpapakita ng pangalan ng organisasyon, maikling paglalarawan at walang minus na button ay inilagay ng organisasyon, hindi idinagdag mo.

Dalawang pagsusuri sa terminal ang mabilis na nagtatakda ng pagmamay-ari. Iniulat ng una ang enrollment, inililista ng pangalawa ang mga profile ng device:

sudo profiles status -type enrollment
sudo profiles -P

Kung sinasabi ng enrollment na oo pero walang laman ang listahan ng profile, huwag munang isipin na walang naka-install. Sa mga pinamamahalaang Mac, may ilang payload na inihahatid ng MDM na nananatiling nakatago sa tool na profiles habang aktibo pa rin. Ang pane ng Device Management ang awtoridad sa kung ano ang itinulak ng organisasyon, at ang walang laman na listahan sa command line sa isang naka-enroll na Mac ay isang kontradiksyon na hindi mo dapat ayusin sa hula.

Basahin ang payload, hindi ang display name

Ang profile ng VPN ay isang lalagyan, at kaunti lang ang sinasabi ng nakikitang pangalan tungkol sa laman nito. Maaaring magdala ang isang payload ng address ng server ng IKEv2, remote identifier, paraan ng authentication at certificate na may sariling UUID. Ang pangalawang payload sa parehong profile ay maaaring magbigay ng identity certificate na kailangan ng tunnel, kaya naman ang certificate na tila nawawala sa Keychain ay maaari pa ring dumating sa pamamagitan ng parehong profile.

I-dump ang mga payload at basahin ang mahahalagang key:

sudo profiles show -type configuration | grep -A3 -E "VPNType|ServerAddress|RemoteAddress|AuthenticationMethod|PayloadUUID"

Itala ang mga UUID ng payload bago ka magbago ng anuman. Sila ang mga identifier na kailangan ng administrator para mahanap ang eksaktong object, at sinasabi rin nila kung ang tunnel at ang certificate ay galing sa iisang pinagmulan o sa dalawang magkaibang deployment.

Pagmasdan kung ano ang nagbabalik ng tunnel

Kung kusang nag-restart ang tunnel, halos tiyak na may On Demand rule. Ang rule na tumutugma sa anumang interface na may Connect na aksyon ay nagpapaandar ng tunnel kapag kumonekta ang Wi-Fi, kapag nagising ang Mac mula sa sleep, o kapag nabigo ang DNS probe. Hindi naglalantad ang client ng switch na umaagaw sa payload.

Ang listahan ng serbisyo at ang configuration ng bawat serbisyo ay galing sa scutil:

scutil --nc list
scutil --nc show "Corporate VPN"

Sa output ng show, hanapin ang OnDemandRules at basahin ang halaga ng Action ng bawat entry. Itinataas ng Connect ang tunnel, ibinababa ito ng Disconnect, at pinapanatili ng Ignore ang kasalukuyang estado. Ang unang rule na tumutugma sa lahat na may Connect ang karaniwang dahilan kung bakit ayaw manatiling patay ng tunnel pagkatapos mong idiskonekta.

Kung wala ang koneksyon sa scutil --nc list, hindi ito naka-install bilang system VPN service. Itinuturo nito ang isang network extension na pag-aari ng client app, kung saan maaaring ipasa lang ng profile ang configuration ng app at ang app mismo ang nagpapasya kung kailan kokonekta.

Magpasya kung pag-aari mo ang pag-alis

Dalawang mekanismo ang pumipigil sa pagbura. Maaaring itakda ng payload ang PayloadRemovalDisallowed, na nagpapawalang-bisa sa pag-alis ng profile sa interface, at maaaring i-supervise ang Mac para tuluyang tanggihan ang pag-alis ng management profile. Wala sa dalawa ang bug, at ang pagbura ng walang kaugnayang certificate o ng management profile para pilitin ang isyu ay mag-iiwan sa iyo ng problemang mas malaki kaysa sa pinagmulan mo.

Para sa work Mac, ang support o offboarding route ng administrator ang tama. Dalhin mo ang identifier ng profile. Ang ticket na nagsasabing “VPN profile” lang ay hindi sapat para mahanap ng kahit sino ang object na tinutukoy mo.

Mangolekta ng ebidensya bago humingi ng tulong

Isulat ang limang bagay: ang identifier ng profile, ang mga UUID ng payload, ang bersyon at build ng macOS mula sa sw_vers, ang subtype ng VPN, at ang eksaktong teksto ng failure na may timestamp. Idagdag kung full o split ang tunnel at kung nabigo ito sa oras ng pagkonekta o sa unang pag-access sa internal resource, dahil magkaiba ang may-ari ng dalawang failure na iyon.

Para sa failure ng network extension, karaniwang sapat ang isang makitid na log query:

log show --last 5m --predicate 'process == "nesessionmanager"'

Kunin ang mga linyang nakapalibot sa pagtatangka sa halip na ang buong window, at i-redact ang mga pangalan ng server at subject ng certificate bago i-post ang resulta kahit saan. Ipinapaliwanag ng deployment guide ng Apple kung para saan dinisenyo ang mga managed VPN payload at On Demand rule, at mas mahusay itong argumento kaysa sa screenshot: Pangkalahatang-ideya ng VPN.

Kapag natapos ang lahat ng limang pagsusuri, eksaktong isa sa tatlong bagay ang totoo. Hindi sa iyo ang profile para alisin, muling ikinokonekta ng payload ang tunnel ayon sa disenyo, o may hawak ang client ng configuration na hindi kailanman kinontrol ng profile. Dalhin ang mga identifier at timeline sa may-ari ng enrollment; iyon ay ticket na may magagawa. Ang muling pagpindot sa delete ay hindi.