Qué es NAT
Network Address Translation (NAT) modifica información de direccionamiento IP al atravesar un dispositivo de traducción. RFC 3022 describe el NAT tradicional para IPv4 e incluye Basic NAT y NAPT. El objetivo histórico habitual es permitir que un dominio con direcciones privadas se comunique con un dominio externo con direcciones globalmente únicas.
NAT no es routing: primero debe existir una decisión de encaminamiento válida y, además, puede aplicarse una traducción en el borde.
Direcciones privadas RFC 1918
RFC 1918 reserva tres bloques IPv4 privados: 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. Esas direcciones pueden reutilizarse en redes distintas y no deben propagarse como prefijos globalmente enrutable en Internet.
Una red doméstica o empresarial puede asignarlas internamente y traducir tráfico al salir. Esto no convierte una dirección privada en «más segura» por definición; simplemente no es una dirección globalmente única.
Basic NAT: traducción de direcciones
En Basic NAT se mapea una dirección de un ámbito a una dirección de otro. Puede haber asignaciones estáticas o dinámicas desde un conjunto de direcciones disponibles. La traducción debe mantener estado suficiente para invertir el cambio en el tráfico de respuesta.
Si hay menos direcciones públicas que equipos internos activos, Basic NAT uno-a-uno no resuelve por sí solo el problema; ahí entra NAPT/PAT.
PAT o NAPT: muchos hosts detrás de una dirección
Network Address Port Translation (NAPT), llamado habitualmente PAT en productos comerciales, amplía la traducción para incluir identificadores de transporte como puertos TCP/UDP. Así varias conexiones internas pueden compartir una misma dirección externa y distinguirse por combinaciones de direcciones y puertos.
Un equipo puede traducir, por ejemplo, múltiples conexiones de 192.168.1.10:puerto y 192.168.1.20:puerto hacia una única IP pública usando puertos externos distintos.
Estado y tabla de traducciones
El dispositivo NAT mantiene asociaciones entre flujos internos y externos. Las entradas pueden crearse por configuración o de forma dinámica al iniciar tráfico. Tienen tiempos de vida y reglas diferentes según protocolo.
Cuando una traducción dinámica no existe, el dispositivo no sabe automáticamente a qué host interno entregar una conexión iniciada desde fuera. Para eso se usan mapeos estáticos, port forwarding o mecanismos de publicación equivalentes.
Port forwarding y publicación de servicios
El port forwarding crea una regla para que tráfico recibido en una dirección/puerto externo se traduzca hacia un host y puerto interno. Esto permite publicar un servicio detrás de NAT.
Publicar un puerto no equivale a proteger el servicio. Debe combinarse con firewall, autenticación, actualización del software y una política de exposición adecuada.
NAT no es un firewall
Es habitual asociar NAT con seguridad porque una traducción dinámica dificulta iniciar conexiones arbitrarias hacia hosts internos. Sin embargo, NAT y firewall son funciones distintas. Un firewall aplica una política de filtrado; NAT modifica direcciones y, en PAT, puertos.
Un diseño correcto debe poder explicar por separado qué se traduce y qué tráfico está permitido.
Impacto sobre el modelo extremo a extremo
La traducción introduce estado intermedio y rompe la transparencia de las direcciones extremo a extremo. Protocolos que incluyen direcciones IP o puertos dentro de sus propios payloads pueden necesitar ALGs o mecanismos específicos. También pueden aparecer complicaciones con IPsec, conexiones entrantes, trazabilidad y aplicaciones peer-to-peer.
RFC 3022 documenta varias de estas limitaciones y deja claro que NAT no es invisible para todos los protocolos.
Checksums, fragmentación y protocolos no TCP/UDP
Modificar direcciones exige ajustar checksums cuando los campos traducidos participan en ellos. NAPT además necesita identificar correctamente el flujo. La fragmentación puede complicar esa asociación porque no todos los fragmentos transportan cabeceras de transporte completas.
Los dispositivos modernos resuelven muchos casos, pero el troubleshooting debe recordar que NAT es procesamiento con estado, no una simple sustitución de texto.
¿Qué ocurre con IPv6?
IPv6 proporciona un espacio de direcciones mucho mayor y su arquitectura no necesita NAT44 como mecanismo general para conservar direcciones. Eso no significa que IPv6 carezca de firewalls, prefijos internos o tecnologías de traducción; significa que direccionamiento y seguridad pueden diseñarse sin asumir PAT como requisito.
Para comprender el cambio de modelo, revisa IPv6.
Hairpin NAT y accesos desde dentro
Un caso frecuente aparece cuando un host interno intenta acceder a otro servicio interno utilizando la dirección pública publicada por NAT. Algunos dispositivos implementan hairpin NAT o NAT loopback para devolver ese flujo hacia dentro. Otros requieren una estrategia DNS diferente o reglas adicionales.
Este comportamiento no está garantizado por el concepto general de NAT y debe comprobarse en la plataforma concreta.
Relación entre routing y NAT
Un dispositivo de borde necesita conocer el camino hacia el destino y también el camino de retorno. Si la traducción se crea pero la ruta de salida es incorrecta, no hay conectividad. Si la respuesta vuelve por un camino que evita al dispositivo con estado NAT, la sesión puede fallar.
Por eso NAT debe analizarse junto con la tabla de routing y posibles rutas asimétricas.
Agotamiento de puertos y escala
PAT multiplica conexiones usando puertos, pero ese recurso tampoco es infinito. Redes con muchísimas sesiones simultáneas pueden necesitar varias direcciones externas, políticas de timeouts o diseños de Carrier-Grade NAT. En una red pequeña rara vez es el primer problema, pero entenderlo evita pensar que una sola IPv4 pública tiene capacidad ilimitada.
Cuando hay síntomas intermitentes bajo carga, revisar estadísticas de traducción y uso de puertos puede ser tan importante como comprobar rutas.
Troubleshooting de NAT/PAT
- Confirma que la regla coincide con las direcciones y el sentido de tráfico correctos.
- Comprueba que se crea una entrada de traducción.
- Verifica rutas de ida y retorno.
- Revisa si el pool o los puertos disponibles se han agotado.
- Separa fallos de NAT de fallos de firewall.
- Comprueba DNS: una resolución correcta no demuestra que la traducción funcione.
Capturas antes y después del dispositivo NAT son muy útiles para ver qué cabeceras cambian.
Qué estudiar después
Después de NAT/PAT, entra en supernetting y route summarization para completar el cluster de routing. Si todavía mezclas direcciones privadas, prefijos y subredes, vuelve a direccionamiento IP y subnetting.