Orden de Funcionamiento de NAT

Opciones de descarga

PDF (100.9 KB)
Visualice con Adobe Reader en una variedad de dispositivos
ePub (83.9 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (90.9 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos

Actualizado:30 de septiembre de 2008

ID del documento:6209

Contenido

Introducción

prerrequisitos

Requisitos

Componentes Utilizados

Convenciones

Descripción general de NAT

Configuración y resultado de NAT

Información Relacionada

Introducción

Este documento ilustra que la orden en la cual las transacciones se procesan usando el Network Address Translation (NAT) está basada encendido si un paquete va de la red interna a la red externa, o de la red externa a la red interna.

prerrequisitos

Requisitos

Los Quien lea este documento deben tener conocimiento de este tema:

Network Address Translation (NAT). Para más información sobre el NAT, vea cómo el NAT trabaja.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Note: La información en este documento se basa en la versión de software, Software Release 12.2(27) de Cisco IOS®

Convenciones

Consulte Convenciones de Consejos Técnicos de Cisco para obtener más información sobre las convenciones sobre documentos.

Descripción general de NAT

En esta tabla, cuando el NAT realiza el global al local, o el local a global, la traducción es diferente en cada flujo.

Dentro-a-exterior	De afuera hacia adentro
Si IPSec, verifique la lista de acceso de entrada desciframiento - para CET (tecnología de encripción de Cisco) o el IPSec verificar lista de acceso de entrada revise los límites de velocidad de entrada contabilidad de entrada redirección al caché de la Web ruteo de política ruteo NAT dentro al exterior (local a la traducción global) crypto (mapa de control y marca para el encripción) control de lista de accesos de salida examine (Control de acceso basado en el contexto (CBAC)) Intercepción de tráfico de TCP cifrado Cola	Si IPSec, verifique la lista de acceso de entrada desciframiento - para el CET o el IPSec verificar lista de acceso de entrada revise los límites de velocidad de entrada contabilidad de entrada redirección al caché de la Web NAT afuera ante el interior (global a la traducción local) ruteo de política ruteo crypto (mapa de control y marca para el encripción) control de lista de accesos de salida examine el CBAC Intercepción de tráfico de TCP cifrado Cola

Dentro-a-exterior

De afuera hacia adentro

Si IPSec, verifique la lista de acceso de entrada
desciframiento - para CET (tecnología de encripción de Cisco) o el IPSec
verificar lista de acceso de entrada
revise los límites de velocidad de entrada
contabilidad de entrada
redirección al caché de la Web
ruteo de política
ruteo
NAT dentro al exterior (local a la traducción global)
crypto (mapa de control y marca para el encripción)
control de lista de accesos de salida
examine (Control de acceso basado en el contexto (CBAC))
Intercepción de tráfico de TCP
cifrado
Cola

Si IPSec, verifique la lista de acceso de entrada
desciframiento - para el CET o el IPSec
verificar lista de acceso de entrada
revise los límites de velocidad de entrada
contabilidad de entrada
redirección al caché de la Web
NAT afuera ante el interior (global a la traducción local)
ruteo de política
ruteo
crypto (mapa de control y marca para el encripción)
control de lista de accesos de salida
examine el CBAC
Intercepción de tráfico de TCP
cifrado
Cola

Configuración y resultado de NAT

Este ejemplo demuestra cómo la orden de funcionamiento puede efectuar el NAT. En este caso, sólo se muestran NAT y ruteo.

En el ejemplo anterior, el Router A se configura para traducir a la dirección local interna 171.68.200.48 a 172.16.47.150, tal y como se muestra en de esta configuración.

!
version 11.2
no service udp-small-servers
no service tcp-small-servers
!
hostname Router-A
!
enable password ww
!
ip nat inside source static 171.68.200.48 172.16.47.150

!--- This command creates a static NAT translation !--- between 171.68.200.48 and 172.16.47.150 

ip domain-name cisco.com
ip name-server 171.69.2.132
!
interface Ethernet0
 no ip address
 shutdown
!
interface Serial0
 ip address 172.16.47.161 255.255.255.240
 ip nat inside

!--- Configures Serial0 as the NAT inside interface

 no ip mroute-cache
 no ip route-cache
 no fair-queue
!
interface Serial1
 ip address 172.16.47.146 255.255.255.240
 ip nat outside

!--- Configures Serial1 as the NAT outside interface

 no ip mroute-cache
 no ip route-cache
!
no ip classless
ip route 0.0.0.0 0.0.0.0 172.16.47.145

!--- Configures a default route to 172.16.47.145


ip route 171.68.200.0 255.255.255.0 172.16.47.162
!
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 password ww
 login
!
end

La tabla de traducción indica que existe la traducción prevista.

Router-A#show ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.47.150      171.68.200.48      ---                ---

Esta salida se toma del Router A con habilitado nacional del IP del detalle del paquete y del debug del IP del debug, y un ping se publica del dispositivo 171.68.200.48 destinada para 172.16.47.142.

Note: Los comandos Debug generan una cantidad significativa de resultados. Utilícelos sólo cuando el tráfico en la red del IP es lento, con el fin de que no se vea afectada negativamente otra actividad del sistema. Antes de que usted publique los comandos debug, refiera la información toImportant sobre los comandos Debug.

IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=172.16.47.161 (local), d=171.68.200.48 (Serial0), len 56, sending
    ICMP type=3, code=1
IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=172.16.47.161 (local), d=171.68.200.48 (Serial0), len 56, sending
    ICMP type=3, code=1
IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=172.16.47.161 (local), d=171.68.200.48 (Serial0), len 56, sending
    ICMP type=3, code=1

Puesto que no hay mensajes del debug NAT en la salida anterior, usted sabe que la traducción estática existente no está utilizada y que el router no tiene una ruta para la dirección destino (172.16.47.142) en su tabla de ruteo. El resultado del paquete no enrutable es un mensaje inalcanzable de ICMP, que se envía al dispositivo interno.

¿Pero, Router A tiene una ruta predeterminado de 172.16.47.145, así que porqué es la ruta considerada no routable?

El Router A no tiene ningún haber configurado sin clase del IP, que significa si un paquete destinado para una dirección de red “importante” (en este caso, 172.16.0.0) para las cuales las subredes existan en la tabla de ruteo, el router no confía en la ruta predeterminado. Es decir si usted publica el comando no ip classless, esto apaga la capacidad del router de buscar la ruta con la coincidencia más larga del bit. Para cambiar este comportamiento, usted tiene que configurar el IP sin clase en el Router A. Habilitan al comando ip classless por abandono en los routeres Cisco con los Cisco IOS Software Release 11.3 y Posterior.

Router-A#configure terminal
Enter configuration commands, one per line.  End with CTRL/Z.
Router-A(config)#ip classless
Router-A(config)#end

Router-A#show ip nat translation
%SYS-5-CONFIG_I: Configured from console by console nat tr
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.47.150      171.68.200.48      ---                ---

Cuando usted relanza la misma prueba de ping según lo hecho previamente, usted ve que el paquete consigue traducido y el ping sea acertado.


Ping Response on device 171.68.200.48

D:\>ping 172.16.47.142
Pinging 172.16.47.142 with 32 bytes of data:

Reply from 172.16.47.142: bytes=32 time=10ms TTL=255
Reply from 172.16.47.142: bytes=32 time<10ms TTL=255
Reply from 172.16.47.142: bytes=32 time<10ms TTL=255
Reply from 172.16.47.142: bytes=32 time<10ms TTL=255

Ping statistics for 172.16.47.142:
    Packets: Sent = 4, Received = 4, Lost = 0 (0%)
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  10ms, Average =  2ms

Debug messages on Router A indicating that the packets generated by device 
171.68.200.48 are getting translated by NAT. 

Router-A#
*Mar 28 03:34:28: IP: tableid=0, s=171.68.200.48 (Serial0), d=172.16.47.142 
(Serial1), routed via RIB
*Mar 28 03:34:28: NAT: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [160]
*Mar 28 03:34:28: IP: s=172.16.47.150 (Serial0), d=172.16.47.142 (Serial1),
 g=172.16.47.145, len 100, forward
*Mar 28 03:34:28: ICMP type=8, code=0
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [160]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48 
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0), 
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0
*Mar 28 03:34:28: NAT*: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [161]
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [161]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48 
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0), 
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0
*Mar 28 03:34:28: NAT*: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [162]
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [162]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48 
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0), 
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0
*Mar 28 03:34:28: NAT*: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [163]
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [163]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48 
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0), 
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0
*Mar 28 03:34:28: NAT*: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [164]
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [164]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48 
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0), 
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0

Router-A#undebug all
All possible debugging has been turned off

El ejemplo anterior muestra que cuando un paquete atraviesa dentro a afuera, un router NAT marca su tabla de ruteo para una ruta a la dirección externa antes de que continúe traduciendo el paquete. Por lo tanto, es importante que el router NAT tenga una ruta válida para la red externa. La ruta a la red de destino se debe saber a través de una interfaz que se defina como NAT afuera en la configuración del router.

Es importante observar que los paquetes de devolución están traducidos antes de que se ruteen. Por lo tanto, el router NAT también debe tener una ruta válida para la dirección local interna en su tabla de ruteo.