Saturday, January 21, 2017

Exchange 2016 (6) : connecteurs d'envoi et de réception

English summary: after the creation of several mailboxes in a previous post, users were able to send and receive messages internally with very little additional configuration. In this blog post, I create a send connector with certain parameters and observe that the receive connector, in Exchange 2016, is already configured with the proper settings for the reception of external messages. We take note of some other related elements to ensure successful inbound mail flow. 

***

Dans le billet de blogue précédent, j'ai créé une boîte à lettres pour chacun de mes deux utilisateurs et ceux-ci ont pu échanger des messages en interne. Il s'agit, vous l'aurez compris, d'utilisateurs "imaginaires" par l'intermédiaire desquels nous pouvons mettre à l'essai divers aspects d'Exchange 2016, comme l'accès client via Outlook et OWA. A mon grand contentement, cet accès s'est fait presque tout seul. Maintenant, nous allons passer à la prochaine étape : envoyer des messages vers l'extérieur et en recevoir.

***

Connecteur d'envoi

Notre première tâche consiste à créer ce qui s'appelle un "connecteur d'envoi". Pour ce faire, nous devons ouvrir l'EAC (Centre d'administration Exchange) et nous rendre à la section "flux de messagerie" et puis "connecteurs d'envoi" :



A regarder la capture d'écran ci-dessus, vous avez sans doute deviné qu'il faudra cliquer sur le signe "+ " pour lancer le processus de création d'un nouveau connecteur d'envoi - et vous avez raison. Mais d'abord, je tiens à faire quelques précisions sur ces connecteurs d'envoi.

Comme vous avez probablement remarqué, aucun connecteur d'envoi n'existe par défaut après une nouvelle installation d'Exchange. Dans le scénario d'une migration, en revanche, nous verrions des connecteurs d'envoi déjà en place. En effet, les connecteurs d'envoi existent au niveau de l'organisation Exchange plutôt qu'au niveau d'un serveur particulier. Ainsi, quand un nouveau serveur est installé, il "hérite" en quelques sorte les objets qui existent au niveau de l'organisation (et qui sont stockés dans Active Directory au final).

Nous cliquons donc sur le signe " + " pour créer un nouveau connecteur d'envoi et nous devons aussitôt prendre une décision : quel nom donnerons-nous à notre nouveau connecteur ? Pour nos essais, un simple nom comme "cde_principal" suffira. De plus, comme il s'agit d'échanger des messages avec le dehors, nous allons choisir l'option "Internet" : 



A l'étape suivante, nous devons choisir entre deux options que je résume ainsi :

  • Déterminer l'adresse IP du destinataire par le moyen des enregistrements DNS (MX et A) et puis envoyer directement à cette destination.
  • Faire transiter les messages par ce qu'on appelle un "hôte actif" ou "hôte intelligent" selon les traductions (c'est traduit de deux manières différentes dans la capture d'écran ci-dessous d'ailleurs).

Je choisis la seconde option et je clique sur le signe "+ " pour ajouter l'hôte actif :



L'hôte actif est, en substance, un serveur (un "hôte") qu'un fournisseur met à la disposition des clients afin qu'ils puissent faire transiter leurs messages par ce serveur au lieu d'envoyer directement aux serveurs de messagerie des destinataires. L'hôte actif se révèle utile, en particulier, si on monte un réseau d'essai chez soi et l'interface extérieure de notre pare-feu se voit assigner une adresse IP de façon dynamique. Autrement dit : si c'est une "adresse DHCP".

Quel est le problème ? Certains fournisseurs bloquent le trafic SMTP sortant de ces adresses et même si le vôtre le permet (c'est mon cas), certains services antispam rejettent tout message envoyé à partir de ces adresses "dynamiques". Il faut penser qu'ils ont pris la peine de dresser une telle liste.

Quoi qu'il en soit, l'hôte actif nous permet de reprendre certaines options pour l'étude des systèmes de messagerie dans un milieu temporaire d'essai, et sans devoir faire l'achat d'une adresse IP statique.

Dans le cas présent, j'ai choisi le service "Alternate-Port SMTP" de No-IP. Je ne présenterai pas toutes les démarches à faire, pas à pas, mais, en abrégé, il s'agit de créer un compte chez No-IP, de faire l'achat du service en question, et de protéger l'accès à l'hôte actif avec un mot de passe.

Cela accompli, je reviens à notre serveur Exchange où je spécifie le domaine de l'hôte actif :



Note : où ai-je trouvé ce FQDN au juste ? No-IP vous envoie ces informations par courriel.

Voici notre hôte actif :



Note : comme j'ai expliqué dans mes autres billets de blogue, je cadre mes captures d'écran de manière à se concentrer sur l'essentiel. Les boutons "Enregistrer", "Suivant" et "Terminer" sont souvent hors cadre. Je fais confiance au lecteur de comprendre qu'il faut cliquer dessus pour passer à la page suivante.

J'ai mentionné un mot de passe qu'il fallait saisir en configurant son hôte actif chez No-IP. A l'étape de la configuration du connecteur d'envoi illustrée ci-dessus, il faut choisir "authentification de base" avec TLS et puis saisir les données de connexion qui correspondent aux données chez No-IP :


Encore une fois, No-IP vous communique ces données par courriel (à l'exception du mot de passe choisi qu'il faut simplement retenir).


A l'étape suivante, nous devons spécifier l'espace d'adresse dont ce connecteur va s'occuper. Il faut cliquer sur le signe " + " :


Note : je n'ai pas besoin de cocher (tout en bas)  "Connecteur d'envoi délimité" pour mes objectifs.


Nous ajoutons un domaine et puisque nous utiliserons ce connecteur d'envoi pour tout, il suffit de mettre un astérisque (étoile) dans la case FQDN :


Ce qui nous donne ceci :


Note : vous pouvez cliquer sur les images pour les agrandir.

Si, plus tard, nous avions besoin de créer un connecteur d'envoi pour un autre domaine (un partenaire avec des exigences spéciales, par exemple), nous mettrions le nom de ce domaine dans la case FQDN afin que le nouveau connecteur s'occupe de ces envois (avec les paramètres appropriés). C'est donc le connecteur avec la référence la plus spécifique à tel domaine qui s'occupe de ce domaine-là.

Enfin, nous devons choisir les serveurs associés à ce connecteur. Nous cliquons donc sur le signe " + "...



Et nous ajoutons notre seul serveur, EX16-3 :



Voici le résultat :



Nous cliquons sur "Suivant", "Terminer", etc.. pour fermer l'Assistant.

A cette étape, nous pouvons tenter d'envoyer un message à un destinataire extérieur (quelqu'un avec un compte Gmail ou Hotmail, etc.). C'est ce que j'ai fait et cela a réussi. Nous pouvons en conclure que le connecteur d'envoi, correctement configuré, est désormais fonctionnel.


***


Connecteur de réception

Mais attendez ! Peut-on nous répondre de l'extérieur? La réponse est oui... en principe.

En ce qui concerne Exchange 2016 (je précise bien 2016), aucune configuration manuelle n'est requise pour le connecteur de réception. Les paramètres par défaut acceptent les messages du dehors à condition que l'adresse corresponde à un de nos "domaines acceptés". Nous pouvons vérifier ceux-ci, et les modifier au besoin, à cet endroit :



Ce n'était pas le cas dans certaines versions précédentes comme Exchange 2007 et 2010 où il fallait ajuster les permissions afin d'accepter des messages des expéditeurs "anonymes".

Pour Exchange donc, tout va bien. Il faut tenir compte de deux autres facteurs quand nous planifions ou dépannons le flux de messagerie entrant :

  • Il faut que les enregistrements DNS soient justes. En particulier, les "MX" doivent renvoyer vers l'"A" et celui-ci doit renvoyer à l'adresse IP de l'interface externe du pare-feu de l'organisation (à moins qu'un tiers s'occupe de l'hygiène des messages, auquel cas nous réglerions nos enregistrements en conséquence).
  • Une fois que les messages arrivent à notre pare-feu (ou dispositif équivalent), il faut que l'appareil puisse relayer les messages vers le serveur Exchange. Il s'agit de configurer ce qu'on appelle le plus souvent "1 to 1 NAT". Encore une fois, la situation sera sans doute différente pour chacun. Le pare-feu pourrait plutôt relayer les messages vers un répartiteur de charge qui, à son tour, les enverrait vers un ensemble de serveurs Exchange. Le matériel pour le pare-feu va sans doute varier aussi. Les uns utilisent Cisco alors que les autres utilisent CheckPoint (etc.). Voilà pourquoi je ne présente pas la configuration de ces éléments en détail : mes instructions ne seraient pas valables pour le matériel d'un autre vendeur.

Note : et n'oublions pas les "domaines acceptés". Si nous utilisons seulement le nom de domaine par défaut, il sera ajouté automatiquement en tant que "domaine accepté". Si nous utilisons d'autres domaines dans les adresses de notre courriel, nous devons ajouter ces domaines à la liste des domaines acceptés de façon manuelle.

Pour récapituler, il est donc possible de recevoir des messages de l'extérieur si toutes les conditions ci-dessus sont remplies : bonne configuration de DNS, du pare-feu, et des domaines acceptés. Mais je n'ai pas encore montré le connecteur de réception et il le faut afin de clarifier certaines choses.

D'abord, il n'y pas un seul connecteur de réception (1) après une installation normale d'Exchange 2016 mais plutôt cinq (5). Les voici :




C'est le "Default Frontend [Nom du serveur]" qui nous intéresse pour le flux des messages avec l'extérieur. En cliquant sur l'icône du stylo, nous pouvons afficher ses propriétés...




Et en particulier, dans la section "sécurité", nous voyons que la dernière case pour les permissions, "Utilisateurs anonymes", est cochée par défaut :



Qu'en est-il des autres connecteurs de réception ? A quoi servent-ils ?

  • Outbound Proxy Frontend : par défaut, les messages sortants passent par le connecteur d'envoi qui les expédie directement vers les destinataires à l'extérieur (éventuellement par le biais d'un hôte actif). Nous avons l'option de faire transiter ces messages par le service "Front End Transport". C'est ce connecteur qui s'en occuperait alors. Dans la plupart des cas, nous n'avons pas besoin de recourir à cette option.
  •  Client Frontend et Client Proxy : les connecteurs avec le mot  "Client" concernent les connexions  POP et IMAP. Si nous n'utilisons ni l'un ni l'autre, nous n'avons pas besoin d'en tenir compte. C'est mon cas.
  • Default : cela nous laisse avec le connecteur "Default"...

Quelle est la différence entre le connecteur "
Default Frontend" et "Default" tout court ? Je vous l'explique :

Le connecteur "Default Frontend" se rattache au service "Front End Transport"...

Alors que...

Le connecteur "Default" se rattache au service "Transport".

Mais en quoi cette explication nous avance-t-elle ? Je le reconnais : elle ne fait que déplacer la question, c'est-à-dire...

Quelle est la différence entre le service "Front End Transport" et le service "Transport" tout court ?

Le service "Front End Transport" joue le rôle de "proxy" (ou intermédiaire) entre les serveurs SMTP extérieurs et le service "Transport". Il fait passer les messages entre les deux sans autre forme de traitement.

Le service "Transport" s'occupe des tâches de catégorisation des messages et de l'inspection de leur contenu (antivirus/antispam - souvent avec les "agents" d'un logiciel tiers). Il agit lui-même comme un intermédiaire entre le service "Front End Transport" et le service "Mailbox Transport".

Ce dernier service s'occupe de l'interaction directe avec les boîtes à lettres. En fait, il se compose lui-même de deux services : le service "Mailbox Transport Delivery" et "Mailbox Transport Submission". De ces deux services, le premier pose les messages qui arrivent du service "Transport" dans les boîtes à lettres et le second ramasse les messages sortants en attente et les transmet au service "Transport".

Comme vous avez vu dans certaines des captures d'écran plus haut, la version française d'Exchange retient parfois les noms anglais des connecteurs. J'ai moi-même utilisé les noms de service anglais car la documentation officielle en français n'est pas toujours disponible (voir le lien plus bas par exemple). Toutefois, je me rends compte, en consultant la console des Services, que les noms de services sont bel et bien traduits dans la version française de Windows 2012 R2, soit...

  • Transport frontal (pour "Front End")
  • Transport (d'accord, aucun changement là)
  • Remise de transport de boîtes aux lettres (pour "Delivery")
  • Transmission de transport de boîtes aux lettres (pour "Submission")


***

Pour de plus amples renseignements, veuillez vous reporter à la documentation officielle à ce sujet (au moment où je compose ce billet, la documentation n'a pas été traduite en français) :


En conclusion, ce billet a fini par être assez long et complexe mais, à la fin, j'ai été capable d'envoyer des messages d'essai vers l'extérieur et aussi d'en recevoir.

No comments:

Post a Comment