Exposer plusieurs serveurs derrière NAT en utilisant une seule adresse IP publique
Ceci est une question canonique à propos de NAT et DNS
J'essaie actuellement de mettre en place un réseau avec un DMZ contenant un serveur Web et un serveur de messagerie séparés 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 mon 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 pour le example.com domaine pour résoudre les deux example.com et mail.example.com à mon adresse IP publique.
Je souhaite que mon pare-feu NAT pare-feu transmette toutes les demandes entrantes à example.com au serveur Web au 192.168.124.30, et toutes les demandes entrantes à mail.example.com au serveur de messagerie au 192.168.124.32. Je vois une fonction de "redirection de port" dans ma configuration de 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 à la fois mail.example.com et example.com à 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 redirection de port (également appelée traduction d'adresse de port ou PAT) fonction de votre pare-feu NAT pour envoyer les demandes entrantes à TCP port 80 (HTTP) au serveur Web lors de l'envoi TCP) = port 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 envoyées à votre NAT adresse IP publique du pare-feu vers TCP port 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é le Host: en-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 Server Name Indication (SNI) 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 va probablement au-delà de ce qu'un simple pare-feu NAT pare-feu est capable car les paquets doivent être inspectés au niveau de la couche application. en utilisant 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 il est probable que vous parliez d'é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 le http://example.com:XXX notation (où XXX est 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 :XXX notation de port dans n'importe quelle URL qu'ils doivent saisir manuellement.)
Votre fonctionnalité de "redirection de port" peut vous permettre d'envoyer du trafic destiné à: 80 et: 443 à 192.168.124.30 et les ports restants (ou uniquement 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 https://mail.example.com:other_port à 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 uniquement des connexions Web sécurisées au serveur de messagerie, non?)
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 regarder un emplacement facile à trouver dans l'en-tête TCP pour le 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 TCP port 80 (443 pour HTTPS), tandis que SMTP utilise TCP port 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 pouvoir accepter le même type de trafic, par exemple. si votre serveur de messagerie héberge également un service de messagerie Web, vous avez des problèmes, car vous ne pouvez transférer des ports spécifiques (80 et/ou 443) qu'à 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.