top of page
Buscar

Entiendo NAT e IPsec: teoría y laboratorio con Cisco

  • jogofus
  • hace 24 minutos
  • 5 min de lectura

En mi día a día como arquitecto de redes me he visto con la necesidad de crear múltiples túneles VPN sin que se solaparan las redes o, por motivos de ofuscación, para que el otro peer no conociera nuestras redes internas.


NAT, como todos sabemos, es una técnica que modifica las direcciones IP de los paquetes cuando atraviesan un router o firewall. Se utiliza principalmente para permitir que múltiples dispositivos con direcciones IP privadas compartan una única dirección IP pública para acceder a Internet.

Pero salir a Internet no es su única finalidad, como veremos en el laboratorio posterior.


Pero primero, la teoría.


Qué es NAT

NAT (Network Address Translation) es el proceso por el cual un dispositivo de capa 3 reescribe las direcciones IP (y, en el caso de PAT, también los puertos de capa 4) en las cabeceras de los paquetes que lo atraviesan, manteniendo una tabla de estado que le permite revertir esa traducción en el sentido contrario.


Fíjate en la definición: lo esencial no es "cambiar una IP por otra", es mantener una tabla que permita deshacer el cambio en el retorno. Sin esa tabla no hay NAT, hay solo un router que destroza paquetes.


El problema que resuelve

Dos problemas históricamente distintos:

  1. Agotamiento de IPv4. El espacio de 32 bits (~4.300 millones de direcciones) era insuficiente. La RFC 1918 reservó rangos privados —10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16— no enrutables en Internet. NAT es lo que permite que cientos de hosts con direcciones privadas compartan unas pocas IP públicas. Esta es la razón por la que NAT está en todas partes.

  2. Independencia del proveedor / solapamiento de redes. Poder cambiar de ISP sin readireccionar toda la red interna, o fusionar dos empresas que ambas usan 192.168.1.0/24.


Cómo funciona mecánicamente

Un router haciendo NAT, cuando un paquete lo atraviesa, ejecuta esto:

1. El paquete llega a la interfaz.

2. El router determina la DIRECCIÓN del flujo (inside→outside u outside→inside)

según qué interfaces estén marcadas como 'ip nat inside' / 'ip nat outside'.

3. Busca (o crea) una entrada en la TABLA DE TRADUCCIÓN.

4. Reescribe los campos correspondientes de la cabecera IP (y TCP/UDP en PAT).

5. RECALCULA los checksums:

- Checksum de la cabecera IP (porque cambió la IP).

- Checksum de TCP/UDP (porque el pseudo-header incluye las IPs, y en PAT el puerto).

6. Reenvía el paquete.


El paso 5 es el que la gente olvida que existe: cambiar una IP obliga a recalcular checksums en dos capas, porque el checksum de TCP/UDP se computa sobre un pseudo-header que incluye las direcciones IP de origen y destino. Por eso NAT es un proceso de capa 3-4, no solo de capa 3.

La terminología de Cisco

Cada nombre tiene dos palabras, y cada palabra responde a una pregunta distinta:

  • inside / outside → ¿de quién es la dirección? ¿El host al que pertenece está en el lado interior o en el exterior?

  • local / global → ¿desde dónde la estás mirando? local = tal como se ve dentro del dominio interior. global = tal como se ve dentro del dominio exterior.


El mismo host del interior tiene dos nombres: Inside Local (su nombre de verdad, como lo conocen sus vecinos internos) e Inside Global (su nombre tal como lo ve Internet, tras la traducción).


Definición oficial de cada una

  • Inside Local (IL): dirección del host interior tal como se la conoce dentro. Normalmente la privada RFC 1918. Es la real del host.

  • Inside Global (IG): dirección con la que ese host interior se presenta al exterior, después de traducir. Normalmente la pública asignada por el ISP.

  • Outside Global (OG): dirección del host exterior tal como existe en el exterior. Su dirección real y registrada.

  • Outside Local (OL): dirección del host exterior tal como se la ve desde el interior. Suele coincidir con OG... salvo que estés haciendo outside NAT.

Manos a la obra: laboratorio IPsec y NAT


Este es el escenario que vamos a cubrir:



Primero configuraremos la VPN site-to-site en ambos routers. En esta configuración vamos a centrarnos en hacer un VTI y no en policy-based, por lo que no deberemos olvidarnos de las rutas.


R1:

Primero configuramos la phase1.

crypto ikev2 proposal PROP-TUN0 
 encryption aes-cbc-256
 integrity sha256
 group 14
!         
crypto ikev2 policy POL-TUN0 
 proposal PROP-TUN0
!
crypto ikev2 keyring PSK-TUN0
 peer R2
  address 10.0.0.2
  pre-shared-key Aa12345678
 !
!
!
crypto ikev2 profile PROF-TUN0
 match identity remote address 10.0.0.2 255.255.255.255 
 authentication remote pre-share
 authentication local pre-share
 keyring local PSK-TUN0
!

Ahora configuramos la phase2.

crypto ipsec transform-set TS-TUN0 esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile IPSEC-PROF-TUN0
 set transform-set TS-TUN0 
 set ikev2-profile PROF-TUN0

Procedemos a crear la interfaz que va a servir para el tunel VPN: 

interface Tunnel0
 ip address 172.17.0.1 255.255.255.255
 ip mtu 1400
 ip nat outside
 ip virtual-reassembly in
 ip tcp adjust-mss 1360
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 10.0.0.2
 tunnel protection ipsec profile IPSEC-PROF-TUN0
!

Debemos recordar que la interfaz del tunel debe tener IP o si no no levantará el túnel.


R2:

crypto ikev2 proposal PROP-TUN0 
 encryption aes-cbc-256
 integrity sha256
 group 14
!         
crypto ikev2 policy POL-TUN0 
 proposal PROP-TUN0
!
crypto ikev2 keyring PSK-TUN0
 peer R1
  address 10.0.0.1
  pre-shared-key Aa12345678
 !
!
!
crypto ikev2 profile PROF-TUN0
 match identity remote address 10.0.0.1 255.255.255.255 
 authentication remote pre-share
 authentication local pre-share
 keyring local PSK-TUN0
!
!
!
crypto ipsec transform-set TS-TUN0 esp-aes 256 esp-sha256-hmac 
 mode tunnel
!
crypto ipsec profile IPSEC-PROF-TUN0
 set transform-set TS-TUN0 
 set ikev2-profile PROF-TUN0
!
interface Tunnel0
 ip address 172.16.0.1 255.255.255.255
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 10.0.0.1
 tunnel protection ipsec profile IPSEC-PROF-TUN0

Siguiente paso, crear el NAT en R1. Para ello, primero debemos decirle que interfaz es la de entrada y cual la de salida del NAT.

interface Ethernet0/0
 description WAN
 ip address 10.0.0.1 255.255.255.252
 duplex auto
!
interface Ethernet0/1
 description LAN
 ip address 192.168.100.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 duplex auto
!

Ahora creamos el el NAT estático. Si quisieramos que fuera solo de salida y no que respondieran igualmente a la misma red nateada, coincidiendo el último octeto, usaríamos un pool con el siguiente comando:

ip nat pool NAT-POOL 10.10.10.0 10.10.10.255 netmask 255.255.255.0 type match-host

Una vez creada la regla de NAT debemos decirle cuando se aplica, con un access-list extendida.


ip access-list extended NAT-VPN
 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
!

Comprobación del laboratorio

Para empezar, voy a hacer un ping tanto desde la IP 192.168.100.20 como de la IP 192.168.100.125 y veremos en el tcpdump como llegan nateadas.



Como vemos, las IP llegan nateadas pero conservando el ultimo octeto, conocido como one-to-one o 1:1.


Aquí debo hacer un pequeño disclaimer, y es que en Fortigate el concepto one-to-one lo que hace es asociar una IP del pool a una IP interna, pero por orden de llegada. Es decir, si la IP .125 llega antes, se llevaría la IP 10.10.10.2 y la siguiente que establezca conexión se llevaría la .3 y así consecutivamente.


Espero que os sirva de ayuda.

¡Nos vemos en las siguientes!

 
 
 

Comentarios

bottom of page