Le courrier atteint le serveur sans VPN : où appliquer la règle

Le courrier continue d’interroger et le VPN est coupé, mais le compte se synchronise encore. L’application fait ce pour quoi elle a été configurée ; rien dans un profil de courrier normal ne dit que le serveur n’est joignable que par le tunnel. Cela laisse deux exigences différentes, et il est facile de les confondre : le service doit refuser les clients directs, ou le Mac ne doit jamais tenter la connexion.

Choisissez l’exigence avant de choisir un produit. Une règle côté serveur et une règle côté client échouent à des endroits différents, produisent des preuves différentes et appartiennent à des propriétaires différents. Appliquer les deux est valable lorsque les deux affirmations sont vraies, mais l’une ne remplace pas l’autre. Les deux exigences sont légitimes ; elles ne sont simplement pas le même contrôle.

Le symptôme ressemble au Mac, mais le serveur peut être la fuite

Quand le courrier se synchronise hors du tunnel, commencez par ce que le serveur accepte. Si l’écouteur de courrier répond à une connexion directe depuis Internet, aucun réglage de confort côté client ne change ce fait. Le Mac se comporte normalement face à un service encore ouvert.

Demandez à l’administrateur du courrier quelle adresse source le service voit. Une passerelle VPN, un proxy inverse ou un répartiteur de charge peuvent traduire l’adresse du client, si bien que le pool d’adresses de la configuration VPN peut ne pas correspondre à ce qui arrive au processus de courrier. Une règle écrite contre la mauvaise source bloque soit tout le monde, soit personne.

Cette réponse indique aussi si le service peut distinguer les clients VPN. Si chaque client arrive par la même adresse de proxy, une admission fondée sur la source ne peut pas les séparer, et l’exigence doit passer à l’authentification ou au côté client.

Admission côté serveur : refusez la source, pas l’application

Un pare-feu d’hôte ou de réseau peut restreindre l’écouteur de courrier à des plages sources approuvées tout en laissant l’authentification et TLS inchangées. Une condition de règle qui correspond à des adresses distantes, des sous-réseaux ou des plages est le bloc de construction habituel ; la syntaxe exacte relève du produit pare-feu du serveur, pas de l’application de courrier.

C’est la frontière la plus solide lorsque l’exigence est « le service ne doit pas servir les clients directs ». Elle tient même si l’utilisateur installe un autre client de courrier, car le refus intervient avant l’authentification. Elle survit aussi à un Mac qui ignore sa politique VPN.

Sa limite est tout aussi importante. Une connexion refusée prouve que le service a refusé la session ; elle ne prouve pas que le Mac n’a fait aucune tentative. La résolution DNS, un TCP SYN vers un répartiteur de charge antérieur et une nouvelle tentative après échec peuvent tous se produire avant que la règle du serveur soit atteinte. Si l’exigence porte sur la divulgation des tentatives plutôt que sur l’accès, l’admission côté serveur n’est que la moitié du contrôle.

Application côté client : bloquez la tentative, pas seulement le tunnel

Une règle côté client doit interdire le trafic, pas seulement démarrer un tunnel à l’ouverture du courrier. Un déclencheur d’activation pour un domaine de courrier peut monter le VPN au bon moment, mais il ne définit pas ce qui se passe pendant que le tunnel est coupé ou après son échec.

Utilisez la politique de blocage prise en charge par le produit de point de terminaison et délimitez-en la portée délibérément. Une règle au niveau de l’application couvre chaque compte de cette application de courrier, y compris les comptes personnels. Une règle au niveau de la destination doit nommer les points de terminaison IMAP, d’envoi et d’authentification du compte professionnel, et elle doit continuer à fonctionner lorsque ces adresses changent.

Couvrez les deux familles d’adresses et les sessions existantes. Une politique qui bloque les nouvelles connexions IPv4 tout en laissant IPv6 ou une socket établie tranquille produit des synchronisations intermittentes qui semblent aléatoires. Les changements de réseau et les cycles de veille font partie du même test.

Les règles au niveau de l’application et de la destination ont une portée différente

Un blocage au niveau de l’application est simple à raisonner : aucun trafic du Courrier ne sort sans le tunnel. Il est aussi brutal, car la même application peut contenir un compte personnel qui n’a rien à voir avec la politique. Les utilisateurs le remarquent en premier et le signalent comme une application de courrier cassée.

Un blocage au niveau de la destination est plus étroit et plus difficile à maintenir. Il exige l’ensemble complet des points de terminaison utilisés par le compte, y compris les services de découverte et d’authentification, et un processus pour les mettre à jour. Un seul manque et le compte fonctionne à moitié ; en inclure trop et le courrier sans rapport s’arrête.

Choisissez selon la formulation de l’exigence. « Ce compte professionnel ne doit pas se connecter directement » renvoie à la portée de destination. « Ce Mac ne doit pas faire tourner le courrier hors du VPN » justifie la règle d’application plus large, à condition que le propriétaire accepte l’effet secondaire sur le compte personnel.

Testez le refus et l’absence séparément

Avec un compte de test dédié, connectez-vous par le VPN et confirmez le fonctionnement normal. Déconnectez ensuite et testez deux fois : une fois pour voir si le serveur refuse la connexion, et une fois pour voir si le Mac tente le moindre échange. Ce sont des observations différentes et elles appartiennent à des journaux différents.

Surveillez les preuves côté client pour un SYN ou une requête DNS pendant que vous êtes déconnecté, et le journal du serveur pour une session refusée ou acceptée. Si le serveur refuse mais que le client tente encore, la règle serveur fonctionne et la règle client manque. Si le client ne tente rien mais que le serveur accepte encore d’autres clients, la frontière est exactement là où vous l’avez placée.

Notez le responsable de l’application, l’adresse source que le serveur voit réellement et le compte de test utilisé. Le prochain changement de réseau ou de proxy peut déplacer cette source, et une note nommant la valeur observée se vérifie plus vite qu’une nouvelle série de suppositions.