Mac Mail, to konti og én VPN-regel, der ikke kan skille dem

Mail åbner, arbejdsindbakken synkroniserer, og den personlige begynder at løbe tør for tid. Eller begge synkroniserer, men arbejdsserveren svarer kun, mens en tunnel er oppe, og Mail aner ikke, hvilken konto der er hvilken. Symtomet har altid samme form: én applikation, to konti og en regel, der identificerer applikationen. Rettelsen begynder med at indrømme, at applikationen er en beholder, ikke en grænse.

Tre selektorer er i spil her, og de kan ikke byttes ud med hinanden. Den ene er processen, der laver forbindelsen, en anden er den vært, den når, og den tredje er den identitet, der bruges til at logge ind over den vært. Hvilken af dem din politik kan navngive, er den grænse, du faktisk kan bygge.

Hvorfor applikationen er den forkerte enhed

Mail er én proces, der betjener hver konfigureret konto. En regel skrevet mod applikationen fanger alle dens forbindelser, så den personlige konto arver arbejdstunnelen og dens standardrute. Det kan være acceptabelt, men det er en beslutning, ikke en bivirkning, du kan lade uundersøgt.

Undersøg, hvad brugeren faktisk klager over, før du retter noget. En indbakke, der synkroniserer, men ikke kan sende, peger normalt på indsendelsesserveren frem for indbakken, og begge kan ligge på forskellige adresser inden for samme private område. Spørg, om fejlen er i modtagelse, afsendelse eller begge. Svaret afgør, hvilket endepunkt din regel skal dække, og det sparer en tur hos den, der administrerer serveren.

Når de to konti bruger forskellige servere

Hvis arbejdsmail taler med en vært i det virksomhedsinterne område, og personlig mail taler med en offentlig udbyder, kan en destinationsbaseret ordning udtrykke kravet. Den kræver de rigtige adresser på mailserverne, den DNS, der opløser dem, og eventuelle indsendelses- eller godkendelsesendepunkter, der følger med samme tjeneste. Saml alle tre, før du skriver politik, for en regel, der kun dækker indbakken, fejler ved første afsendelse.

Brug adresser, ikke delen efter @-tegnet. Et domæne i en mailadresse er ikke en routingudtalelse, og hvis du behandler det som en, får du en regel, der udløses for den forkerte vært eller aldrig. Bekræft de faktiske endepunkter i kontoindstillingerne eller hos administratoren.

Når begge konti deler én server

To konti på samme værtadresse besejrer destinationsbaseret valg fuldstændigt. En rute til den adresse betjener alle, der forbinder, og den kan ikke undersøge, hvilken postkasse der logger ind bagefter. At flytte ruten flytter stien for begge konti, og det er præcis det udfald, brugeren prøvede at undgå.

På det tidspunkt er de ærlige muligheder en kontobevidst politik, hvis platformen og klienten understøtter en, en separat godkendt mailklient til arbejdskontoen, så applikationsgrænsen bliver reel, eller at acceptere, at begge konti rejser sammen. Vælg en bevidst, og sig hvilken.

At udløse en tunnel er ikke det samme som at dække den

Apples App Layer VPN-payload dokumenterer en MailDomains-indstilling: oplistede domæner får Mail til at udløse en VPN-forbindelse på understøttede administrerede installationer. Det er en nyttig evne, og den er snævrere, end den lyder. Den starter tunnelen, når Mail taler med de domæner; den beskriver ikke hver rute, hver apptilknytning eller hvad der sker, mens tunnelen er nede.

Det er også en administreret funktion, ikke et afkrydsningsfelt per konto i Mail-grænsefladen. Er installationen ikke administreret, er indstillingen ikke tilgængelig for dig, og ingen mængde profilredigering vil frembringe den.

Test med en frisk synkronisering, ikke en cachet indbakke

Accepttesten er en frisk synkronisering for hver konto under den tilsigtede politik, plus den utilgængelige tilstand for den beskyttede. En cachet indbakke beviser intet om den næste anmodning, og et tilsluttet VPN-ikon siger kun, at en eller anden tunnel findes.

Giv administratoren arbejdskontoens endepunkter og den adfærd, du ønsker for personlig mail, og spørg derefter, hvilken understøttet kontobevidst, domænebaseret eller applikationspolitik der implementerer det. At se de to konti synkronisere under hver betingelse er det eneste bevis for, at den grænse, du designede, er den grænse, maskinen håndhæver.