Voy a preparar una ligera clasificación de los diferentes modos y aplicaciones de cada modo de NAT.
Algunas son las conocidas, las habituales, y otras, bueno, son cosas sorprendentes.

Para entender la clasificación de los diferentes tipos de NAT lo que vamos a hacer explicar cada uno de los modos y luego sus aplicaciones.
Como este artículo tiene un peso importante, y buena profundidad, seguramente tenga que elaborar 2 versiones. Una orientada a gente de red, y otra, más bien pensada para gente de sistemas.
Casi todo lo que voy a plantear es nivel IP, capa 3, y TCP o UDP, capa 4, pero este artículo pretende abarcar todas las capas y todos los niveles.

Introducción

En el campo de las redes, NAT cumple un papel fundamental en varios campos, sobre todo mientras se siga aplicando la misma filosofía usada en IPv4 por motivos de conservación del direccionamiento. Otras áreas de interés donde la aplicación de NAT es base de la tecnología es en seguridad, como base de cortafuegos y otros, o habilitando la comunicación entre redes de formas más complejas.

En este artículo, tras el artículo introductorio, voy a profundizar, no demasiado, no quiero ser excesivamente académico, voy a profundizar un poco en los diversos modos que existen y quizás haga algún artículo monográfico más, dedicado a algún modo en concreto, y por supuesto, su lugar en el panorama contemporáneo.

Resumiendo del artículo anterior, NAT, o traducción de direcciones de red, es una tecnología del campo de redes que es capaz de alterar los paquetes de información, que no necesariamente el contenido, mientras está en circulación. Esto significa que NAT trabaja con las cabeceras de los paquetes y los modifica en función de las necesidades de router o del firewall mientras atraviesa entre sus diferentes redes.
Las implementaciones más habituales son las de terminación de red y puerta de enlace orientadas a comunicar hacia otras redes como intermediarios, o hacia redes públicas e Internet.
Así que un resumen podría ser que NAT es una salida al problema del crecimiento de la red y su asociación al agotamiento de las IP disponibles permitiendo así el crecimiento de la red permitiendo a las redes privadas compartir una misma IPv4 pública para todos sus dispositivos.

Pero ¿y que hacemos con el camino de vuelta?

Función primordial de NAT

El propósito fundamental del NAT es que permite que un grupo determinado de direcciones se presente como otra dirección al resto de la red.
Este mapeo, esta adjudicación, habilita múltiples que dispositivos en una red puedan llegar a otra red presentándose con otra identidad. Esto puede suceder múltiples veces a lo largo de todo el recorrido de la comunicación.

Esta función primordial está formada en diferentes proporciones por, en principio, por 3 unidades funcionales básicas y una funcionalidad común. Traducción de IP, Traducción de puertos, seguridad y enrutamiento.

Traducción de direcciones IP: NAT cambia la IP origen de salida del paquete desde una IP normalmente privada a un destino también con IP privada o pública. Es decir, que NAT cambia la dirección IP de origen de los paquetes salientes de una dirección IP a la dirección IP del dispositivo NAT. Esto permite que en cada salto con NAT, los paquetes de respuesta de servidores externos se reenvíen al dispositivo que ha hecho NAT, que a su vez puede reenviarlos al dispositivo adecuado desde el que ha recibido la petición, normalmente en la red local.

Traducción de puertos: NAT también traduce el número de puerto de origen de los paquetes salientes. La función es compartir la o las direcciones de NAT del dispositivo en caso de que varias peticiones del interior quieran atravesar el dispositivo NAT por la misma IP de NAT y los mismos puertos. Una funcionalidad como esta es esencial dado que el número de puertos va a ser limitado en cada IP como ya veremos más adelante, de forma que varios dispositivos puedan utilizar la misma dirección. Al traducir el puerto de origen, NAT cambia la composición del paquete sustituyendo el puerto de la comunicación garantizando así que el tráfico de cada dispositivo pueda identificarse de forma única y enrutarse correctamente.

Seguridad: A pesar de que la seguridad aportada es válida, no es un argumento aceptable como argumento final de venta, pero es indiscutible que la funcionalidad de seguridad definida a partir del NAT forma parte de la base de cualquier sistema de seguridad basado en cortafuegos de capa 3 y 4.

Enrutamiento: Esta es la funcionalidad común. Está presente como parte de la traducción de direcciones y funciona enviando paquetes de una parte del NAT a la otra, conociendo únicamente su tabla de rutas local, y junto a la seguridad, definiendo si permite paso bidireccional o unidireccional. Pero lo básico aquí, es que forma parte de los nodos frontera que conectan direccionamiento enrutable con direccionamiento que según los estándares, no es enrutable y dado que pueden existir repeticiones, para ello se diseñó, no es anunciable para la circulación a través de Internet.

NAT estático

NAT estático es el tipo más sencillo que podemos encontrar.
Aquí se establece una comunicación uno a uno, entre una dirección de un lado del NAT contra otra del otro lado del NAT, es decir, que se establece que, mientras dure la comunicación, que exista un flujo de paquetes, en cualquier dirección permitida, con una asignación permanente de una IP interna a su propia IP externa, o al revés, y permanente a lo largo del tiempo, sea de forma forzada, o bajo demanda. (Explicar esto puede costar pero hay que entender que en ambos lados puede haber pools y cuando uno de ellos se completa, se deniegan las conexiones como pasaba en proveedores de fibra con direccionamiento público en LAN si esto no se gestionaba correctamente)

Es, o más bien, era, de uso común, cuando había una mayor disponibilidad de direcciones IP públicas, para el mapeo directo de servidores de forma que su trazabilidad a través de conservar la misma dirección IP a lo largo del tiempo, se mantenga.
Como ejemplo más común, esto es lo que viene designado en routers y firewalls como host de DMZ.

Entre sus ventajas, como ya he dicho, figuran el mantenimiento de la configuración sin cambios a lo largo del tiempo, es predecible, y que su mantenimiento es relativamente sencillo. También he leído que es ideal para la publicación de servicios complejos, pero hay más formas de hacerlo. Y que dicha publicación facilita el flujo de ese tráfico. Y puedo añadir que vale, como método para compatibilizar pools, conjuntos, entre iguales no enrutables entre si por cualquier motivo o necesidad de configuración, aunque esto es algo que debería estar superado por tecnologías más modernas.

Sus desventajas, pues que no escala bien, no se adapta a redes grandes con facilidad, y que es un uso ineficiente de recursos a ambos lados, difícil de justificar en el presente modelo IPv4. Además de los obvios límites.

NAT dinámico

NAT dinámico es un acercamiento más eficaz a una solución que sigue sin ser completamente ideal. Es un avance y una evolución del NAT estático inicial.
En NAT dinámico hay una red, un conjunto de direcciones en una red utilizan una o varias direcciones.
Cada conexión, con un origen interno utiliza una dirección completa, de las disponibles en el pool de asignación de direcciones externas. Y al revés, también. Cada conexión externa a una IP externa puede llegar al servidor, a la IP, interna, y ahí si puede haber también un grupo de direcciones internas para recibir cada conexión externa. Tiene utilidad para repartir la carga de proceso de las conexiones. (Por ejemplo un grupo de servicios de entrada con respuesta asíncrona por otra vía)
Esto tiene utilidad para conservar el uso de direcciones, permite un reparto dinámico en comparación con NAT estático, con grupos de direcciones que pueden ser más pequeños, optimizando frente al modelo estático, pero hay que tener control de los recursos disponibles en cada momento.

Como ventajas, un uso más eficiente de las direcciones IP en comparación con NAT estático. En ambas direcciones, tanto de entrada como de salida, en ambos lados del NAT. También el uso de grupos de direcciones dinámicos, y permite un nuevo nivel de seguridad, aunque circunstancial, meramente aleatorio, en la que el baile de direcciones permite cierto nivel de ofuscación, más resistente a descubrimientos que un NAT estático u otras soluciones.

Pero como contrapunto, aumenta la complejidad de gestión, especialmente para redes grandes y puede llevar al agotamiento de direcciones si no se gestiona adecuadamente en cualquiera de los rangos. De hecho es un riesgo que puede venir por sobredimensionamiento con los correspondientes costes, o las denegaciones por falta de recursos. También tiene presentes otros límites, superiores a los del NAT estático, pero siguen muy presentes.

PAT - Traducción de puertos

Tomando como base el NAT dinámico, aunque con frecuencia también he visto esquemas con NAT estático, el planteamiento es, desde el más sencillo al más avanzado, es simple. Empezando por ejemplo con un NAT dinámico de una única IP externa, todo el tráfico saldrá por esa IP, compartiendo todas las comunicaciones esa IP, y sus puertos, que serán asignados dinámicamente por el mecanismo de NAT.
Este modelo es más avanzado que los anteriores, y es lo que hoy se denomina NAT vulgarmente por la inmensa mayoría de los consumidores, incluso por mi cuando no quiero tener que aclarar demasiados fregados, aunque estrictamente no es correcto. En ciertos libros lo he encontrado como NAT recargado, NAT overloaded, o simplemente por su nombre real, PAT.
El mecanismo combina el NAT en ambas direcciones, con el reparto dinámico de puertos. Una conexión se forma a partir de una IP y un puerto, que al atravesar el NAT transformará la IP, y además, puede que cambie el puerto, o no, pero solo el mismo número de puertos que los que necesita la conexión en lugar de ocupar una IP entera.
La combinación de la dirección IP de origen, el número de puerto de origen, la dirección IP de destino y el número de puerto de destino permite al dispositivo NAT con mecanismo PAT gestionar un gran número de conexiones simultáneas utilizando una única dirección IP en uno de los extremos, pública, o privada. Esto resulta especialmente útil para conservar las direcciones IP públicas a la vez que se permite una amplia conectividad de red interna.
No voy a extender demasiado esto pero podemos tener PAT+NAT en cualquiera de sus versiones analizadas anteriormente, con grupos, pools, de direcciones a ambos lados y mezclas de técnicas como la asignación estática o dinámica. Esto ya lo veremos más adelante que hay tecnologías que sacan un gran partido a esto.

Como ventajas, evidentemente hay un incremento enorme de la eficacia en los consumos de direcciones IP, sobre todo las públicas, admitiendo una cantidad bastante superior de conexiones simultáneas, y en la parte de seguridad, una mera y simple ofuscación de direcciones y puertos.

En el otro lado, el crecimiento puede dar lugar a un incremento de la complejidad para gestionar, pero sobre todo para analizar y depurar tráficos, para redes muy grandes. Y al entrar en juego un nuevo elemento, que es la asignación de puertos, algunas aplicaciones pueden verse resentidas debido a conflictos de puertos. Lo que ya da comienzo al trabajo con cortafuegos y otros dispositivos de seguridad. Los límites ya son menos opresivos pero siguen estando presentes.

NAT-T o NAT transversal

Esto es una forma especial de NAT que viene a resolver múltiples problemas, sobre todo con vistas a retrocompatibilidad y a la superación de límites. Es una forma de hacer cosas, túneles.
Para entender el funcionamiento del NAT-T hay que pensar en zonas de dominio, límites de seguridad, básicos, pero seguridad al fin y al cabo, y desde ahí desarrollar algo que va a complicarse muchísimo.
Estoy hablando de tunelización, de túneles de cualquier tipo. Esto responde a necesidades nuevas, ya diferentes a las clásicas que ya he contado como la conservación de los recursos o gestión del direccionamiento. De hecho, los objetivos de NAT-T tienen ya poco que ver con esto.
NAT-T lo que permite es que los dispositivos NAT de la red no interfieran en la tunelización de las conexiones que atraviesan dicha infraestructura.
Como existen varias implementaciones, las dos más importantes son las que permiten el paso o las que realizan la tunelización.
Inicialmente las que permiten el paso, serán incapaces de realizar la operación de manipulación de los túneles, pero son compatibles y no impiden o rompen la comunicación. Entre las tecnologías NAT-T que realizan tunelización tenemos tecnologías de retrocompatibilidad como Anynet para SNA sobre TCP/IP, o IPXTunnel para IPX/SPX sobre IP para los sistemas más “legacy”, de retrocompatibilidad, o GRE, Generic routing encapsulation, túneles LNS-LAC para L2TP multisalto conmutables, muy habitual en cores de operadores, o los más modernos VXLAN, de cualquier fabricante, los genéricos de SD-WAN. Todo esto da para mucho, de hecho hay contenido para varios podcast ya preparados.

Como ventajas, es indiscutible su utilidad en escenarios con retrocompatibilidad, o con direccionamiento superpuesto, o con configuraciones que de otra forma no se podrían realizar, permitiendo comunicaciones través de los límites de NAT. Aporta también la capacidad de que los túneles funcionen a través de redes con dispositivos NAT, y en un último lugar, pero ahora si, existen niveles de seguridad cuando intervienen protocolos como SSL, IPSec, L2TP o los propios de SD-WAN.

En frente nos encontramos a la dificultad de implementación, a las diferencias entre estándares, y que no es algo para todos los públicos.

NAT Loopback o Hairpinning. El invento del bucle inverso

Hay más mecanismos aparte de NAT para reducir el gasto de direcciones IP, que se realizan a otros niveles, con DNS por ejemplo, y aplicaciones de proxy inverso, que permiten responder de diferente manera en función de como se realiza la llamada.
Al intervenir a la vez las capas 3, 4 y 7, prácticamente todo el stack IP, es la forma más compleja que podemos encontrar a nivel doméstico, aunque muy usado a nivel empresarial.
¿Que quiere decir esto? Pues que más que un modo de NAT como el dinámico u otros, es una combinación donde intervienen más elementos como el DNS.
Su mecanismo está orientado a permitir que una IP usada en un lado de la conexión sea usada como tal en el otro extremo de la conexión. Es decir. Si un router o firewall no posee esta cualidad, la comunicación iniciada en un lado del NAT tiene que atravesarlo, el paquete será alterado para sustituir la dirección de origen por la del NAT. Pero si la comunicación se inicia en el mismo lado, sin tener que atravesarlo, aún cuando se quiera alcanzar el destino a través de la dirección de NAT, el elemento de NAT no realizará ninguna operación con los paquetes por lo que los resultados serán los esperados, el destino recibe el paquete del origen sin ningún tipo de modificación.
No he explicado bien el objetivo de la idea, del obstáculo a salvar.

El objetivo es que el comportamiento del servicio, de la conexión, sea el mismo desde ambos lados del NAT, sobre todo en el momento en el que la red comienza a crecer y no se han contemplado mecanismos o presencia de servicios horizontales como DNS internos diferenciados y demás, o estos están orientados de otra manera en función del crecimiento de la red.

El mecanismo completo de funcionamiento es sencillo. Independientemente del origen, si el destino a alcanzar por el origen está fuera del segmento local, es decir, que se va a cambiar de red, los paquetes serán manipulados de la forma habitual de NAT y PAT que establecen los equipos por los que pasan.
La complicación y donde entra en funcionamiento el hairpinining es cuando el dispositivo que va a hacer NAT detecta que el origen del paquete y el destino del NAT están en el mismo segmento LAN y mismo lado del dispositivo NAT.
Aquí lo que va a hacer el dispositivo que no lo soporta es redirigir la petición, con lo que la alteración del paquete queda interrumpida en el sentido de que el paquete que cursará hacia destino tiene los datos del origen dentro de su misma red, por lo que no se cumple el objetivo marcado de que el comportamiento sea el mismo desde cualquier origen.
En cambio, si el dispositivo NAT soporta hairpinning, NAT loopback o como lo queráis llamar, al detectar que el paquete con origen en local quiere llegar al mismo segmento, le hará cursar como paquete externo haciendo que el paquete salga de la red local, PAT estándar, volviendo a entrar a través de la regla correspondiente con el direccionamiento externo por el que se le ha hecho pasar de forma que tanto si es un paquete remoto como si es local, el servicio reciba la misma petición con los mismos tipos de datos.

Esta vez las desventajas son mayores, al menos en cantidad, como por ejemplo que se requieren un mayor control del direccionamiento, cosa normal en rango empresarial pero no tan común en doméstico, además de controles sobre la traducción de nombres de dominio, causante de esta necesidad en gran medida, o que el precio de los equipos con estas capacidades es superior al equivalente sin ellas, y unos mayores requisitos de hardware en las implementaciones.

Pero a favor vamos a tener un acceso a servicios unificado y transparente, y una escalabilidad ya no marcada por la disponibilidad de IP si no donde también intervienen más elementos de red que amplían el espectro.

CG-NAT o el malo de las películas

He querido dejar este tipo de NAT para el final, puesto que supone la culminación de los esfuerzos para reducir el uso de direcciones IPv4 y la última salida, el último desvío, antes de IPv6.
Debido a la orientación hacia proveedores de servicio, Carrier grade NAT se llama, es el campo donde se aplica esto de forma extensiva.
Realmente es una modificación de un clásico NAT dinámico con PAT, donde un grupo muy extenso de usuarios comparten un reducido grupo de direcciones públicas. Aquí si voy a hablar de direcciones públicas y del estándar que gestiona todo esto.
Ya escribí un artículo sobre bogons, martians y rangos de direccionamiento bastante amplio donde explico cual es el funcionamiento de las RFC que gobiernan el direccionamiento a todos los niveles. EN CG-NAT tenemos 2 niveles (mínimo) de NAT. El primero, el consumidor final, con su equipamiento en una red local, no enrutable y un router proporcionando conexión.
Este dispositivo tendrá en su parte LAN al usuario, y en la parte WAN tendrá una IP del rango CG-NAT definido, o puede que tenga otra cosa, como falsas direcciones públicas, u otros rangos de direcciones privadas, pero no una IPv4 pública como tal.
Por su parte, el operador tendrá un grupo grande de dispositivos en ese rango de CG-NAT, todos ellos con el lado WAN del usuario, conectados al lado LAN del router de salida del operador. Es decir, que desde el usuario hasta la dirección IPv4 que le corresponde, hay al menos 2 saltos, 2 equipos de NAT, por eso también se denomina doble NAT a este mecanismo.

Un operador, de esta manera, puede mantener un mayor número de clientes con un reducido grupo de direcciones IP públicas, puesto que cada cliente, es decir, cada router de usuario con una IP de CG-NAT, da igual el número de equipos y conexiones que tenga, compartirá IP a través de los puertos que demande de esa IP, no todos, con otros clientes.
Es decir. Que la asignación de direcciones IP públicas se realiza por medio de equipos bastante más grandes que los de cliente, con capacidad para repartir esos puertos y esas direcciones entre todas las conexiones que establezcan los clientes, y usuarios, desde sus equipos.

Gracias a ciertos conocidos, de una conversación pude sacar que la media de clientes por IP ronda los 64 lo que normalmente adjudicaría unos 100 puertos por cliente, pero como esas conexiones ni son simultáneas, ni permanentes, los equipos permiten más, hasta 500, estableciendo sobresuscripción de aproximadamente 5:1 para las conexiones limitando en función de la ocupación de dichos pools hasta agotar los puertos disponibles en la IP pública asignada.
Pero antes he dicho que el enrutador puede manejar también pools de direcciones, grupos de direcciones IP públicas, por lo que, manteniéndose controlado, se puede dar el caso de que un mismo usuario pueda cursar por 2 IP públicas diferentes.

Aquí no voy a resaltar gran cosa como ventaja,salvo el evidente ahorro que supone.
La contrapartida reside en el usuario, que verá que sus “aperturas” de puertos no funcionan debido al doble NAT, que un usuario con una ingente cantidad de equipos conectando don el exterior puede obtener denegaciones de conexión, y que dentro del mismo segmento del enrutador un usuario puede intentar por su WAN, alcanzar las WAN de otro clientes dentro del CG-NAT lo que supone una bajada de los niveles de seguridad si no se atiende correctamente.

¿Futuro?

Como siempre, el cierre esperado no es el que ofrezco.
Es obvio que hay que preguntarse si existe futuro para NAT, para las implementaciones que conocemos.
De momento y mientras que la adopción de IPv6 siga a la velocidad que sigue… Es más que necesario. Es crucial, por el momento, continuar con el uso y sobre todo, el desarrollo de NAT, en las vías que ya conocemos como en nuevas vías.
Creo que pocas veces he dicho cosas más vacías, pero bueno, vamos a meternos en eso que se denomina “panorama moderno y desafios” del campo de los vendehumos, o no, de redes.

El agotamiento de la IPv4 permanece como un desafío interesante. No solo por que supone lo que supone, en escasez, peleas, desasignación de módulos históricos o de reasignación de bloques reservados, si no por el encarecimiento, y, en caso de nuevos desarrollos, la obsolescencia de una parte importante de la planta de hardware que puede quedar obsoleto o que directamente es ya obsoleto y eso explica cosas… Mientras tanto, NAT sigue siendo vital para prorrogar la vida del ya desfasado IPv4.

Por parte de la implantación de IPv6, la coexistencia es un duro desafío chupito que sigo hablando lengua comercial para quien realiza este tipo de proyectos. Sin embargo, al menos, ya existen métodos de coexistencia como la doble pila, (dual-stack), Teredo, 6to4 y otros que como ya he comentado, se basan en o apoyan en NAT, concretamente en NAT-T, para habilitar la comunicación en pilas separadas o entre dispositivos a través de otras redes.
Adicionalmente también tenemos el camino inverso, retrocompatibilidad, desde redes IPv6 puras con destino a otras redes, con componentes como NAT64, DNS64 y posiblemente el equivalente al NAT-T nativo de las redes IPv6, llamado 464XLAT. Todos ellos permiten la coexistencia, traducción al vuelo, túneles a través de tecnologías no compatibles… La coexistencia, concebida como desafío, y sus herramientas.

Tengo algo más de material, que originalmente estaba pensado para una serie de artículos pero creo que quedará mejor como podcast.

YoVirtualizador en formato podcast. Ahora también en Sospechosos Habituales: https://feedpress.me/sospechososhabituales
Y sin más, os dejo los enlaces:

Web: https://www.yovirtualizador.com
Grupo de telegram: https://t.me/grupovirtualizador
Podcast: https://www.ivoox.com/podcast-yovirtualizador_fg_f1563806_filtro_1.xml
Canal de youtube: https://www.youtube.com/channel/UC0R70cABSsmC6TFyXth0qPg
Enlaces afiliados:
Amazon: https://amzn.to/3gX3HmK
Asociación Podcast: https://www.asociacionpodcast.es/registrarse/socio/?coupon=SB6A70
iVoox Plus: https://www.ivoox.vip/plus?affiliate-code=323d07d8569f044513746a1be4724b40
iVoox Premium: https://www.ivoox.vip/premium?affiliate-code=03d0efe2be3b55e4cd6df6dc3f6a6dbc
iVoox Premium anual: https://www.ivoox.vip/premium?affiliate-code=9feb8e44ecb4c97148e227100af9223b