Pruebas de DHCP detrás de NAT/PAT
Fecha: 24 de noviembre del 2015 Clase: CCNA4 R&S
Escenario
Este escenario pretende analizar el comportamiento de una transacción DHCP mediante dhcp-relay, pero en la interface inside
de un router ejecutando NAT/PAT, como podría ser por ejemplo, teléfonos IP en una oficina y obteniendo direcciones IP en el
call manager del proveedor publicado en internet (por ejemplo el servicio de Iplan IUNI).
Si bien es un caso extremo, ya que los teléfonos podrían obtener la dirección IP internamente, o tener IP fija, aquí se analiza
puntualmente el paquete de relay-dhcp y NAT/PAT.
Configuración:
El escenario tiene una configuración bastante simple de PAT y DHCP en el CME publicado en internet.
Gateway(config)#interface GigabitEthernet0/0
Gateway(config-if)#ip address 192.168.0.1 255.255.255.0
Gateway(config-if)#ip nat inside
Gateway(config-if)#ip helper-address 200.0.0.2 (relay DHCP)
Gateway(config-if)#exit
Gateway(config)#interface GigabitEthernet0/1
Gateway(config-if)#ip address 200.0.0.1 255.255.255.252
Gateway(config-if)#ip nat outside
Gateway(config-if)#exit
Gateway(config)#access-list 10 permit 192.168.0.0 0.0.0.255
Gateway(config)#ip nat inside source list 10 interface
GigabitEthernet0/1 overload
Gateway(config)#end
Gateway#
CME_DHCP#conf t
CME_DHCP(config)#interface
FastEthernet0/1
CME_DHCP(config-if)#ip address 200.0.0.2
255.255.255.252
CME_DHCP(config-if)#exit
CME_DHCP(config)#ip dhcp pool DHCP
CME_DHCP(dhcp-config)#network
192.168.0.0 255.255.255.0
CME_DHCP(dhcp-config)#default-router
192.168.0.1
CME_DHCP(dhcp-config)#end
CME_DHCP#
Verificación inicial:
Verificamos que el router recibe peticiones broadcast de DHCP DISCOVER a través de la interface Gi0/0, a estas no se les
realiza NAT/PAT sino que se reenvían al CME como unicast generado en la interface inside.
Este tráfico coincide con la ACL del servicio PAT y el tráfico se traduce (se natea) a la IP pública de la interface Gi0/1.
El router CME recibe la petición DHCP desde la IP de origen 200.0.0.1 (interface Gi0/1) pero no le responde a esta sino a
la dirección 192.168.0.1, que es la dirección de la interface que recibe el DHCP DISCOVER.
Esta solicitud, al ser datos de layer 7, no se someten al proceso de NAT/PAT, por lo tanto la IP de quien realiza el relay no
se modifica.
Si hubiese un commando para traducer este registro, el CME no buscaría direcciones disponibles para ofrecer en el pool
correspondiente a la red 192.168.0.0/24, sino a la red 200.0.0.0/30, lo cual no es factible, no por IP disponibles, ni por ser
direcciones IP útiles para los teléfonos en la LAN interna.
Gateway#sh ip nat trans
Pro
Inside
global Inside local Outside local Outside global
icmp 200.0.0.1:5 192.168.0.1:5 200.0.0.2:5 200.0.0.2:5
icmp 200.0.0.1:6 192.168.0.1:6 200.0.0.2:6 200.0.0.2:6
udp 200.0.0.1:68
192.168.0.1:68
200.0.0.2:67 200.0.0.2:67
Gateway#
CME_DHCP#sh ip dhcp bind
IP address
Client-ID/
Lease expiration Type
Hardware address
CME_DHCP#
Como en la realidad el router tiene la red 200.0.0.0/30 directamente conectada y una default route hacia internet, no tiene
manera de responder las peticiones DHCP, o como mucho las responde hacia internet, pero esto no cumple con un esquema
de direccionamiento IP público como se especifica en la RFC 1918 y por lo tanto se descartará.
Pero lo importante para nosotros es que el Gateway nunca recibe las respuestas de DHCP OFFER, al menos que inventemos
algo del lado del CME para que responda hacia 200.0.0.1.
Modificaciones:
CME_DHCP(config)#ip route 192.168.0.0
255.255.255.0 200.0.0.1
Nueva verificación:
CME_DHCP#sh ip dhcp bind
IP address
Client-ID/
Lease expiration Type
Hardware address
192.168.0.2 0090.2167.BCE4 -- Automatic
CME_DHCP#
Mejoras para internet:
Para evitar que tráfico privado (con destino a 192.168.0.1) sea reenviado por internet, y en caso de que en Gateway tengamos una
ACL que deniegue todo tráfico proveniente desde internet con hacia una IP privada (tipo anti-spoofing o similar que cumpla con la
RFC 1918), podríamos levantar un túnel entre el CME y Gateway, aunque esto dependería del proveedor de telefonía y sería
impracticable el caso de implementar un túnel para cada cliente.
Pero esto es un caso de estudio y lo vamos a realizar.
Gateway#conf t
Gateway(config)#int tunnel 0
Gateway(config-if)#ip add 10.0.0.1 255.255.255.252
Gateway(config-if)#tunnel source gi0/1
Gateway(config-if)#tunnel destination 200.0.0.2
%LINK-5-CHANGED: Interface Tunnel0, changed
state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface
Tunnel0, changed state to up
Gateway(config-if)#exit
Gateway(config)#router eigrp 100
Gateway(config-router)#net 192.168.0.0 0.0.0.255
Gateway(config-router)#net 10.0.0.0 0.0.0.3
Gateway(config-router)#end
Gateway#
CME_DHCP#conf t
CME_DHCP(config)#int tunnel 0
CME_DHCP(config-if)#ip add 10.0.0.2
255.255.255.252
CME_DHCP(config-if)#tunnel
source Fa0/1
CME_DHCP(config-if)#tunnel
destination 200.0.0.1
%LINK-5-CHANGED: Interface Tunnel0, changed
state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface
Tunnel0, changed state to up
CME_DHCP(config-if)#exit
CME_DHCP(config)#router eigrp 100
CME_DHCP(config-router)#net
10.0.0.0 0.0.0.3
%DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor
10.0.0.1 (Tunnel0) is up: new adjacency
CME_DHCP(config-router)#exit
Eliminamos la ruta que lleva el tráfico a través de internet:
CME_DHCP(config)#no ip route 192.168.0.0 255.255.255.0 200.0.0.1
CME_DHCP(config)#end
CME_DHCP#
Verificación del enrutamiento:
CME_DHCP#sh ip route
---resumido---
10.0.0.0/30 is subnetted, 1 subnets
C
10.0.0.0 is directly connected, Tunnel0
D 192.168.0.0/24 [90/26882560] via 10.0.0.1,
00:00:46, Tunnel0
200.0.0.0/30 is subnetted, 1 subnets
C 200.0.0.0
is directly connected, FastEthernet0/1
CME_DHCP#
Verificación del DHCP:
CME_DHCP#sh ip dhcp bind
IP address
Client-ID/ Lease
expiration Type
Hardware address
192.168.0.2
0090.2167.BCE4 -- Automatic
CME_DHCP#
(2015) Sensei , St. Claus will
distribute DHCP packets ?
Rosario, Argentina