Mac Mail, kaks kontot ja üks VPN-reegel, mis ei suuda neid eraldada

Mail avaneb, tööpostkast sünkroonitakse ja isiklik hakkab aega ületama. Või sünkroonitakse mõlemad, aga tööserver vastab ainult siis, kui tunnel on üleval, ja Mail ei tea, milline konto on milline. Sümptomil on alati sama kuju: üks rakendus, kaks kontot ja reegel, mis tuvastab rakenduse. Parandus algab tunnistamisest, et rakendus on konteiner, mitte piir.

Siin mängivad kolm selektorit ja need ei ole vahetatavad. Üks on ühenduse loov protsess, teine on host, kuhu see jõuab, ja kolmas on identiteet, mida kasutatakse selle hosti kaudu sisselogimiseks. Millist neist teie poliitika suudab nimetada, see on piir, mille saate tegelikult ehitada.

Miks rakendus on vale üksus

Mail on üks protsess, mis teenindab iga seadistatud kontot. Rakenduse vastu kirjutatud reegel haarab kõik selle ühendused, nii et isiklik konto pärib töötunneli ja selle vaikimisi marsruudi. See võib olla vastuvõetav, kuid see on otsus, mitte kõrvalmõju, mille võite uurimata jätta.

Enne millegi parandamist kontrollige, mille üle kasutaja tegelikult kurdab. Postkast, mis sünkroonitakse, kuid ei saa saata, osutab tavaliselt esitamisserverile, mitte sisendkastile, ja mõlemad võivad asuda sama privaatse vahemiku eri aadressidel. Küsige, kas tõrge on vastuvõtus, saatmises või mõlemas. Vastus otsustab, millist otspunkti teie reegel peab katma, ja säästab ühe käigu serveri administraatori juurde.

Kui kaks kontot kasutavad erinevaid servereid

Kui tööpost räägib ettevõtte vahemikus oleva hostiga ja isiklik post avaliku teenusepakkujaga, saab sihtkohapõhine lahendus nõuet väljendada. See vajab postiserverite tegelikke aadresse, neid lahendavat DNS-i ja kõiki esitamis- või autentimisotspunkte, mis sama teenusega kaasas käivad. Koguge kõik kolm enne poliitika kirjutamist, sest ainult sisendkasti kattev reegel ebaõnnestub esimesel saatmisel.

Kasutage aadresse, mitte @-märgi järel olevat osa. Domeen postiaadressis ei ole marsruutimisavaldus, ja selle nii käsitlemine loob reegli, mis käivitub vale hosti jaoks või ei käivitu kunagi. Kinnitage tegelikud otspunktid konto seadetest või administraatorilt.

Kui mõlemad kontod jagavad ühte serverit

Kaks kontot samal hostiaadressil nullistavad sihtkohapõhise valiku täielikult. Marsruut sellele aadressile teenindab kõiki, kes ühenduvad, ja ei suuda kontrollida, milline postkast hiljem sisse logib. Marsruudi liigutamine liigutab tee mõlema konto jaoks, ja see on täpselt see tulemus, mida kasutaja püüdis vältida.

Sel hetkel on ausad valikud kontoteadlik poliitika, kui platvorm ja klient seda toetavad, eraldi heakskiidetud postiklient töökonto jaoks, et rakenduse piir muutuks tõeliseks, või leppimine sellega, et mõlemad kontod reisivad koos. Valige üks teadlikult ja öelge, millise valisite.

Tunneli käivitamine ei ole sama mis selle katmine

Apple'i App Layer VPN kasulik koormus dokumenteerib seade MailDomains: loetletud domeenid panevad Maili toetatud hallatavates juurutustes VPN-ühenduse käivitama. See on kasulik võime ja see on kitsam, kui kõlab. See käivitab tunneli, kui Mail nende domeenidega räägib; see ei kirjelda iga marsruuti, iga rakenduse seost ega seda, mis juhtub, kui tunnel on maas.

See on ka hallatav funktsioon, mitte konto kohta märkeruut Maili liideses. Kui juurutus ei ole hallatav, ei ole seade teile saadaval ja ükski profiili muutmine ei tekita seda.

Testige värske sünkroonimisega, mitte vahemällu salvestatud sisendkastiga

Vastuvõtutest on värske sünkroonimine iga konto jaoks kavandatud poliitika all, pluss kaitstud konto mitteolemasolev olek. Vahemällu salvestatud sisendkast ei tõesta järgmise päringu kohta midagi ja ühendatud VPN-i ikoon ütleb ainult, et mingi tunnel on olemas.

Andke administraatorile töökonto otspunktid ja soovitud käitumine isikliku posti jaoks, seejärel küsige, milline toetatud kontoteadlik, domeenipõhine või rakendusepoliitika seda rakendab. Kahe konto sünkroonimise jälgimine igas olukorras on ainus tõend, et teie kavandatud piir on piir, mida masin kehtestab.