Via Mac mem denove konektas la VPN: kontrolu la regulon laŭpete

Vi malkonektas la VPN kaj post tridek sekundoj la piktogramo en la menuobreto denove estas tie. Nenio fantomas: la reguloj laŭpete de macOS komencas konekton kiam la reto ŝanĝiĝas aŭ kiam io petas nomon kiun la regulo kovras, kaj la regulo povas loĝi en profilo kiun vi neniam skribis. Trakuri la kontrolojn sube laŭorde estas pli rapide ol reinstali la klienton. La regulo estas politiko, do legu la politikon antaŭ ol batali kontraŭ ĝi.

Kion la regulo efektive observas

La regulo laŭpete havas du decido-punktojn: la reton al kiu la Mac estas alkroĉita, kaj domajnon kiun io provas solvi. Ambaŭ povas levi la tunelon, kaj tial serĉado de interna nomo startigas VPN-on kiun neniu malfermis. La deplojo ankaŭ bezonas aŭtentikigon kiu funkcias sen ĉeesta persono, kaj tial atesto-bazitaj aranĝoj superregas en administrataj flotoj.

Apud la sistema politiko povas ekzisti rekonekta opcio por ĉiu aplikaĵo, do la unua demando estas kiu mekanismo rekonektis la tunelon. Kontrolu unue la sisteman politikon, poste la klienton, kaj nur poste tiun kiu klakis Malkonekti. Plej multaj klientaj preferoj kiuj ŝajnas respondecaj montriĝas ne tiaj. Tiu ordo gravas ĉar la sistema politiko venkas defaŭlte, kaj agordo je klienta nivelo povas klarigi nur la kazojn kiujn la politiko ne kovras.

Kiu posedas la politikon, kaj kion kostas forigo

Legu la instalitan profilon kaj la subtenatajn klientajn regilojn antaŭ ol ŝanĝi iun el ili. Se la Mac estas administrata, la kondiĉoj estas dokumentitaj ie, kaj peti tiun dokumenton pli bonas ol retroinĝenieri SSID-ojn kaj domajnojn de ekstere.

La konfida materialo en la Mac estas dividata kun ĉiu alia servo kiu uzas ĝin, do revoko estas la lasta paŝo, ne la unua. Forigu la profilon kiu posedas la regulon, poste konfirmu ke la regulo ĉesas ekagi antaŭ ol tuŝi ateston. Duone forigita profilo estas ĝuste la kialo pro kiu homoj konkludas ke la konduto estas hazarda. La du komandoj kiuj montras kio estas instalita indas esti konservitaj:

profiles show -type configuration
scutil --nc list

Kion rekonekto ne pruvas

Rekonekto laŭpete diras nenion pri la breĉo: dum la tunelo leviĝas, trafiko ankoraŭ povas eliri tra la fizika interfaco se aparta politiko ne retenas ĝin. Bloki antaŭ ol la tunelo ekzistas estas alia agordo ol startigi la tunelon. Maŝino kiu rekonektas rapide ankoraŭ povas liki dum la unuaj sekundoj.

La amplekso de la vojoj estas tria demando, ĉar regulo kiu startigas la tunelon diras nenion pri la prefiksoj kiujn ĝi portas. Konfirmu kion la konekto enkursigas anstataŭ supozi ke rekonekto signifas plenan kovron. Testu ĝin intence: fermu la klienton, konfirmu ke la servo haltis, poste petu la rimedon kiun la regulo devas protekti.

Noti la ekigilon, ne la piktogramon

Notu kio levis la tunelon: aliĝo al reto, malfermo de aplikaĵo, solvo de privata nomo, vekiĝo el dormo. Rimarku kiam ĝi okazas, ne nur ke ĝi okazis, ĉar la sinsekvo estas la pruvo. Konkreta ekigilo valoras pli ol ekrankopio de la piktogramo.

Poste kontrolu la rimedon post kiam la konekto leviĝis. La menuobreto pruvas ke servo funkcias, ne ke la celloko kiun vi bezonas atingeblas tra ĝi. La du povas diverĝi pro tute ordinaraj kialoj, inkluzive de vojo kiu montras aliloken.

Kiam la regulo startigas la malĝustan konekton

Konekto kiu startas kiam ĝi ne devus kutime venas de eksdata profilo, de domajna kondiĉo pli vasta ol celite, aŭ de du agordoj konkurencaj por la sama reto. Ĉiuj tri videblas en la instalita agordo, kaj neniom el ili pli klariĝas per ŝaltado de la servo.

Portu la ekigilon, la posedanton de la profilo kaj la celatan konduton al tiu kiu administras la politikon. La dokumentaro de Apple pri laŭpeta reĝimo estas la komuna vortprovizo por tiu konversacio, kaj ĝi estas pli mallonga ol la argumento. Petu ŝanĝon de politiko anstataŭ forigon, kaj ambaŭ flankoj konservas funkciantan aranĝon.