Aller au contenu
Avanet

Configurer Sophos Email Gateway avec Exchange sur site

Avec Exchange sur site, le flux comporte deux chemins distincts : les messages entrants atteignent d’abord les cibles MX Sophos régionales, puis sont remis à Exchange. Exchange envoie les messages sortants via l’hôte relais (smart host) Sophos régional. Configurez et testez les deux sens séparément.

Ce guide ne concerne ni Microsoft 365, ni la gestion automatique des connecteurs par Sophos Mailflow. Un serveur Exchange local nécessite ses propres connecteurs de réception et d’envoi ; les connecteurs Microsoft 365 ne doivent pas être reproduits à cet effet.

Procédure rapide : consignez la configuration actuelle et le retour arrière, configurez le domaine dans Sophos Fusion (anciennement Sophos Central) avec Inbound and Outbound, limitez la réception Exchange aux adresses IP de remise Sophos régionales, créez un Send Connector vers l’Outbound Relay Host copié, tracez les deux sens, puis désactivez les anciennes routes de filtrage.

Préparer les données et le retour arrière

Consignez ces valeurs dans le changement avant toute modification :

  • le domaine de messagerie, par exemple example.org, et tous les destinataires à protéger ;
  • la destination Exchange publiquement joignable sous forme de FQDN ou d’adresse IP, par exemple mail.example.org, et le port SMTP réellement utilisé ;
  • les adresses IP sources publiques ou réseaux CIDR utilisés par Exchange en sortie, par exemple l’adresse de documentation remplaçable 192.0.2.25/32 ;
  • les cibles MX, adresses IP de remise, Outbound Relay Host et domaine SPF Sophos régionaux provenant des dépendances externes actuelles du tenant ;
  • les connecteurs de réception et d’envoi existants, leurs étendues et leur priorité, ainsi que les règles de pare-feu et de NAT ;
  • les valeurs MX et SPF actuelles avec leurs TTL.

Les valeurs Sophos dépendent de la région. Copiez-les depuis votre propre tenant Sophos Fusion et utilisez les listes Sophos actuelles des IP de remise Gateway, enregistrements MX, hôtes relais sortants et domaines SPF. Le tenant affiche aussi le relais sous Gateway Domains > domaine > Configure External Dependencies > Outbound Settings. Conservez les anciennes valeurs DNS et les paramètres des connecteurs comme retour arrière testé. Réduisez le TTL DNS suffisamment tôt. Selon Sophos, la propagation des modifications de connecteurs peut prendre jusqu’à 24 heures ; un test immédiat ne prouve donc pas la propagation complète.

Configurer le domaine et le chemin entrant

Préparer Sophos Gateway

  1. Dans Sophos Fusion, accédez à Global Settings > Products and Services > Email > Gateway Domains, puis ajoutez ou ouvrez le domaine.
  2. Saisissez le domaine, le sens du trafic, la destination de remise et son port SMTP. Le flux complet nécessite Inbound and Outbound.
  3. Sélectionnez Verify Domain Ownership, publiez la valeur TXT propre au domaine à la racine DNS, puis sélectionnez Verify. Utilisez comme nom celui affiché ou @.
  4. Continuez uniquement après confirmation de la vérification par Sophos. Un échec signifie généralement que la valeur TXT est incorrecte ou que la propagation DNS n’est pas terminée.
  5. Ajoutez ou synchronisez les boîtes aux lettres que Sophos Email doit protéger.

La destination de remise est le point de terminaison Exchange publiquement joignable, et non le nom MX Sophos. Son FQDN ou son adresse IP et son port doivent correspondre exactement au service SMTP publié et à la redirection du pare-feu.

Restreindre la réception Exchange

Sur le pare-feu et le chemin de réception Exchange, autorisez uniquement les adresses IP de remise Sophos régionales comme sources de la route Sophos. Relevez les adresses exactes dans les dépendances externes actuelles du tenant. En omettre une peut bloquer la remise ; ajouter un réseau étranger ou trop large affaiblit la protection contre le contournement.

Sur le Receive Connector Exchange utilisé par Sophos, définissez la liaison locale sur l’adresse IP Exchange locale et le port d’écoute prévus ; séparément, limitez les plages IP distantes aux seules IP de remise Sophos régionales et n’utilisez pas 0.0.0.0/0. La réception normale pour les destinataires des domaines acceptés Exchange est distincte de l’autorisation de relais SMTP : elle ne requiert aucun droit de relais général et ce connecteur ne doit pas en recevoir. Si plusieurs Receive Connectors se chevauchent, déterminez avant la bascule lequel correspondra à chaque source Sophos.

Vérifiez d’abord que ce chemin est joignable sans supprimer l’ancienne protection. Remplacez ensuite chez le fournisseur DNS les enregistrements MX par les cibles MX Sophos régionales. Orthographe, préférence et région doivent correspondre exactement aux valeurs du tenant.

Configurer le chemin sortant via Sophos

Autoriser la source sortante dans Sophos

  1. Ouvrez le domaine sous Gateway Domains et sélectionnez Edit.
  2. Dans Configure Domain, confirmez Inbound and Outbound.
  3. Sous Outbound Gateway, sélectionnez Custom Gateway.
  4. Ajoutez au moins une adresse IP publique ou un réseau CIDR depuis lequel Sophos verra réellement les connexions sortantes, puis enregistrez. Les adresses Exchange privées derrière le NAT ne sont pas la source visible ici.
  5. Ouvrez Configure External Dependencies > Outbound Settings et copiez l’Outbound Relay Host régional.

Gardez les plages sources aussi étroites que possible. Un CIDR inutilement large peut autoriser des systèmes tiers ; une mauvaise adresse NAT provoque au contraire des refus de relais.

Basculer le Send Connector Exchange

Dans Exchange, créez un Send Connector SMTP pour les destinataires Internet, sélectionnez Route mail through smart hosts, puis saisissez avec Add l’Outbound Relay Host copié. Chaque contrôle Exchange a un rôle distinct : les espaces d’adressage déterminent les domaines destinataires routés ; les serveurs de transport sources sont les serveurs Exchange qui hébergent le connecteur — les messages sélectionnés pour ce connecteur sont routés vers l’un d’eux, qui établit la remise au smart host ; le coût départage les espaces correspondants de même spécificité ; l’option de connecteur délimité limite sa disponibilité dans la topologie Exchange au site Active Directory, et non le routage des destinataires. Suivez Microsoft pour Exchange 2019, Exchange 2016 ou Exchange 2013.

Pendant la recette et la bascule, désactivez chaque ancien Send Connector de filtrage dont les espaces d’adressage chevauchent ceux du connecteur Sophos, quelle que soit sa liste de serveurs sources ; conservez sa configuration documentée, et non une route concurrente active, pour le retour arrière. Si un pilote doit garder les deux actifs, attribuez-leur des espaces d’adressage réellement distincts. Des listes de serveurs sources distinctes ne répartissent pas les messages selon leur serveur Exchange d’origine et ne constituent pas une isolation sûre. Ne comptez pas sur le seul coût : Exchange évalue d’abord la spécificité de l’espace d’adressage. Après validation, laissez l’ancien connecteur chevauchant désactivé ou supprimez-le.

Vérifier SPF, DKIM et les deux sens

Lorsque Sophos remet les messages sortants, mettez à jour l’unique enregistrement TXT SPF avec la valeur régionale de la liste Sophos liée. Un remplacement Sophos seul suit exactement la forme v=spf1 include:<spf-domain> -all. En exploitation parallèle, conservez tous les mécanismes autorisés existants et insérez include:<spf-domain> avant l’unique all terminal, par exemple v=spf1 include:old.example include:<spf-domain> -all. Remplacez <spf-domain> par la valeur régionale ; ne publiez jamais le placeholder, un second all terminal ou un second enregistrement SPF. Choisissez -all uniquement si tous les expéditeurs réels sont certainement représentés dans cet enregistrement, sinon ~all. Ce choix dépend de la couverture des expéditeurs, pas de l’exclusivité de Sophos. Vérifiez DKIM séparément.

Utilisez des objets uniques pour la recette et notez expéditeur, destinataire et heure :

  1. Entrant : envoyez depuis un domaine externe vers une boîte protégée. Dans Sophos Fusion, le message doit apparaître sous Reports > Message History, puis dans le suivi Exchange et la boîte cible.
  2. Sortant : envoyez depuis une boîte protégée vers un domaine externe. Réglez le sens de Message History sur outbound, examinez l’entrée, puis confirmez l’acceptation externe et le suivi Exchange.
  3. Contournement et relais : une remise directe vers Exchange depuis une source non autorisée et une tentative de relais vers un domaine tiers ne doivent pas être acceptées par le chemin Sophos restreint.

Une entrée dans un seul système ne prouve pas le succès de bout en bout. Corrélez le suivi Exchange, l’historique Sophos et le résultat destinataire avec les horodatages et le Message-ID.

Dépanner méthodiquement

  • Message entrant absent de Sophos : vérifiez cibles MX, préférence, propagation DNS et région. Un ancien MX peut encore contourner la passerelle.
  • Visible dans Sophos, absent d’Exchange : vérifiez destination et port, pare-feu/NAT, adresses IP de remise Sophos régionales, étendue du Receive Connector et files Exchange. Excluez aussi une boîte absente de Sophos.
  • Message sortant bloqué dans Exchange : vérifiez résolution DNS et accessibilité de l’Outbound Relay Host, le Send Connector choisi, ses serveurs sources et les files Exchange.
  • Relais refusé : identifiez l’IP source publique réellement vue par Sophos et comparez-la aux valeurs IP/CIDR de Custom Gateway. N’élargissez pas globalement la plage.
  • Échec TLS : vérifiez les noms de l’hôte relais (smart host) et de la destination, la chaîne, la validité et la correspondance du certificat, ainsi que la négociation TLS prise en charge des deux côtés. Ne désactivez pas durablement TLS pour masquer le problème.
  • Certains messages suivent l’ancien chemin ou bouclent : vérifiez chevauchement des espaces des Send Connectors, coûts/priorité et anciens connecteurs de filtrage. D’anciens MX ou relais amont peuvent aussi former une boucle.

Après chaque correction, répétez le test du sens concerné et comparez les nouveaux horodatages. Si le flux reste absent, relevez Message-ID, plage horaire, état du connecteur, erreur de file et entrée Sophos Message History correspondante pour l’escalade.

Revenir en arrière en toute sécurité

Ne restaurez que le sens défaillant. Pour un incident entrant, rétablissez les anciennes valeurs MX sauvegardées et gardez l’ancien chemin de réception actif jusqu’à propagation DNS. Pour un incident sortant, commencez par rétablir les anciens mécanismes d’expéditeur sauvegardés en les fusionnant dans l’unique enregistrement SPF du domaine, tout en conservant temporairement include:<spf-domain>, puis tenez compte de la propagation DNS prévue dans le plan de changement. Réactivez ensuite l’ancien Send Connector connu et désactivez sans ambiguïté le nouveau Sophos Send Connector afin d’éviter des routes concurrentes.

Ne retirez les modifications de pare-feu et de Receive Connector qu’après preuve du fonctionnement du chemin entrant restauré. Ne retirez include:<spf-domain> de l’unique enregistrement SPF du domaine qu’après validation de la route sortante restaurée, en conservant les mécanismes d’expéditeur rétablis. Retestez ensuite les deux sens, examinez les deux files et documentez les caches DNS restants. Un retour arrière partiel ne devient ainsi ni un relais ouvert ni une seconde route d’envoi incontrôlée.