Vous vous embrouillez dans votre réflexion sur la façon dont les informations circulent entre les couches de la pile de protocoles TCP / IP - entre DNS et les protocoles de couche application, en particulier.
Vous avez une adresse IP publique. Votre DNS peut certainement résoudre les deux mail.example.comet example.comvers la même adresse IP publique.
En général, les datagrammes IP contenant des demandes à votre adresse IP publique, qui seront reçues par l'interface externe de votre pare-feu, ne contiennent pas le nom de l'hôte auquel le client distant tente d'accéder. Votre pare-feu ne peut pas "savoir" par magie quel nom d'hôte le client distant a résolu, car les deux noms d'hôte se résolvent à la même adresse IP. La couche IP ne connaît pas le nom d'hôte utilisé au niveau de la couche application.
Les protocoles TCP et UDP différencient les services spécifiques offerts par un hôte à l'aide de numéros de port. Dans le cas de votre exemple, il peut être possible d'utiliser la fonction de redirection de port (également appelée traduction d'adresse de port ou PAT) de votre pare-feu NAT pour envoyer des requêtes entrantes au port TCP 80 (HTTP) au serveur Web lors de l'envoi du port TCP entrant 25 (SMTP) vers votre serveur de messagerie.
Si, toutefois, vous prévoyez d'héberger le même service sur les deux machines, cette stratégie devient problématique. Supposons que vous allez héberger à la fois un site Web sécurisé sur votre serveur Web (pour l'accès client) et un site Web sécurisé sur votre serveur de messagerie (pour la messagerie Web). Les demandes provenant de l'adresse IP publique de votre pare-feu NAT vers le port TCP 443 (HTTPS) ne peuvent être acheminées que vers un serveur ou l'autre.
La solution généralisée à cette situation est d'avoir plus d'adresses IP publiques. Parce que les adresses IPv4 se font rares, cela peut également être problématique.
Nous finissons par contourner la rareté des adresses IP publiques dans certains protocoles au niveau de la couche application. Par exemple, HTTP / 1.1 a ajouté l'en- Host:tête spécifiquement pour permettre à un serveur Web d'héberger plusieurs sites Web sur la même adresse IP publique. TLS ajoute l' extension SNI ( Server Name Indication ) pour permettre la sélection du certificat approprié en fonction du nom d'hôte entré par le client distant.
Faire ce genre de solution de contournement dans la couche application signifie que chaque protocole de couche application aurait besoin de son propre "correctif" (et alors tous les logiciels serveur et client devraient implémenter ce "correctif"). C'est un défi de taille.
Au lieu de modifier le protocole de la couche application, certains protocoles peuvent facilement être «multiplexés» entre plusieurs hôtes à l'aide d'un logiciel qui peut «acheminer» les demandes. Cela dépasse probablement les capacités d'un simple pare-feu NAT car les paquets doivent être inspectés au niveau de la couche application. L'utilisation d'un proxy inverse comme nginx est un bon exemple de ce type de «multiplexage» (ou règles de publication Web sur Forefront TMG ou ISA Server dans un environnement Microsoft) pour le protocole HTTP. En théorie, tout protocole pourrait être multiplexé via un proxy inverse, mais plus le protocole est ésotérique, plus vous parleriez de faire écrire du code personnalisé.
Lorsque vous devez offrir le même service à partir de deux hôtes différents sur une seule adresse IP publique, vous avez toujours la possibilité de déplacer l'un des hôtes vers un port non standard. Cela nécessitera cependant que les clients connaissent le port non standard. Dans le cas de HTTP (S), cela entraîne des URL avec la http://example.com:XXXnotation (où XXXest le numéro de port non standard). Que ce soit problématique dans votre situation est quelque chose que vous seul pouvez décider. (Mon expérience a montré que pratiquement aucun utilisateur final n'est capable de gérer la :XXXnotation de port dans n'importe quelle URL qu'il doit saisir manuellement.)