Mac Mail, deux comptes et une règle VPN qui ne peut pas les séparer

Mail s’ouvre, la boîte professionnelle se synchronise et la personnelle commence à expirer. Ou les deux se synchronisent, mais le serveur professionnel ne répond que tant qu’un tunnel est monté, et Mail ne sait pas quel compte est lequel. Le symptôme a toujours la même forme : une application, deux comptes et une règle qui identifie l’application. Le correctif commence par admettre que l’application est un conteneur, pas une frontière.

Trois sélecteurs sont en jeu ici, et ils ne sont pas interchangeables. L’un est le processus qui établit la connexion, un autre est l’hôte qu’il atteint, et le troisième est l’identité utilisée pour se connecter via cet hôte. Celui que votre politique peut nommer est la frontière que vous pouvez réellement construire.

Pourquoi l’application est la mauvaise unité

Mail est un seul processus qui sert chaque compte configuré. Une règle écrite contre l’application capture toutes ses connexions, si bien que le compte personnel hérite du tunnel professionnel et de sa route par défaut. Cela peut être acceptable, mais c’est une décision, pas un effet secondaire que vous pouvez laisser sans examen.

Vérifiez ce dont l’utilisateur se plaint réellement avant de corriger quoi que ce soit. Une boîte qui se synchronise mais ne peut pas envoyer pointe généralement vers le serveur d’envoi plutôt que vers la boîte de réception, et les deux peuvent se trouver à des adresses différentes dans la même plage privée. Demandez si la panne concerne la réception, l’envoi ou les deux. La réponse décide quel point de terminaison votre règle doit couvrir, et elle épargne un aller-retour avec celui qui administre le serveur.

Quand les deux comptes utilisent des serveurs différents

Si le courrier professionnel parle à un hôte de la plage d’entreprise et le courrier personnel à un fournisseur public, un dispositif fondé sur la destination peut exprimer l’exigence. Il lui faut les adresses réelles des serveurs de messagerie, le DNS qui les résout et tout point de terminaison d’envoi ou d’authentification qui accompagne le même service. Rassemblez les trois avant d’écrire la politique, car une règle qui ne couvre que la boîte de réception échouera au premier envoi.

Utilisez des adresses, pas la partie après le signe @. Un domaine dans une adresse de messagerie n’est pas une déclaration de routage, et le traiter comme tel produit une règle qui se déclenche pour le mauvais hôte ou jamais. Confirmez les points de terminaison réels dans les réglages du compte ou auprès de l’administrateur.

Quand les deux comptes partagent un seul serveur

Deux comptes sur la même adresse d’hôte déjouent complètement la sélection fondée sur la destination. Une route vers cette adresse sert quiconque se connecte, et elle ne peut pas inspecter quelle boîte se connecte ensuite. Déplacer la route déplace le chemin pour les deux comptes, et c’est exactement le résultat que l’utilisateur cherchait à éviter.

À ce stade, les options honnêtes sont une politique consciente du compte si la plateforme et le client en prennent une en charge, un client de messagerie approuvé distinct pour le compte professionnel afin que la frontière de l’application devienne réelle, ou accepter que les deux comptes voyagent ensemble. Choisissez-en une délibérément et dites laquelle.

Déclencher un tunnel n’est pas la même chose que le couvrir

La charge utile App Layer VPN d’Apple documente un réglage MailDomains : les domaines listés amènent Mail à déclencher une connexion VPN sur les déploiements gérés pris en charge. C’est une capacité utile, et elle est plus étroite qu’elle n’en a l’air. Elle démarre le tunnel lorsque Mail parle à ces domaines ; elle ne décrit pas chaque route, chaque association d’applications ni ce qui se passe pendant que le tunnel est coupé.

C’est aussi une fonctionnalité gérée, pas une case par compte dans l’interface de Mail. Si le déploiement n’est pas géré, le réglage ne vous est pas disponible, et aucune quantité de modification de profil ne le produira.

Testez avec une synchronisation fraîche, pas une boîte en cache

Le test d’acceptation est une synchronisation fraîche pour chaque compte sous la politique prévue, plus l’état indisponible pour le compte protégé. Une boîte en cache ne prouve rien sur la requête suivante, et une icône VPN connectée dit seulement qu’un tunnel existe.

Donnez à l’administrateur les points de terminaison du compte professionnel et le comportement souhaité pour le courrier personnel, puis demandez quelle politique prise en charge, consciente du compte, fondée sur le domaine ou sur l’application, le met en œuvre. Observer les deux comptes se synchroniser dans chaque condition est la seule preuve que la frontière que vous avez conçue est celle que la machine applique.