Exponer múltiples servidores detrás de NAT usando una sola dirección IP pública

Esta es una pregunta canónica sobre NAT y DNS

Actualmente estoy tratando de configurar una red con una DMZ que contenga un servidor web y un servidor de correo electrónico separado de Internet por un firewall de traducción de direcciones de red (NAT).

He instalado el firewall NAT con las siguientes interfaces:

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

En mi DMZ tengo mis dos hosts:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

Sé que necesitaré configurar el DNS para que el example.comdominio resuelva ambos example.comy mail.example.commi dirección IP pública.

Me gustaría que mi firewall NAT reenvíe todas las solicitudes entrantes al example.comservidor web al 192.168.124.30, y todas las solicitudes entrantes al mail.example.comservidor de correo electrónico al 192.168.124.32. Veo una función de "reenvío de puertos" en la configuración de mi firewall NAT, pero parece que no puedo lograr lo que estoy buscando.

Te estás confundiendo al pensar en cómo fluye la información entre las capas de la pila de protocolos TCP / IP, específicamente entre los protocolos de capa de DNS y de aplicación.

Tienes una dirección IP pública. Su DNS sin duda puede resolver tanto mail.example.comy example.comcon la misma dirección IP pública.

En general, los datagramas IP que contienen solicitudes a su dirección IP pública, que serán recibidos por la interfaz externa de su firewall, no contienen el nombre del host al que intenta acceder el cliente remoto. Su firewall no puede "saber" mágicamente qué nombre de host resolvió el cliente remoto, ya que ambos nombres de host se resuelven en la misma dirección IP. La capa IP no conoce el nombre de host utilizado en la capa de aplicación.

Los protocolos TCP y UDP diferencian servicios específicos ofrecidos por un host utilizando números de puerto. En el caso de su ejemplo, es posible utilizar la función de reenvío de puertos (también llamada traducción de dirección de puerto o PAT) de su cortafuegos NAT para enviar solicitudes entrantes al puerto TCP 80 (HTTP) al servidor web mientras envía el puerto TCP entrante 25 (SMTP) a su servidor de correo electrónico.

Sin embargo, si planea alojar el mismo servicio en ambas máquinas, esta estrategia se vuelve problemática. Suponga que va a alojar un sitio web seguro en su servidor web (para acceso del Cliente) y un sitio web seguro en su servidor de correo electrónico (para webmail). Las solicitudes que llegan a la dirección IP pública de su firewall NAT al puerto TCP 443 (HTTPS) solo se pueden enrutar a un servidor u otro.

La solución generalizada a esta situación es tener más direcciones IP públicas. Debido a que las direcciones IPv4 se están volviendo escasas, eso también puede ser problemático.

Terminamos trabajando en torno a la escasez de direcciones IP públicas en algunos protocolos en la capa de aplicación. Por ejemplo, HTTP / 1.1 agregó el Host:encabezado específicamente para permitir que un servidor web aloje múltiples sitios web en la misma dirección IP pública. TLS agrega la extensión de Indicación de nombre de servidor (SNI) para permitir la selección del certificado apropiado basado en el nombre de host ingresado por el cliente remoto.

Hacer este tipo de solución en la capa de aplicación significa que cada protocolo de capa de aplicación necesitaría su propia "solución" (y luego todo el servidor y el software del cliente tendrían que implementar esa "solución"). Esa es una tarea difícil.

En lugar de modificar el protocolo de la capa de aplicación, algunos protocolos son fácilmente susceptibles de ser "multiplexados" entre múltiples hosts utilizando un software que puede "enrutar" las solicitudes. Esto probablemente va más allá de lo que es capaz de hacer un simple firewall NAT porque los paquetes deben ser inspeccionados en la capa de aplicación. El uso de un proxy inverso como nginx es un buen ejemplo de este tipo de "multiplexación" (o reglas de publicación web en Forefront TMG o ISA Server en un entorno de Microsoft) para el protocolo HTTP. En teoría, cualquier protocolo podría multiplexarse ​​a través de un proxy inverso, pero cuanto más esotérico sea el protocolo, más probable es que esté hablando de tener un código personalizado escrito.

Cuando necesite ofrecer el mismo servicio desde dos hosts diferentes en una sola dirección IP pública, siempre tiene la opción de mover uno de los hosts a un puerto no estándar. Sin embargo, esto requerirá que los clientes conozcan el puerto no estándar. En el caso de HTTP (S), esto da como resultado URL con la http://example.com:XXXnotación (donde XXXestá el número de puerto no estándar). Si esto sería problemático en su situación es algo que solo usted puede decidir. (Mi experiencia ha demostrado que prácticamente ningún usuario final es capaz de manejar la :XXXnotación de puertos en cualquier URL que deba ingresar manualmente).

Su función "Reenvío de puertos" puede permitirle enviar tráfico destinado a: 80 y: 443 a 192.168.124.30 y los puertos restantes (o solo aquellos que su servidor de correo electrónico está configurado para usar) a 192.168.124.32. Si por alguna razón necesita cualquiera de esos dos puertos para el servidor de correo electrónico y también para el servidor web, está en problemas. Para que este método funcione, cualquier acceso web a su servidor de correo electrónico tendría que estar en un puerto diferente (probablemente no estándar). Probablemente también configure el servidor web para redirigir cualquier cosa que diga " mail.example.com" para usar en su lugar, para los usuarios que no saben cómo agregar el número de puerto y / o especificar una conexión segura. (Usted está va a utilizar conexiones web seguras solamente al servidor de correo, ¿verdad?)https://mail.example.com:other_port

Esto está en la capa de transporte en lugar de la capa de aplicación, lo que significa que no tiene que depender de la inspección profunda de paquetes. En cambio, puede buscar una ubicación fácil de encontrar en el encabezado TCP del puerto.

Si sus "solicitudes entrantes" son cosas diferentes, es decir, tráfico web (HTTP) para el servidor web y tráfico de correo (SMTP) para el servidor de correo, esto puede hacerse: HTTP utiliza el puerto TCP 80 (443 para HTTPS), mientras que SMTP usa el puerto TCP 25; por lo tanto, desde la misma dirección IP pública, puede reenviar tráfico HTTP a su servidor web y tráfico SMTP a su servidor de correo; esto es lo que significa "reenvío de puertos". Cualquier firewall decente es capaz de esto.

Sin embargo, si por casualidad los dos servidores necesitan poder aceptar el MISMO tipo de tráfico, por ejemplo, si su servidor de correo también aloja un servicio de correo web, entonces está en problemas, porque puede reenviar puertos específicos (80 y / o 443) solo a un único servidor; Para separar el tráfico web en función del nombre que el cliente usó para solicitarlo, necesita algo que funcione a un nivel más alto que TCP / IP, como un proxy inverso.