🔀 Lab 11: NAT — Cómo se "disfraza" tu IP¶

En el lab anterior usaste iptables para filtrar tráfico. Ahora vas a usarlo de una forma diferente: traducir IPs.

Hasta ahora todos tus labs usaron IPs privadas (192.168.x.x, 10.x.x.x). Esas IPs no existen en Internet — son solo válidas dentro de tu red. Entonces, ¿cómo hace tu PC para hablar con Google si tiene una IP privada?

La respuesta es NAT (Network Address Translation): el router reemplaza tu IP privada por su propia IP antes de mandar el paquete afuera. Cuando llega la respuesta, hace el proceso inverso y te la entrega.

Tu PC                 Router                  Servidor
192.168.1.2  ──────▶  [NAT]  ──────▶  10.0.0.1 → 10.0.0.2
                    reemplaza
                  192.168.1.2
                  por 10.0.0.1

En este lab vas a configurar NAT vos mismo con iptables para entender exactamente qué pasa. En el próximo lab el nodo CLOUD lo hace automáticamente — pero primero tenés que entender qué hace.

🏗️ Topología del Laboratorio¶

Copia y pega este YAML en Topología → Importar:

name: "lab-08-nat"
nodes:
  - name: PC-Interna
    type: HOST
    x: 100
    y: 200
  - name: ROUTER-NAT
    type: ROUTER
    x: 350
    y: 200
  - name: PC-Servidor
    type: HOST
    x: 600
    y: 200
links:
  - source: PC-Interna
    target: ROUTER-NAT
  - source: ROUTER-NAT
    target: PC-Servidor

Dos redes: - Red interna: 192.168.1.0/24 — PC-Interna y el router - Red externa: 10.0.0.0/30 — PC-Servidor y el router

🛠️ Paso 1: Configurar IPs¶

En PC-Interna:

ip addr add 192.168.1.10/24 dev eth1
ip link set eth1 up
ip route add default via 192.168.1.1

En ROUTER-NAT:

ip addr add 192.168.1.1/24 dev eth1
ip addr add 10.0.0.1/30 dev eth2
ip link set eth1 up
ip link set eth2 up

En PC-Servidor:

ip addr add 10.0.0.2/30 dev eth1
ip link set eth1 up
ip route add default via 10.0.0.1

❌ Paso 2: Sin NAT — el servidor no puede responder¶

Desde PC-Interna, hacé ping a PC-Servidor:

ping -c 3 10.0.0.2

Funciona porque es una red directamente conectada al router. Pero ahora hacé clic derecho en el cable que une ROUTER-NAT con PC-Servidor, seleccioná Sniff ROUTER-NAT, y fijate: el paquete llega al servidor con IP origen 192.168.1.10.

Eso está bien en este lab porque PC-Servidor tiene ruta de vuelta. Pero en Internet real, ningún servidor sabe cómo responder a 192.168.1.10 — esa IP no existe en Internet.

🔑 Paso 3: Activar NAT con iptables¶

Primero habilitá el IP forwarding (que el router reenvíe paquetes entre interfaces):

# En ROUTER-NAT
echo 1 > /proc/sys/net/ipv4/ip_forward

Ahora configurá la regla NAT. MASQUERADE significa: "reemplazá la IP origen por la IP de la interfaz de salida":

# En ROUTER-NAT
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

🔬 Paso 4: Ver la traducción en acción¶

Hacé clic derecho en el cable que une ROUTER-NAT con PC-Servidor, seleccioná Sniff ROUTER-NAT, y hacé ping desde PC-Interna:

# En PC-Interna
ping -c 3 10.0.0.2

Observá en la captura: los paquetes ahora salen con IP origen 10.0.0.1 (la IP del router), no 192.168.1.10. PC-Servidor nunca ve la IP privada — para él, el cliente es 10.0.0.1.

🧾 Paso 5: Ver las reglas NAT activas¶

# En ROUTER-NAT
iptables -t nat -L -n -v

Verás la regla MASQUERADE y un contador que aumenta con cada paquete que traduce.

🔄 Paso 6: Entender el proceso inverso¶

Cuando PC-Servidor responde a 10.0.0.1, el router recibe ese paquete y sabe que debe entregárselo a 192.168.1.10 — porque tiene una tabla interna que registra qué conexión salió de quién. Ese mecanismo se llama NAT table o conntrack:

# En ROUTER-NAT
cat /proc/net/nf_conntrack

Verás entradas como:

tcp ... src=192.168.1.10 dst=10.0.0.2 ... src=10.0.0.2 dst=10.0.0.1 ...

El kernel registra: "la conexión de 192.168.1.10 salió como 10.0.0.1 — cuando llegue la respuesta, devolvérsela a 192.168.1.10".

💡 Concepto Clave: NAT no es magia — es una tabla de traducciones que el router mantiene por cada conexión activa. En el próximo lab verás que el nodo CLOUD hace exactamente esto, pero de forma automática.