NAT, acceso a Internet y publicación de servicios en redes de computadoras

¿Qué es NAT y qué problema resuelve?

NAT (Network Address Translation) es una función del router/firewall que modifica direcciones IP en los paquetes cuando cruzan entre una red privada y otra red (típicamente Internet). Su uso más común es permitir que múltiples equipos con IP privadas salgan a Internet usando una sola IP pública. En la práctica, NAT suele ir acompañado de reglas de filtrado (firewall), pero son conceptos distintos: NAT traduce; el firewall permite o bloquea.

NAT vs. PAT (NAT con puertos)

En entornos domésticos y empresariales, lo más habitual es PAT (Port Address Translation), también llamado “NAT overload”. Además de cambiar la IP de origen, el dispositivo cambia el puerto de origen para poder multiplexar muchas conexiones internas sobre una sola IP pública.

• NAT 1:1 (estático): una IP privada se traduce siempre a una IP pública específica.
• NAT dinámico: un conjunto de IP privadas se traduce a un pool de IP públicas disponibles.
• PAT (muchos a 1): muchas IP privadas comparten una IP pública diferenciándose por puertos.

Efectos de NAT en visibilidad y trazabilidad

• Visibilidad desde Internet: por defecto, una red con NAT no es “alcanzable” desde fuera; las conexiones entrantes no saben a qué host interno ir, salvo que se configure una publicación (port forwarding/reverse proxy) o NAT 1:1.
• Trazabilidad: desde el exterior, varias máquinas internas pueden “parecer” la misma IP pública. Para atribuir una conexión a un host interno, se necesitan logs del dispositivo NAT (mapeos IP:puerto interno ↔ IP pública:puerto externo) y marcas de tiempo precisas.
• Protocolos y aplicaciones: algunas aplicaciones que “anuncian” IP/puertos dentro del payload pueden fallar si el NAT no hace inspección/ayuda (ALG). En servidores, se prefiere evitar dependencias de ALG y usar configuraciones explícitas.

Casos de uso: salida a Internet para servidores y redes privadas

1) Servidores internos que necesitan salir a Internet

Escenario típico: servidores en una subred privada que requieren actualizaciones, repositorios, APIs externas o sincronización con servicios cloud. Con PAT, el tráfico saliente se traduce a la IP pública del perímetro.

Implicaciones prácticas:

• Si un proveedor externo restringe por IP (allowlist), verá la IP pública, no la IP privada del servidor.
• Si varios servidores salen por la misma IP pública, un bloqueo por reputación o rate limiting puede afectar a todos.
• Para auditoría, conviene registrar en el firewall/NAT: IP interna origen, destino, puerto, NAT aplicado y timestamp.

2) Redes privadas “no enrutable” hacia Internet

NAT se usa para mantener direcciones privadas internas sin exponerlas ni anunciarlas hacia Internet. Esto simplifica el diseño perimetral, pero introduce una frontera donde la conectividad entrante requiere configuración explícita.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Publicación de servicios: port forwarding y reverse proxy (conceptual)

Port forwarding (DNAT)

El port forwarding (técnicamente DNAT: Destination NAT) publica un servicio interno mapeando un puerto de la IP pública a un host/puerto privado. Ejemplo conceptual: IP_publica:443 → 10.0.0.10:443.

Características:

• Simple y directo: el cliente se conecta a la IP pública y el NAT redirige al servidor interno.
• La seguridad depende de reglas de firewall asociadas (permitir solo orígenes necesarios, limitar puertos, etc.).
• El servidor interno verá como origen la IP real del cliente si el NAT no hace SNAT adicional en el camino; en algunos diseños, el origen puede verse como la IP del gateway (depende del flujo y del dispositivo).

Reverse proxy (a nivel conceptual)

Un reverse proxy es un servidor intermedio (por ejemplo, un proxy HTTP) que recibe conexiones desde Internet y las reenvía a uno o varios servidores internos. A diferencia del port forwarding “puro”, el reverse proxy opera a nivel de aplicación (por ejemplo, HTTP/HTTPS) y puede decidir el backend por hostname, ruta, cabeceras, etc.

Ventajas típicas:

• Publicar múltiples sitios/servicios web detrás de una sola IP/puerto (por ejemplo, varios dominios en 443).
• Centralizar TLS, autenticación, límites de tasa y registros.
• Mejor control de observabilidad: logs de acceso en el proxy y, si se configura, preservación de IP cliente mediante cabeceras (p. ej., X-Forwarded-For).

Consideración clave: si hay reverse proxy, el servidor backend puede ver como origen la IP del proxy, no la del cliente, a menos que se reenvíe y se confíe correctamente la IP original.

Guía práctica: comprobar si tu salida a Internet está bajo NAT y cuál es tu IP pública

Paso 1: identificar la IP “vista” desde Internet

Desde un servidor interno, consulta tu IP pública:

curl -s https://ifconfig.me

Guarda el resultado: esa es la IP que verán servicios externos (salvo proxies intermedios).

Paso 2: comparar con la IP del servidor y el gateway

Si la IP del servidor es privada y la IP pública es distinta, hay NAT en algún punto. Si además tu gateway no es el dispositivo que tiene la IP pública (por ejemplo, hay un router del ISP delante), puedes estar en doble NAT.

Paso 3: validar ruta y primer salto

Ejecuta un traceroute hacia un destino público:

traceroute 1.1.1.1

El primer salto suele ser tu gateway. Si los siguientes saltos son redes privadas (por ejemplo, 10.0.0.0/8 o 192.168.0.0/16) antes de salir a Internet, es una pista de NAT adicional aguas arriba.

Guía práctica: publicar un servicio interno con port forwarding (paso a paso conceptual)

Objetivo: exponer un servicio interno (por ejemplo, TCP 443) hacia Internet.

Paso 1: confirmar que el servicio funciona en la red interna

Desde otra máquina dentro de la misma red (o desde una red interna que enrute al servidor), prueba el puerto:

nc -vz 10.0.0.10 443

Si falla internamente, no continúes: primero corrige el servicio o el firewall local del servidor.

Paso 2: definir el mapeo de publicación

• Entrada: IP pública del perímetro y puerto externo (ej.: 443).
• Destino: IP privada del servidor y puerto interno (ej.: 10.0.0.10:443).

Esto se implementa como DNAT/port forward en el router/firewall.

Paso 3: crear la regla de firewall asociada

Además del NAT, necesitas permitir el tráfico entrante al puerto publicado. Buenas prácticas:

• Permitir solo orígenes necesarios (si aplica).
• Registrar (log) los intentos permitidos y denegados durante la fase de pruebas.
• Evitar publicar puertos administrativos directamente (por ejemplo, SSH) sin controles adicionales.

Paso 4: probar desde fuera (imprescindible)

La prueba debe hacerse desde una red externa (por ejemplo, un móvil con datos o una VM en la nube). Prueba conectividad por puerto:

nc -vz TU_IP_PUBLICA 443

Si es HTTP/HTTPS, valida respuesta:

curl -I https://TU_IP_PUBLICA

Paso 5: considerar hairpin NAT (pruebas desde dentro usando IP pública)

Si desde dentro intentas acceder a TU_IP_PUBLICA:443 y falla, no significa necesariamente que la publicación esté mal. Puede faltar hairpin NAT (NAT loopback), que permite que clientes internos accedan al servicio usando la IP pública y vuelvan a entrar por el NAT hacia el servidor interno. Soluciones típicas:

• Habilitar hairpin NAT en el firewall/router (si lo soporta).
• Usar resolución interna (split-horizon) para que el nombre apunte a la IP privada cuando se consulta desde dentro.

Administración y operación: logs, pruebas y trazabilidad

Impacto en registros (logs)

• En el servidor publicado: registra IP origen, puerto, timestamp, y si hay proxy, registra cabeceras de IP real (y configura la confianza solo para IPs del proxy).
• En el NAT/firewall: habilita logs de reglas de DNAT y de políticas de entrada/salida. Para trazabilidad con PAT, es crítico registrar traducciones de puertos (mapeos) y sincronizar hora (NTP ya tratado en capítulos previos).
• Correlación: ante un incidente, correlaciona “hora + IP pública + puerto externo” con el mapeo NAT para identificar el host interno.

Checklist de pruebas desde dentro y fuera

Cómo distinguir problemas de NAT vs. firewall vs. DNS (enfoque de diagnóstico)

1) Síntoma: “Desde dentro funciona, desde fuera no”

• Probable firewall de entrada: el puerto no está permitido en la interfaz WAN.
• Probable NAT/DNAT mal configurado: el port forward apunta a IP/puerto incorrectos o a un host distinto.
• Menos probable: servicio: si internamente funciona de forma consistente, el servicio está bien; el problema suele estar en el perímetro.

2) Síntoma: “Desde fuera el puerto aparece cerrado/filtrado”

• Firewall: regla de denegación o falta de regla de permiso.
• NAT: no existe DNAT para ese puerto, o está en otra IP pública.
• ISP/Upstream: algunos proveedores bloquean puertos comunes (p. ej., 25) o hay CGNAT (no tienes IP pública enrutable real).

3) Síntoma: “Resuelve a una IP, pero conecta a otro sitio o falla”

• DNS: el nombre apunta a una IP equivocada o antigua (TTL/caché). Aunque DNS se vio antes, aquí el enfoque es operativo: confirma que el nombre apunte a tu IP pública actual y que no haya discrepancias entre resolución interna y externa.
• NAT: si tienes múltiples IP públicas, el servicio puede estar publicado en una distinta a la que apunta el nombre.

4) Síntoma: “Desde dentro usando el nombre público falla, pero desde fuera funciona”

• Hairpin NAT ausente: típico en routers simples.
• Split-horizon: si existe, revisa que la resolución interna apunte al destino correcto.

Ejercicios de diagnóstico (prácticos y verificables)

Ejercicio 1: confirmar IP pública y detectar doble NAT

• En un servidor interno, ejecuta: curl -s https://ifconfig.me y anota la IP.
• Ejecuta: traceroute 1.1.1.1 y observa si aparecen saltos con IP privadas antes de salir a Internet.
• Interpreta: si hay varios segmentos privados antes de un salto público, documenta la hipótesis de doble NAT (router propio + router ISP o CGNAT).

Ejercicio 2: prueba por puerto desde fuera (validación de publicación)

• Elige un puerto a publicar (por ejemplo, 8080 hacia un servicio interno temporal).
• Desde una red externa, ejecuta: nc -vz TU_IP_PUBLICA 8080.
• Si falla, revisa en este orden: (1) regla de firewall WAN, (2) DNAT/port forward, (3) servicio escuchando en el host interno, (4) firewall local del servidor.

Ejercicio 3: diferenciar “NAT” de “firewall” con observación de logs

• Habilita logs en la regla de firewall que permitiría el puerto publicado y en la regla de DNAT correspondiente.
• Realiza un intento de conexión desde fuera.
• Interpreta: si ves hits en firewall pero no en DNAT (o viceversa), hay inconsistencia de reglas o el tráfico está llegando por otra interfaz/IP pública.

Ejercicio 4: verificación de IP pública efectiva para allowlists

• Desde el servidor que consumirá un API externo con restricción por IP, ejecuta: curl -s https://ifconfig.me.
• Configura esa IP en la allowlist del proveedor.
• Si el proveedor sigue bloqueando, verifica si tu salida usa múltiples IP públicas (balanceo) o si hay un proxy de salida; documenta evidencia con timestamps y logs del firewall.

Ejercicio 5: matriz rápida de diagnóstico (NAT vs firewall vs DNS)

Completa esta matriz con tus resultados reales: