Mac Mail, twee rekeninge en een VPN-reël wat hulle nie kan skei nie

Mail maak oop, die werkposbus sinkroniseer, en die persoonlike een begin tyd uitloop. Of albei sinkroniseer, maar die werkbediener antwoord net terwyl ’n tonnel op is, en Mail weet nie watter rekening watter is nie. Die simptoom het altyd dieselfde vorm: een toepassing, twee rekeninge en ’n reël wat die toepassing identifiseer. Die regmaak begin met die erkenning dat die toepassing ’n houer is, nie ’n grens nie.

Drie keuses is hier in die spel, en hulle is nie uitruilbaar nie. Een is die proses wat die verbinding maak, ’n ander is die gasheer wat dit bereik, en die derde is die identiteit wat gebruik word om oor daardie gasheer aan te meld. Watter een jou beleid ook al kan noem, is die grens wat jy werklik kan bou.

Waarom die toepassing die verkeerde eenheid is

Mail is ’n enkele proses wat elke opgestelde rekening bedien. ’n Reël wat teen die toepassing geskryf is, vang al sy verbindings, so die persoonlike rekening erf die werktonnel en sy verstekroete. Dit kan aanvaarbaar wees, maar dit is ’n besluit, nie ’n newe-effek wat jy ondersoek kan laat nie.

Kyk waarna die gebruiker werklik kla voordat jy iets regmaak. ’n Posbus wat sinkroniseer maar nie kan stuur nie, dui gewoonlik op die indienbediener eerder as die inkassie, en albei kan op verskillende adresse binne dieselfde private reeks woon. Vra of die fout ontvangs, stuur of albei is. Die antwoord bepaal watter eindpunt jou reël moet dek, en dit spaar ’n heen-en-weer met wie ook al die bediener administreer.

Wanneer die twee rekeninge verskillende bedieners gebruik

As werkspos met ’n gasheer binne die korporatiewe reeks praat en persoonlike pos met ’n openbare verskaffer, kan ’n bestemminggebaseerde reëling die vereiste uitdruk. Dit het die werklike adresse van die posbedieners nodig, die DNS wat hulle oplos, en enige indienings- of verifikasie-eindpunte wat saam met dieselfde diens ry. Versamel al drie voordat jy beleid skryf, want ’n reël wat net die inkassie dek, sal by die eerste stuur misluk.

Gebruik adresse, nie die deel ná die @-teken nie. ’n Domein in ’n posadres is nie ’n roeteringsverklaring nie, en om dit so te behandel lewer ’n reël wat vir die verkeerde gasheer vuur of glad nooit nie. Bevestig die werklike eindpunte uit die rekeninginstellings of by die administrateur.

Wanneer albei rekeninge een bediener deel

Twee rekeninge op dieselfde gasheeradres verydel bestemminggebaseerde keuse heeltemal. ’n Roete na daardie adres bedien wie ook al koppel, en dit kan nie inspekteer watter posbus daarna aanmeld nie. Om die roete te skuif skuif die pad vir albei rekeninge, en dit is presies die uitkoms wat die gebruiker wou vermy.

Op daardie punt is die eerlike opsies ’n rekeningbewuste beleid as die platform en kliënt een ondersteun, ’n aparte goedgekeurde poskliënt vir die werkrekening sodat die toepassingsgrens werklik word, of om te aanvaar dat albei rekeninge saam reis. Kies een doelbewus en sê watter een.

’n Tonnel begin is nie dieselfde as om dit te dek nie

Apple se App Layer VPN-lading dokumenteer ’n MailDomains-instelling: gelyste domeine laat Mail ’n VPN-verbinding begin op ondersteunde bestuurde ontplooiings. Dit is ’n nuttige vermoë, en dit is smaller as wat dit klink. Dit begin die tonnel wanneer Mail met daardie domeine praat; dit beskryf nie elke roete, elke app-verbinding of wat gebeur terwyl die tonnel af is nie.

Dit is ook ’n bestuurde funksie, nie ’n merkie per rekening in die Mail-koppelvlak nie. As die ontplooiing nie bestuur word nie, is die instelling nie vir jou beskikbaar nie, en geen hoeveelheid profielredigering sal dit lewer nie.

Toets met ’n nuwe sinkronisering, nie ’n gekaste inkassie nie

Die aanvaardingstoets is ’n nuwe sinkronisering vir elke rekening onder die beoogde beleid, plus die onbeskikbare toestand vir die beskermde een. ’n Gekaste inkassie bewys niks oor die volgende versoek nie, en ’n gekoppelde VPN-ikoon sê net dat een of ander tonnel bestaan.

Gee die administrateur die werkrekening se eindpunte en die gedrag wat jy vir persoonlike pos wil hê, en vra watter ondersteunde rekeningbewuste, domeingebaseerde of toepassingsbeleid dit implementeer. Om te sien hoe die twee rekeninge onder elke toestand sinkroniseer, is die enigste bewys dat die grens wat jy ontwerp het, die grens is wat die masjien afdwing.