Respondiendo una consulta que me hizo un alumno del curso de iptables, hoy aprenderemos el concepto de NAT (Network Address Translation), y las diferencias entre SNAT y DNAT

Este contenido complementa nuestro curso de IPTables.

Comprendiendo el NAT para entender la diferencia de SNAT vs DNAT

NAT, o Network Address Translation (Traducción de direcciones de red), es un término que se utiliza para cuando algún dispositivo de red realiza cambios en alguno de los parámetros TCP/IP de los paquetes de red.

Las operaciones de NAT se llevan a cabo en el router o firewall de red, o dispositivos de borde (edge platform), que es donde se realiza la conexión entre una red privada y una pública.

Cabe preguntarse, si una red privada no es direccionable en Internet (como una LAN): ¿cómo puede un equipo de la red privada, por ejemplo, navegar en Internet, si el servidor no conoce su dirección privada?

Otro caso: ¿cómo es posible que un servidor montado en una LAN, con direccionamiento privado, puede ser alcanzado por un cliente en Internet?

Estas preguntas tienen una sola respuesta: porque existe el NAT. Veamos a continuación sus dos variantes: SNAT y DNAT.

SNAT: «Saliendo» a Internet

Cuando un equipo en una red privada necesita salir a Internet, utiliza el router o el firewall, que le da el acceso.

Este equipo tendrá configuradas dos direcciones IP: una privada, que conecta a la LAN, y una pública, que conecta a Internet. Esto se ve en el siguiente diagrama:

Supongamos que el cliente, IP 192.168.1.123, desea conectar a un servidor ubicado en la IP pública B (por ejemplo, un servidor web).

El paquete de consulta que envíe el cliente va a llegar primero a la puerta de enlace predeterminada (default gateway). En nuestro caso, el router/firewall.

Allí es donde se produce el SNAT, Source NAT, o NAT de origen. El router/firewall va a modificar la IP de origen del paquete del cliente, y va a reemplazar la IP privada por la IP pública A (configurada en el router).

De esta forma, el paquete que reciba el servidor va a provenir desde una IP pública, y podrá responderle.

Cuando le responda, el paquete de respuesta viajará destinado hacia la IP pública A, la del router/firewall. Allí el equipo va a revertir el NAT mediante una asociación de conexiones en caché, y va a cambiar, en este caso, la IP destino (recordemos, IP pública A) por la IP privada del cliente: 192.168.1.123, y le enviará al cliente la respuesta.

Así, el cliente «pensará» que está interactuando directamente con el servidor, cuando en realidad lo hace con un equipo intermedio, mientras que el servidor remoto «pensará» que está interactuando con el router/firewall, cuando en realidad lo hace con un cliente en un direccionamiento privado.

Veamos el ejemplo en una captura del contenido del curso de IPTables.

DNAT: montando un servidor en IP privada

Veamos ahora otro caso. Considerando un esquema similar al de recién, supongamos ahora que tenemos un servidor montado en una IP privada de la LAN, y deseamos que sea accesible desde Internet.

Un cliente remoto no podrá acceder al servidor directamente, puesto que éste se encuentra «escuchando» conexiones en una IP privada. Sin embargo, el punto de acceso más cercano del cliente hacia el servidor es el router/firewall, su IP pública A.

Veamos el siguiente diagrama:

Aquí, es el cliente remoto quien intentará conectar. No conoce la IP del servidor, pero sí la IP pública del firewall (IP pública A). Enviará su solicitud a dicha IP.

Cuando el router/firewall reciba la consulta del cliente, sabrá que todo el tráfico destinado al servidor (por ejemplo, si es un servidor web, podremos redireccionar el tráfico de los puertos TCP 80 y 443).

El router/firewall cambiará en este caso la IP destino del paquete del cliente (de ahí DNAT: Destination NAT, NAT de destino), y la reemplazará por la IP privada del servidor, 192.168.1.250 en nuestro ejemplo. Entonces le hará llegar la consulta al servidor.

Una vez que el servidor responda, el paquete se dirigirá al router/firewall nuevamente, donde, de manera automática, se cambiará la IP origen privada por la IP pública A del firewall, y se enviará al cliente remoto.

Así, el cliente «pensará» que está interactuando con un servidor ubicado en la IP pública A, cuando en realidad lo hará con un servidor en direccionamiento privado, mientras que el servidor «pensará» que está interactuando directamente con el cliente remoto, cuando en realidad lo hará con un equipo intermedio.

Veamos la siguiente animación extraída del curso de IPTables 🙂

SNAT y DNAT: Consideraciones

Hemos analizado los dos casos principales de NAT de direcciones IP, de manera simplificada y conceptual. Por ser conceptual no hemos incluido comandos iptables para configurar cada caso (igualmente está todo explicado en el curso).

El SNAT, muchas veces denominado enmascaramiento (o masquerading) es implementado de forma predeterminada por casi cualquier router hogareño, por eso es que nuestras computadoras y dispositivos wireless pueden conectarse a Internet desde sus IP’s privadas.

El DNAT generalmente lo configuramos nosotros en nuestros routers/firewalls cuando montamos un servidor en direccionamiento LAN privado, y necesitamos accederlo desde Internet.

Además, estas configuraciones no son excluyentes en un esquema de red, ni siquiera en un solo firewall. Es decir, podríamos tener una red LAN cuyos hosts puedan salir a Internet sin problemas (SNAT) y a su vez, tener servidores privados accesibles desde Internet (DNAT).

Por su parte, cuando hablamos de «Servidor remoto» o «cliente remoto» en los diagramas anteriores, bien podría tratarse de equipos que se encuentren detrás de un NAT (ya sea SNAT o DNAT), y no estar conectados directamente a una IP pública.

Cada firewall y router tienen sus propias maneras de configurar estos parámetros. En el curso de IPTables lo hacemos de manera práctica utilizando esquemas de red virtualizados y mediante la línea de comandos del firewall.

Si trabajamos con iptables, resulta de interés leer el man del comando para entender los parámetros disponibles.

Espero que les haya resultado interesante!

Cualquier duda o consulta ya saben dónde encontrarme 😛

Hasta la próxima!