Errores de NAT y PAT: verificar las tablas de traducción y comprender los comportamientos con estado

En esta entrada tratamos de forma focalizada los errores NAT y PAT: cómo comprobar las tablas de traducción (Translation Tables), identificar causas típicas y manejar de forma operativa el comportamiento stateful de firewalls y gateways NAT. La palabra clave aparece al principio, porque muchas incidencias en producción son causadas directamente por tablas conntrack desbordadas, colisiones PAT o enrutamiento asimétrico. El público objetivo son administradores, system engineers, operadores y proveedores de servicios técnicos; las instrucciones son orientadas a la práctica, con rutas de verificación claras, ejemplos de configuración y estrategias de reversión.

NAT, PAT y stateful – explicación compacta

NAT (Network Address Translation) modifica direcciones de origen o destino en paquetes IP para salvar espacios de direcciones. PAT (Port Address Translation) utiliza además puertos de origen o destino para que varios hosts internos compartan una IP pública. „Stateful“ significa que un dispositivo almacena estados de conexión localmente —en una tabla conntrack o de traducción— y asigna correctamente el tráfico de retorno. Si falta ese estado o está inconsistente, el tráfico de retorno a menudo es rechazado. Comprender este principio es central para troubleshooting y operación.

Errores NAT y PAT: causas frecuentes y síntomas

En el día a día aparecen patrones de fallo recurrentes. Aquí una asignación concisa de causa, síntoma y primera comprobación:

• Desbordamiento de la tabla conntrack: Síntoma: no se permiten nuevas conexiones TCP, alerta de monitorización. Comprobar: estadísticas de conntrack.
• Agotamiento de puertos PAT: Síntoma: hosts concretos pierden conexiones salientes, muchos mapeos sobre una IP. Comprobar: distribución de traducciones por IP pública.
• Enrutamiento asimétrico: Síntoma: paquetes de ida atraviesan NAT, los paquetes de retorno llegan a otro dispositivo y son descartados. Comprobar: capturas de paquetes en varios saltos.
• Estados obsoletos / timeouts prolongados: Síntoma: uso elevado de recursos por entradas antiguas. Comprobar: tiempos de espera y tipos de sesión.
• Reglas NAT erróneas: Síntoma: translation de destino incorrecta, conflictos de prioridad. Comprobar: revisar el conjunto de reglas detalladamente.

Riesgos en operación

La relevancia operativa es alta: los errores NAT y PAT provocan interrupciones de servicio, aumento de incidentes y reportes de usuario difíciles de diagnosticar. Son especialmente críticos los entornos altamente disponibles sin replicación de estado: un failover puede implicar pérdida total de sesiones. Cambios en los timeouts o en el tamaño de conntrack sin monitorización pueden provocar problemas de recursos (swapping, OOM). Planifique por tanto cada cambio con medidas claras de monitorización y rollback.

Preparación antes de cambios

Antes de intervenir, siga una breve lista de comprobación:

• Haga copias de seguridad de ficheros de configuración, logs y métricas (snapshots/exportación).
• Identifique IPs/servicios afectados y planifique una ventana de mantenimiento si es necesario.
• Compruebe la RAM/CPU disponible en sus gateways (en función de recursos).
• Elabore una estrategia de reversión: vaciado selectivo vs reinicio global.
• Informe a los equipos afectados y defina canales de comunicación.

Pasos concretos de verificación y diagnóstico

La siguiente ruta de comprobación está priorizada por esfuerzo e información obtenida y es adecuada para gateways basados en Linux así como appliances con acceso a shell.

1) Recopilar datos básicos de conntrack

En gateways Linux conntrack es central. Determine entradas actuales, valor máximo y tiempos de espera:

# Aktuelle Anzahl der conntrack-Einträge
conntrack -L | wc -l

# Detaillierte Statistiken
conntrack -S

# Maximal erlaubte Einträge (Kernel-Parameter)
sysctl net.netfilter.nf_conntrack_max

# Beispiel: TCP Timeout (established)
sysctl net.netfilter.nf_conntrack_tcp_timeout_established

Por qué: Estos valores permiten evaluar rápidamente si existe un desbordamiento o timeouts excesivos. Observe los valores a lo largo del tiempo, no solo de forma puntual. Un pico breve puede no ser problemático; una tasa de creación sostenida y alta sí lo es.

2) Comprobar reglas NAT / de traducción

Liste sus reglas y contadores de NAT. En tablas grandes siempre filtre; en nftables la salida por defecto puede ser voluminosa.

# nftables
nft list ruleset

# iptables (NAT-Tabelle)
iptables -t nat -L -n -v

# Conntrack-Einträge filtern (z. B. nach öffentlicher IP)
conntrack -L | grep 203.0.113.5 | less

Por qué: Prioridades equivocadas de reglas o reglas duplicadas suelen causar asignaciones erróneas no evidentes. Verifique también las reglas de Masquerade/SNAT y sus interfaces para saber qué IPs se están traduciendo realmente.

3) Identificar PAT / agotamiento de puertos

Analice si una única IP pública tiene demasiados mapeos. Las colisiones de PAT ocurren cuando todos los puertos efímeros de origen disponibles de una IP están ocupados.

# Anzahl Übersetzungen für eine öffentliche IP
conntrack -L | grep 203.0.113.5 | wc -l

# Ephemeral-Port-Range
cat /proc/sys/net/ipv4/ip_local_port_range

Posibles mitigaciones: ampliar el pool de NAT, distribuir el tráfico saliente entre varios gateways, ajustar el rango de puertos efímeros o reestructurar aplicaciones que generan muchas conexiones de corta duración (connection pooling). Atención: la ampliación del rango de puertos solo ayuda si el problema es el número simultáneo de conexiones por IP de origen interna; con un número extremadamente elevado de clientes suele ser necesario añadir direcciones IP públicas adicionales o implementar un proxy de salida.

4) Comprobar enrutamiento asimétrico

El enrutamiento asimétrico significa que las solicitudes y las respuestas siguen rutas de red distintas. Dado que los dispositivos stateful asignan el tráfico de retorno a una entrada local de conntrack, el NAT falla si la respuesta llega a otro dispositivo.

# Capture am Gateway
tcpdump -n -i eth0 host 10.0.0.12 and tcp -w /tmp/gw.pcap

# Reverse capture am Zielhost
tcpdump -n -i eth0 host 203.0.113.5 and tcp -w /tmp/host.pcap

# Traceroute mit TCP
traceroute -T -p 443 8.8.8.8

Si los paquetes SYN llegan al Gateway A pero las respuestas regresan por el Gateway B, observará pérdida de estado. Corrija el enrutamiento, las políticas ECMP o active la replicación de estado (consulte la sección sobre conntrackd).

Resolución de problemas específica para firewalls

Firewalls stateful (dispositivos que almacenan estado) difieren en funciones detalladas. En appliances comerciales, revise las estadísticas de la GUI sobre NAT-mappings y conteo de sesiones; en gateways basados en Linux use las herramientas conntrack. Preste atención a los siguientes puntos:

• Contadores de sesiones por interfaz y por IP virtual (vIP) — ayudan en el análisis de agotamiento por PAT.
• Logs con motivos de drop (p. ej. „INVALID“ o „untracked reply“) — indican que el tráfico de retorno no encontró una sesión correspondiente.
• Comportamiento en HA: qué sesiones se replican y cuáles no; revise la estrategia de failover.

Revise en los logs también explícitamente los mensajes „invalid“; estos ayudan a identificar enrutamiento asimétrico o problemas por MSS/MTU mal configurados.

Consideraciones sobre recursos y rendimiento

Cada entrada de conntrack ocupa RAM. Empíricamente, las entradas de conntrack suelen consumir típicamente varios cientos de bytes por conexión; el valor exacto depende de la versión del kernel, de los módulos Netfilter activos y de helpers adicionales (p. ej. ftp helper). Por ello: aumente net.netfilter.nf_conntrack_max solo de forma controlada y supervise el uso de RAM y swap.

Indicadores del sistema importantes:

• RAM libre y uso de swap
• Load average (picos de corta duración durante sync/flush)
• Carga de CPU causada por conntrackd o por altas tasas de inserción en conntrack

Si usa conntrackd o replicación de estado, tenga en cuenta la carga adicional de red y las latencias: el tráfico de sincronización puede volverse significativo con muchas sesiones. Planifique y pruebe el ancho de banda de sincronización en laboratorio.

Monitoring mit Prometheus & Alerting (Praxisbeispiel)

El monitoring automático ayuda a detectar cuellos de botella de forma temprana. Muchos equipos exportan las cifras de conntrack mediante node-exporter textfile-collector o exportadores específicos de conntrack. Alertas importantes:

• Advertencia al 70% de nf_conntrack_max
• Crítico al 90% de nf_conntrack_max
• Rápida tasa de aumento en la creación de entradas de conntrack

Ejemplo de una Prometheus-Alert-Rule (como plantilla):

groups:
- name: conntrack.rules
  rules:
  - alert: ConntrackHigh
    expr: (conntrack_entries / conntrack_max) > 0.9
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Conntrack near capacity on {{ $labels.instance }}"
      description: "Conntrack entries at {{ $value }} of max; evaluate nf_conntrack_max or reduce connection churn."

Reemplace „conntrack_entries“ y „conntrack_max“ por las métricas del exporter que utilice. Automatice, ante advertencias, la captura de snapshot de las estadísticas de conntrack (p. ej. un cron que guarde conntrack -S en /var/log).

Packet-Capture-Analyse: Hinweise und Filter

Una habilidad importante es filtrar e interpretar correctamente los captures. Use tcpdump y tshark para investigar específicamente secuencias SYN/SYN-ACK o RST.

# SYN-only Capture (Gateway)
tcpdump -n -i eth0 'tcp[tcpflags] & (tcp-syn) != 0' -w /tmp/syns.pcap

# tshark: Zeige Gespräche mit fehlender SYN-ACK-Antwort
tshark -r /tmp/syns.pcap -q -z conv,tcp

Importante: compare captures en varios saltos (cliente, gateway, destino). Observe diferencias en TTL/identificación IP que indiquen por qué dispositivo pasó la ruta de retorno.

Architekturmaßnahmen gegen wiederkehrende Probleme

Si las causas no son solucionables a corto plazo, los cambios arquitectónicos tienen un efecto duradero:

• Ampliación del pool NAT: direcciones IP públicas adicionales evitan cuellos de botella por PAT.
• Egress-Proxies / Connection-Pooling: reducen el número de conexiones salientes de corta duración.
• Distribución de carga del tráfico saliente entre varios gateways (con enrutamiento simétrico).
• Replicación de estado en clústeres HA (conntrackd o soluciones integradas del appliance).

Valore el esfuerzo y la mantenibilidad: un Egress-Proxy puede minimizar cambios en la aplicación, pero añade operación adicional.

Checkliste für das Change-Window

Use esta lista de comprobación antes de cualquier cambio en producción:

• Realizar un snapshot de las estadísticas y configuraciones de conntrack.
• Notificar a los interesados y comunicar la duración del mantenimiento.
• Proporcionar scripts de prueba para verificar, tras el cambio, el establecimiento de conexiones y el comportamiento de las sesiones.
• Documentar por escrito los pasos de rollback (restablecer sysctl, revertir selectivamente reglas NAT).
• Aumentar la monitorización tras el cambio (reducir los intervalos de sondeo).

Runbook: procedimiento ampliado paso a paso

1. Identificar: servicios e IPs afectadas mediante registros y monitorización (p. ej. errores del servidor web, RTOs).
2. Recopilación de datos: conntrack -S, valores sysctl, reglas NAT, capturas de paquetes en Gateway&Host.
3. Análisis: comprobar agotamiento de PAT, asimetría, reglas NAT defectuosas o clientes con tráfico masivo.
4. Elegir medida: borrado selectivo, aumento temporal de nf_conntrack_max o ampliación del pool NAT.
5. Ejecutar: desplegar el cambio de forma incremental y vigilar estrechamente la monitorización.
6. Validar: retroalimentación de usuarios, monitorización, métricas nuevamente, y si procede, rollback.
7. Postmortem: documentación de la causa y las acciones, cambios en Alerting/Routing documentados.

Errores típicos y cómo evitarlos

• Cambios sin Snapshots: siempre exportar previamente configuraciones/logs.
• Aumentos descoordinados de nf_conntrack_max sin análisis de RAM.
• Ignorar el enrutamiento asimétrico: las capturas en varios puntos ahorran tiempo.
• No hacer pruebas en Staging: pruebe Timeouts/Sync-Comportamiento antes del despliegue en producción.
• Flush global sin comunicación: rompe sesiones de usuarios y puede afectar procesos de negocio.

Estrategias concretas de reversión

Planifique las siguientes opciones como rutas de reversión separadas y probadas:

• Rollback rápido: RESTablecer parámetros sysctl y reimplantar los Snapshots de configuración.
• Minimamente invasivo: eliminar selectivamente entradas problemáticas en lugar de reinicios globales.
• Arquitectura de Fallback: distribuir temporalmente el tráfico a Gateways secundarios (si es posible con enrutamiento simétrico).

Conclusión

Los errores de NAT y PAT provocan en entornos productivos fallos a menudo difíciles de diagnosticar. Un enfoque sistemático — recopilar métricas, capturas de paquetes dirigidas, ajuste incremental, flush selectivo y estrategias HA con replicación de estado — reduce considerablemente los riesgos. Configure alertas de monitorización, planifique recursos y pruebe los cambios en un entorno controlado. Con las rutas de comprobación, comandos y pasos del Runbook descritos aquí dispone de un conjunto de herramientas práctico para detectar y resolver de forma segura y duradera los errores de NAT y PAT.

Errores de NAT y PAT: arquitecturas HA, replicación de estado y riesgos de integración

Ante problemas recurrentes de NAT y PAT ayuda una visión arquitectónica: ¿cómo distribuye usted los estados, qué componentes deben sincronizarse y qué integraciones con otros servicios dificultan la resolución de problemas? Aquí ofrecemos indicaciones prácticas sobre replicación de estado, estrategias de prueba y trampas de integración que en entornos productivos con frecuencia se pasan por alto.

Replicación de estado: opciones y riesgos

La replicación de estado (p. ej. conntrackd en Gateways basados en Linux o mecanismos de sincronización específicos del proveedor) permite failover sin pérdida de sesión. Ventajas: menor interrupción de usuarios en un failover HA. Riesgos: tráfico de red adicional, latencia entre pares de sincronización y mayor complejidad en caso de split‑brain. Pruebe la latencia de sincronización y el ancho de banda requerido con números de sesión realistas antes de pasar a producción.

Pasos prácticos de comprobación para la replicación

• Mida el tiempo entre la inserción local y la visibilidad en el partner — aumente los búferes si la latencia provoca una divergencia de estado excesiva.
• Simule el failover bajo carga y verifique explícitamente la coherencia de las sesiones TCP de larga duración (p. ej. SSH, TLS).
• Asegure las configuraciones de sincronización: las claves, los mecanismos de autenticación y el cifrado del tráfico de sincronización suelen ser fuente de fallos.

Integración con balanceadores de carga, pools de NAT y proxies de salida

Si el tráfico saliente pasa por balanceadores de carga o proxies de salida, aumentan los requisitos sobre la afinidad de flujo (flow‑affinity / session‑stickiness) y sobre la asignación correcta de la IP de origen. Preste atención a algoritmos de hash consistentes y compruebe si los health checks de los balanceadores de carga generan conexiones propias que atan recursos PAT.

Herramientas de monitorización y pruebas que aportan valor real

Además de las estadísticas de conntrack, merecen la pena pruebas activas y extensiones de observabilidad:

# Conntrack-Snapshot mit Timestamp
timestamp=$(date -u +"%Y%m%dT%H%MZ")
conntrack -S > /var/log/conntrack-snapshot-$timestamp.log

# Selektives Löschen betroffener IPs (minimalinvasiv)
conntrack -D -s 10.0.0.12

Para analizar comportamientos más profundos, las herramientas eBPF pueden aportar temporalmente información adicional (p. ej. tasas de conexión o llamadas a funciones), sin necesidad de generar PCAPs completas:

# Einfacher eBPF-Count: Anzahl tcp_v4_connect-Aufrufe pro Prozess
bpftrace -e 'kprobe:tcp_v4_connect { @[comm] = count(); }'

Recomendaciones para pruebas y despliegues

• Canary‑Rollouts: aplique cambios en tiempos de espera, rangos de puertos o parámetros de sincronización primero a un pequeño grupo de GW.
• Comprobaciones sintéticas: compruebe de forma automatizada la capa de aplicación (persistencia de sesión HTTP), no solo que el TCP‑Handshake sea exitoso.
• Instantáneas automatizadas ante alertas: ante una advertencia, genere inmediatamente un conntrack‑snapshot y PCAPs breves para facilitar el trabajo forense.

Conclusión: planifique desde el principio la replicación del estado (State‑Replication), la integración con balanceadores de carga y los scripts de prueba. Esto reduce fallos no planificados por errores de NAT y PAT y hace que los rollouts sean manejables — incluso en entornos grandes y distribuidos.