Las dos lecciones anteriores dejaron una paradoja abierta: el PC de Marta tiene la dirección privada 192.168.10.21, los routers de Internet descartan cualquier paquete con direcciones RFC 1918… y aun así Marta navega sin problemas. El truco se llama NAT (Network Address Translation, traducción de direcciones de red) y vive en el router de Valencia: reescribe las direcciones de los paquetes al salir y al volver. En esta lección verás paso a paso cómo lo hace, qué es esa tabla de traducciones IP:puerto que lo hace posible, cómo se publica un servicio interno con port forwarding, y — muy importante para tu carrera — qué cosas rompe NAT y por qué. NAT es de las tecnologías más presentes e invisibles de las redes actuales: entenderla te explicará docenas de comportamientos "raros" que verás en soporte, cloud y desarrollo.

1. El problema: agotamiento de IPv4 y direcciones no enrutables
2. NAT de origen (SNAT/masquerade): el viaje de una petición de Marta
3. PAT / NAT overload: el caso real de casi todas las redes
4. Tipos de NAT: estático, dinámico y PAT
5. Port forwarding (DNAT): publicar la intranet hacia fuera
6. Lo que NAT rompe: el precio del parche
7. NAT como "pseudo-firewall"
8. Curiosidades operativas: hairpin NAT y doble NAT

Recapitulemos las piezas de las lecciones anteriores:

• IPv4 tiene ~4.300 millones de direcciones; parecían infinitas y no lo eran. IANA agotó sus bloques libres en 2011 y los RIR después.
• La respuesta de los 90 fue doble: CIDR (asignar con precisión, sin clases) y RFC 1918 (rangos privados reutilizables por todo el mundo).
• Pero las privadas tienen la limitación que ya conoces: no son enrutables en Internet. No es una limitación técnica del formato del paquete — un datagrama IP con origen 192.168.10.21 es perfectamente válido —, sino una regla de filtrado: como millones de redes usan los mismos rangos, una dirección privada no identifica a nadie de forma única, y los routers de las operadoras descartan esos paquetes. Además, aunque tu petición saliera, la respuesta no sabría volver: ¿a cuál de los millones de 192.168.10.21 del planeta?

Meridiano tiene 20 equipos en Valencia y su ISP le da una IP pública (usaremos la ficticia de documentación 203.0.113.50). La cuenta no sale: 20 equipos, 1 dirección válida en Internet. NAT es el mecanismo que hace que salga: todos los equipos internos comparten la IP pública del router, que actúa de intermediario reescribiendo paquetes.

SNAT (Source NAT) significa reescribir la dirección de origen de los paquetes que salen. Cuando la IP pública es la de la propia interfaz del router y puede cambiar (típico con ISP domésticos y de pyme), la variante se llama masquerade ("enmascaramiento"): los equipos internos salen "disfrazados" del router.

Sigamos un caso completo: Marta abre en el navegador la web de un proveedor público, www.proveedor-cloud.example, que resuelve (DNS, módulo 2) a 198.51.100.80. Su navegador abre una conexión TCP al puerto 443 desde un puerto efímero local, digamos el 51612 (puertos y sockets: módulo 2).

Paso 1 — El paquete sale del PC de Marta:

Destino fuera de su red (AND con la máscara, lección 05-02) → el paquete va al gateway 192.168.10.1.

Paso 2 — El router traduce y anota. Antes de reenviar el paquete hacia Internet, el router:

1. Sustituye la IP de origen privada por su IP pública: 192.168.10.21 → 203.0.113.50.
2. Sustituye (si hace falta, y en la práctica siempre) el puerto de origen por uno libre propio: 51612 → 40001.
3. Apunta la traducción en su tabla de NAT, la pieza clave de todo el mecanismo:

El paquete viaja por Internet con este aspecto — el servidor nunca ve la 192.168.10.21:

Paso 3 — La respuesta vuelve y se deshace la traducción. El servidor responde a lo único que conoce: 203.0.113.50:40001. El router recibe la respuesta, busca 40001 en su tabla, encuentra la fila de Marta y reescribe el destino: 203.0.113.50:40001 → 192.168.10.21:51612. Entrega el paquete en la LAN y el navegador de Marta recibe su respuesta como si nada hubiera pasado.

Detalles operativos que conviene saber:

• Las entradas de la tabla caducan: si una conexión deja de tener tráfico (TCP cerrado o inactivo, UDP tras unos segundos/minutos), el router borra la fila y reutiliza el puerto. Por eso las conexiones larguísimas e inactivas "se caen a través de NAT" y los protocolos usan keepalives.
• NAT recalcula las sumas de verificación (checksum) de IP y TCP/UDP en cada reescritura: la cabecera cambia, la firma debe cambiar.
• El servidor de logs del proveedor registrará que "203.0.113.50 hizo la petición": desde fuera, toda Meridiano-Valencia es una sola dirección.

Lo que acabamos de describir — muchas IP privadas compartiendo una IP pública, distinguidas por puerto — tiene nombre propio: PAT (Port Address Translation), también llamado NAT overload o NAPT. Es lo que hace tu router de casa y el de Meridiano.

La clave está en la columna de puertos. Si a la vez que Marta navega, Ana consulta la misma web, la tabla distingue ambas conexiones sin ambigüedad:

Con ~64.000 puertos utilizables por IP pública, una sola dirección soporta decenas de miles de conexiones simultáneas — de sobra para los 20 equipos de Valencia, y la razón de que IPv4 siga vivo dos décadas después de "agotarse". Cuando el mecanismo lo aplica la operadora para compartir una IP pública entre varios clientes se llama CGNAT (Carrier-Grade NAT); te lo encontrarás en conexiones móviles y de fibra baratas, y agrava todos los problemas del apartado 6.

Cuando alguien dice "NAT" a secas en 2026, casi siempre quiere decir PAT. En Meridiano: PAT en el router de Valencia (todos salen como 203.0.113.50) y PAT en el de Bilbao con su propia IP pública. Nota importante: el tráfico entre sedes por la VPN sitio a sitio no se natea — dentro del túnel, Marta (192.168.10.21) y Jon (192.168.20.7) se ven con sus direcciones privadas reales; para eso está la VPN.

SNAT resuelve las conexiones salientes. ¿Y las entrantes? Supón que Jon está de viaje, sin VPN, y quiere consultar la intranet (https://grupomeridiano.example, que sirve el 192.168.10.10 por el puerto 443, con su API GET /api/proyectos). Alguien de fuera que conecte a 203.0.113.50:443 se topa con el problema simétrico: el router recibe el paquete, busca en su tabla NAT… y no hay fila, porque nadie de dentro inició esa conexión. Sin más información, el router lo descarta.

La solución es DNAT (Destination NAT) o port forwarding: una regla estática que el administrador escribe a mano en el router:

Con esa regla, la petición externa de Jon viaja así:

El puerto externo no tiene por qué coincidir con el interno: podría publicarse 203.0.113.50:8443 → 192.168.10.10:443.

¿Y por qué Meridiano NO lo hace? Porque publicar un puerto es abrir una puerta a todo Internet, no solo a Jon: bots de escaneo encontrarían el servicio en horas y probarían credenciales y vulnerabilidades contra la intranet — un servidor interno que nunca se diseñó para estar expuesto. La política de Meridiano es la recomendada para este caso: los servicios internos se alcanzan a través de la VPN (el empleado remoto se conecta a la VPN y accede a 192.168.10.10 como si estuviera en la oficina), y solo se publica con DNAT lo que está pensado, mantenido y vigilado para ser público. Port forwarding no es malo en sí — es como se publica cualquier servicio autoalojado —; lo peligroso es usarlo como atajo para exponer servicios internos.

En el módulo 4 vimos la filosofía extremo a extremo de TCP/IP: la red solo transporta; la inteligencia está en los extremos, y cualquier host puede hablar con cualquier host. NAT rompe esa simetría: detrás de NAT ya no eres un extremo pleno de Internet — puedes iniciar conexiones, pero no recibirlas. Consecuencias concretas:

• Servidores en casa / en la LAN: invisibles desde fuera sin DNAT explícito. "Monto un servidor en mi PC y le paso mi IP a un amigo" no funciona: tu 192.168.x.x no le sirve, y tu IP pública llega al router, que descarta la conexión entrante.
• P2P, videollamadas y juegos online: dos usuarios, ambos tras NAT, no pueden conectarse directamente — ninguno puede recibir. La industria construyó una capa entera de rodeos (STUN, TURN, ICE, hole punching, servidores intermediarios) solo para atravesar NAT. Si alguna vez una videollamada te ha ido por "relay" con lag, has pagado el impuesto NAT.
• Pérdida de visibilidad extremo a extremo: el servidor ve 203.0.113.50 hagan lo que hagan los 20 equipos de Valencia. Para el proveedor, un abuso de un equipo infectado y el tráfico legítimo de Marta son la misma dirección: baneos y captchas colectivos. Con CGNAT, compartes reputación con desconocidos.
• Protocolos que llevan IPs dentro de los datos: NAT reescribe cabeceras, no el cuerpo. El FTP activo del módulo 2 es el ejemplo clásico: el cliente envía dentro del canal de datos la IP a la que el servidor debe conectarse — y envía la privada, que no sirve. Los routers lo parchean con "ALG" (inspectores por protocolo), otra pieza de complejidad que a veces causa más fallos de los que arregla.
• Fragilidad de conexiones largas: si la entrada de la tabla NAT caduca por inactividad, la conexión muere silenciosamente (típico en SSH o websockets inactivos).

Guarda esta idea: NAT no es un principio de diseño, es un parche brillante al agotamiento de IPv4. Funciona tan bien que se volvió permanente, pero su coste en complejidad es una de las motivaciones centrales de IPv6 (próxima lección).

Habrás oído "estás protegido, tienes NAT". Tiene una base real: como las conexiones entrantes sin entrada en la tabla se descartan, NAT bloquea de facto el acceso directo desde Internet a los equipos internos. Es un efecto secundario valioso… pero no es un firewall:

• No inspecciona ni filtra el tráfico saliente: un equipo infectado en la VLAN corporativa habla con su servidor de control sin que NAT diga nada.
• No protege de nada que inicie la víctima: phishing, descargas maliciosas, webs comprometidas.
• No filtra dentro de la LAN: entre el PC de Marta y el de Ana no hay NAT alguno.
• Sus "excepciones" se abren con facilidad (UPnP permite a las aplicaciones — y al malware — crear reglas DNAT automáticamente en muchos routers domésticos).

La postura correcta: NAT más un firewall con reglas explícitas (los routers de pyme integran ambos). En Meridiano, el router de Valencia hace PAT y aplica reglas: la VLAN 20 de invitados sale a Internet pero no alcanza la VLAN corporativa ni los servidores.

Dos situaciones que verás en la práctica y conviene saber nombrar, sin profundizar:

• Hairpin NAT (NAT loopback): Marta, desde dentro, abre la URL pública 203.0.113.50:443 (o un DNS público que apunta ahí) en lugar de la interna. El paquete va al router y debe "dar la vuelta en horquilla": aplicar DNAT hacia el 192.168.10.10 y SNAT para que la respuesta vuelva por el router. No todos los routers lo soportan bien — de ahí el clásico "la web funciona desde el móvil con 4G pero no desde la oficina". La solución elegante es split DNS: que grupomeridiano.example resuelva a la IP interna dentro de la LAN y a la pública fuera.
• Doble NAT (NAT 444): dos traducciones encadenadas — por ejemplo, el router del ISP hace NAT y detrás el router propio de la empresa hace otro; o CGNAT del operador + NAT del cliente. Todo lo saliente funciona; el port forwarding se complica (habría que abrir el puerto en ambos niveles, y en el CGNAT no puedes) y los problemas del apartado 6 se duplican. Diagnóstico rápido: si la IP WAN que muestra tu router es privada o del rango 100.64.0.0/10 (reservado para CGNAT), hay otro NAT por encima.

• Dar la IP privada a alguien de fuera. "Conéctate a mi 192.168.10.21" solo tiene sentido dentro de la misma red (o vía VPN). Para saber cómo te ve Internet, consulta un servicio de "cuál es mi IP": verás la pública del router.
• Confundir NAT con la VPN. El tráfico entre Valencia y Bilbao por el túnel VPN conserva las IP privadas de origen a destino; NAT solo actúa en el tráfico hacia Internet.
• Abrir port forwarding "para probar" y olvidarlo. Cada regla DNAT es una exposición permanente; documenta, limita y revisa las reglas del router.
• Creer que NAT sustituye al firewall. Bloquea entrantes no solicitadas y nada más; el tráfico saliente y el lateral necesitan reglas explícitas.
• Sorprenderse de que "todos salimos con la misma IP". Es el comportamiento normal de PAT; si un servicio externo os banea a todos por el abuso de un equipo, ese es el porqué.
• Consejo: cuando una app "funciona en una dirección pero no en la otra" (llamada que se oye solo en un sentido, servidor alcanzable solo desde fuera), piensa en NAT: ¿quién inició la conexión?, ¿hay fila en la tabla para el otro sentido?
• Consejo: en diagnósticos, distingue siempre tres direcciones: la privada del equipo, la pública del router y la del destino. Escribirlas evita el 90 % de las confusiones con NAT.

Desde Valencia, simultáneamente: Marta (192.168.10.21) abre una conexión TCP al puerto 443 de 198.51.100.80 desde su puerto 51700, y Ana (192.168.10.22) abre otra al mismo servidor y puerto desde su puerto 51700 (casualidad perfectamente posible). La IP pública del router es 203.0.113.50. a) Escribe la tabla NAT resultante (elige puertos externos plausibles). b) Llega del servidor un paquete con destino 203.0.113.50:40002. ¿A quién lo entrega el router y con qué destino reescrito? c) ¿Por qué el router no puede conservar el puerto 51700 para las dos?

Meridiano quiere que un cliente externo consuma GET /api/proyectos de la intranet (192.168.10.10:443) durante un proyecto de 2 semanas. Un técnico propone la regla DNAT 203.0.113.50:8443 → 192.168.10.10:443. a) Escribe cómo quedarían origen y destino del paquete de petición del cliente (IP pública del cliente: 198.51.100.7, puerto efímero 50123) antes y después del router. b) Da dos riesgos de esta solución y una alternativa más segura coherente con la política de Meridiano.

Un empleado se queja: "desde casa no puedo hacer ping a mi PC de la oficina (192.168.10.30), pero desde el PC de la oficina sí navego por Internet". Explica ambos comportamientos usando la tabla NAT, e indica la forma correcta de acceder al PC de la oficina desde casa.

Solución 1

a) El router asigna a cada conexión un puerto externo libre distinto:

b) El router busca el puerto externo 40002 en la tabla → fila de Ana. Reescribe el destino a 192.168.10.22:51700 y lo entrega en la LAN a Ana.

c) Si ambas salieran como 203.0.113.50:51700 hacia el mismo servidor y puerto, las dos conexiones serían indistinguibles a la vuelta: la tupla (IP externa, puerto externo, IP remota, puerto remoto, protocolo) debe ser única. El puerto externo es precisamente el discriminador que permite a una sola IP pública multiplexar muchas conexiones internas — la esencia de PAT.

Solución 2

a)

b) Riesgos (dos de entre estos): (1) el puerto queda expuesto a todo Internet, no solo al cliente: los escáneres lo encontrarán y probarán ataques contra un servidor interno no endurecido; (2) la intranet entera (no solo /api/proyectos) queda alcanzable por ese puerto; (3) el clásico "regla temporal" que nadie retira a las 2 semanas. Alternativa coherente con Meridiano: dar al cliente acceso VPN limitado (o publicar la API en un servidor específico y aislado, mantenido para exposición pública, restringiendo por firewall las IP de origen del cliente) — nunca DNAT directo al servidor interno.

Solución 3

• Navegar desde la oficina funciona: el PC 192.168.10.30 inicia la conexión; el router crea la entrada SNAT en su tabla y las respuestas encuentran su fila de vuelta.
• El ping desde casa falla: el paquete llega a la IP pública 203.0.113.50 como tráfico entrante no solicitado; no existe entrada en la tabla NAT que diga a qué IP privada corresponde (y ninguna regla DNAT lo define), así que el router lo descarta. Además, la 192.168.10.30 es privada: desde casa ni siquiera es una dirección alcanzable.
• Forma correcta: conectarse a la VPN de Meridiano desde casa; dentro del túnel, el empleado alcanza 192.168.10.30 con su dirección privada real, sin exponer nada a Internet.

Ya tienes el cuadro completo del mundo IPv4 real: direcciones privadas RFC 1918 dentro, una IP pública compartida fuera, y en medio el router haciendo PAT con su tabla de traducciones IP:puerto — creando filas cuando alguien de dentro inicia una conexión, deshaciéndolas a la vuelta y descartando lo entrante no solicitado salvo que un port forwarding (DNAT) diga lo contrario. Sabes por qué Meridiano prefiere la VPN a publicar su intranet, qué rompe NAT (servidores caseros, P2P, la visibilidad extremo a extremo del módulo 4) y por qué su efecto "pseudo-firewall" no sustituye a un firewall de verdad.

Pero no pierdas de vista la naturaleza de todo esto: NAT es un parche — genial, omnipresente, pero parche — sobre un espacio de direcciones que se quedó pequeño. La solución de fondo existe desde los años 90 y lleva décadas desplegándose: un protocolo con tantas direcciones que cada dispositivo del planeta puede volver a ser un extremo pleno de la red, sin traducciones. Es la próxima lección, la última del módulo: Introducción a IPv6.