Exposer plusieurs serveurs derrière NAT à l'aide d'une seule adresse IP publique

Ceci est une question canonique sur NAT et DNS

J'essaie actuellement de mettre en place un réseau avec une DMZ contenant un serveur Web et un serveur de messagerie électronique séparé d'Internet par un pare-feu de traduction d'adresses réseau (NAT).

J'ai installé le pare-feu NAT avec les interfaces suivantes:

WAN - x.x.x.x (redacted public IP address)
DMZ - 192.168.124.5/24
LAN - 192.168.123.5/24

Sur ma DMZ, j'ai mes deux hôtes:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

Je sais que je devrai configurer le DNS du example.comdomaine pour résoudre les deux example.comainsi que mail.example.common adresse IP publique.

Je voudrais que mon pare-feu NAT transmette toutes les demandes entrantes au example.comserveur Web au 192.168.124.30 et toutes les demandes entrantes au mail.example.comserveur de messagerie au 192.168.124.32. Je vois une fonctionnalité de "redirection de port" dans la configuration de mon pare-feu NAT, mais je n'arrive pas à réaliser ce que je recherche.

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.)

Votre fonctionnalité "Port Forwarding" peut vous permettre d'envoyer du trafic destiné à: 80 et: 443 à 192.168.124.30 et les ports restants (ou seulement ceux que votre serveur de messagerie est configuré pour utiliser) à 192.168.124.32. Si, pour une raison quelconque, vous avez besoin de l'un de ces deux ports pour le serveur de messagerie ainsi que pour le serveur Web, vous avez des problèmes. Pour que cette méthode fonctionne, tout accès Web à votre serveur de messagerie doit se faire sur un port différent (probablement non standard). Vous devez également configurer le serveur Web pour rediriger tout ce qui dit " mail.example.com" à utiliser à la place, pour les utilisateurs qui ne savent pas comment ajouter le numéro de port et / ou spécifier une connexion sécurisée. (Vous êtes allez utiliser des connexions Web sécurisées uniquement au serveur de messagerie, non?)https://mail.example.com:other_port

Il s'agit de la couche Transport plutôt que de la couche Application, ce qui signifie qu'il n'a pas à s'appuyer sur une inspection approfondie des paquets. Au lieu de cela, il peut rechercher un emplacement facile à trouver dans l'en-tête TCP du port.

Si vos «demandes entrantes» sont différentes, c'est-à-dire le trafic Web (HTTP) pour le serveur Web et le trafic de messagerie (SMTP) pour le serveur de messagerie, cela peut en effet être fait: HTTP utilise le port TCP 80 (443 pour HTTPS), tandis que SMTP utilise le port TCP 25; ainsi, à partir de la même adresse IP publique, vous pouvez transférer le trafic HTTP vers votre serveur Web et le trafic SMTP vers votre serveur de messagerie; c'est ce que signifie "redirection de port". Tout pare-feu décent en est capable.

Cependant, si par hasard les deux serveurs doivent être en mesure d'accepter le même type de trafic, par exemple si votre serveur de messagerie héberge également un service de messagerie Web, vous êtes en difficulté, car vous pouvez transférer des ports spécifiques (80 et / ou 443) uniquement sur un seul serveur; afin de séparer le trafic Web en fonction du nom que le client a utilisé pour le demander, vous avez besoin de quelque chose qui fonctionne à un niveau supérieur à TCP / IP, comme un proxy inverse.