IP : Traducción de direcciones de red (NAT)

Verificación del funcionamiento de NAT y resolución de problemas básicos de NAT

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Interactivo: Este documento ofrece un análisis personalizado de su dispositivo Cisco.


Contenido


Introducción

Si tiene problemas de conectividad IP en un entorno NAT, a menudo es difícil determinar la causa del problema. Muchas veces se culpa erróneamente a la NAT, cuando en realidad hay un problema subyacente. Este documento muestra cómo verificar el funcionamiento de NAT mediante el uso de las herramientas disponibles en los routers de Cisco. Este documento también le enseña cómo llevar a cabo la resolución básica de problemas de NAT, y cómo evitar los errores comunes que surjan de ella.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

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

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Cómo excluir a NAT

Cuando usted intenta determinar la causa de un problema de conectividad IP, ayuda a eliminar el NAT. Siga los siguientes pasos para verificar que NAT esté funcionando como se espera:

  1. En base a la configuración, defina claramente cuál es la NAT que debería lograrlo. En este punto, puede determinar que existe un problema con la configuración. Para la ayuda con configurar el NAT refiera a configurar la traducción de dirección de red: Introducción.

  2. Controle que existan traducciones correctas en la tabla de traducciones.

  3. Utilice los comandos show and debug de verificar que está ocurriendo la traducción.

  4. El estudio detalladamente qué está sucediendo al paquete y verifica que el Routers tenga la información de ruteo correcta para mover el paquete adelante.

Abajo están algunos problemas de ejemplo en los cuales utilizamos los pasos antedichos para ayudar a determinar la causa del problema.

Problema de ejemplo: Se puede ejecutar ping en un router pero no en otro

En este diagrama de la red, el Router4 puede hacer ping el router 5 (172.16.6.5), pero no al router 7 (172.16.11.7):

13a.gif

No hay Routing Protocol que se ejecutan en el Routers un de los, y el Router4 tiene el router 6 como su default gateway. Configuran al router 6 con el NAT de este modo:

Router 6
interface Ethernet0
 ip address 172.16.6.6 255.255.255.0
 ip directed-broadcast
 ip nat outside
 media-type 10BaseT
 !
interface Ethernet1
 ip address 10.10.10.6 255.255.255.0
 ip nat inside 
 media-type 10BaseT
 !
interface Serial2.7 point-to-point
 ip address 172.16.11.6 255.255.255.0
 ip nat outside
 frame-relay interface-dlci 101 
 !
ip nat pool test 172.16.11.70 172.16.11.71 prefix-length 24
ip nat inside source list 7 pool test
ip nat inside source static 10.10.10.4 172.16.6.14
 !
access-list 7 permit 10.10.50.4
access-list 7 permit 10.10.60.4
access-list 7 permit 10.10.70.4 

En primer lugar, determine que NAT esté funcionando correctamente. Usted sabe de la configuración que la dirección IP del Router4 (10.10.10.4) está supuesta ser traducida estáticamente a 172.16.6.14. Usted puede utilizar el comando show ip nat translation en el router 6 de verificar que la traducción existe en la tabla de traducción:

router-6# show ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.6.14        10.10.10.4         ---                ---

Ahora, asegúrese que esté ocurriendo esta traducción cuando tráfico IP de las fuentes del Router4. Puede hacer esto de dos maneras desde el router 6: mediante la ejecución de la depuración NAT o el control de las estadísticas NAT con el comando show ip nat statistics. Porque los comandos debug deben ser utilizados siempre como último recurso, comience con el comando show.

La intención aquí es monitorear los golpes en dirección contraria considera si está aumentando mientras que enviamos el tráfico del Router4. El contador de aciertos aumenta cada vez que se utiliza una traducción de la tabla de traducciones para traducir una dirección. Primero, borre las estadísticas, después visualice las estadísticas, intente hacer ping al router 7 del Router4, y después visualice las estadísticas otra vez.

router-6# clear ip nat statistics
router-6#
router-6# show ip nat statistics
 Total active translations: 1 (1 static, 0 dynamic; 0 extended)
 Outside interfaces:
 Ethernet0, Serial2.7
 Inside interfaces:
 Ethernet1
 Hits: 0  Misses: 0
 Expired translations: 0
 Dynamic mappings:
 -- Inside Source
 access-list 7 pool test refcount 0
 pool test: netmask 255.255.255.0
 start 172.16.11.70 end 172.16.11.71
 type generic, total addresses 2, allocated 0 (0%), misses 0
router-6#

Después de que usted utilice el comando de 172.16.11.7 del ping en el Router4, las estadísticas de NAT en la demostración del router 6 como:

router-6# show ip nat statistics
 Total active translations: 1 (1 static, 0 dynamic; 0 extended)
 Outside interfaces:
 Ethernet0, Serial2.7
 Inside interfaces:
 Ethernet1
 Hits: 5  Misses: 0
 Expired translations: 0
 Dynamic mappings:
 -- Inside Source
 access-list 7 pool test refcount 0
 pool test: netmask 255.255.255.0
 start 172.16.11.70 end 172.16.11.71
 type generic, total addresses 2, allocated 0 (0%), misses 0

Usted puede ver de los comandos show que la cantidad de aciertos incrementó por cinco. En un ping exitoso de un router de Cisco, el número de aciertos debería aumentar de a diez. Las cinco generaciones de eco del Internet Control Message Protocol (ICMP) enviadas por el router de origen (el router 4) debe ser traducido, y los cinco paquetes de respuesta de eco del router de destino (el router 7) debe también ser traducido, porque un total de diez golpes. Los cinco resultados que faltan probablemente se deban a que las respuestas de eco no están siendo traducidas ni enviadas desde el router 7.

Vea si usted puede encontrar que ningún router 7 de la razón no enviaría los paquetes de respuesta de eco al Router4. Primer estudio qué NAT está haciendo al paquete. El Router 4 envía paquetes de eco ICMP con una dirección de origen de 10.10.10.4 y una dirección de destino de 172.16.11.7. Una vez realizada la NAT (Traducción de la dirección de red) el paquete recibido por el router 7 tiene una dirección fuente de 172.16.6.14 y una dirección de destino de 172.16.11.7. El Router 7 necesita responderle a 172.16.6.14, y ya que ésta no está conectada con el Router 7 de forma directa, necesita una ruta para poder hacerlo. La tabla de ruteo del router 7's del control para verificar la ruta existe.

router-7# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 4 subnets
C       172.16.12.0 is directly connected, Serial0.8
C       172.16.9.0 is directly connected, Serial0.5
C       172.16.11.0 is directly connected, Serial0.6
C       172.16.5.0 is directly connected, Ethernet0

Usted puede ver que la tabla de ruteo del router 7 no tiene una ruta para 172.16.6.14. Una vez que usted agrega esta ruta, haga ping los trabajos muy bien.

Resumen de problemas

Usted primero definió qué NAT fue supuesto para lograr. Luego, verificó que la entrada de NAT estática existía en la tabla de traducción y de que era precisa. Verificó que la traducción realmente se llevaba a cabo al controlar las estadísticas de Traducción de dirección de red (NAT). Allí usted encontró un problema que le llevó a marcar la información de ruteo en el router 7, donde usted encontró ese router 7 necesitó una ruta al dirección interna global del router 4.

Observe que en este entorno de laboratorio simple, es útil monitorear las estadísticas de NAT con el comando show ip nat statistics. Sin embargo, en un más entorno NAT complejo con varias traducciones que ocurren, este comando show es no más útil. En este caso, tal vez sea necesario ejecutar depuraciones en el router. El siguiente ejemplo de problema muestra cómo se utilizan los comandos de depuración.

Problema de ejemplo: Los dispositivos de redes exteriores no pueden comunicarse con los routers interiores

En este escenario, el Router 4 puede hacer ping al Router 5 y al Router 7, pero los dispositivos en la red 10.10.50.0 no pueden comunicarse con el Router 5 o el Router 7 (en el laboratorio de pruebas hemos reproducido este caso al obtener pings de la interfaz de loopback con la dirección IP 10.10.50.4). Observe el diagrama de red:

13a.gif

Router 6
interface Ethernet0
 ip address 172.16.6.6 255.255.255.0
 ip directed-broadcast
 ip nat outside
 media-type 10BaseT
 !
interface Ethernet1
 ip address 10.10.10.6 255.255.255.0
 ip nat inside 
 media-type 10BaseT
 !
interface Serial2.7 point-to-point
 ip address 172.16.11.6 255.255.255.0
 ip nat outside
 frame-relay interface-dlci 101 
 !
ip nat pool test 172.16.11.70 172.16.11.71 prefix-length 24
ip nat inside source list 7 pool test
ip nat inside source static 10.10.10.4 172.16.6.14
 !
access-list 7 permit 10.10.50.4
access-list 7 permit 10.10.60.4
access-list 7 permit 10.10.70.4 

Primero, estado claramente la conducta esperada del NAT. De la configuración del router 6, usted sabe que el NAT está supuesto traducir dinámicamente 10.10.50.4 a la primera dirección disponible en el agrupamiento NAT “prueba”. El grupo está formado por las direcciones 172.16.11.70 y 172.16.11.71. En función de lo aprendido en el problema anterior, puede deducir que la dirección de origen de los paquetes que reciben los Routers 5 y 7 tienen es 172.16.11.70 ó 172.16.11.71. Estas direcciones están en la misma subred como Router 7, por lo que el Router 7 debe tener una ruta conectada directamente, sin embargo el Router 5 necesita una ruta para la subred en el caso de que no tuviera ya una.

Usted puede utilizar el comando show ip route de ver que la tabla de ruteo del router 5 enumera 172.16.11.0:

router-5# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 4 subnets
C 172.16.9.0 is directly connected, Serial1
S 172.16.11.0 [1/0] via 172.16.6.6
C 172.16.6.0 is directly connected, Ethernet0
C 172.16.2.0 is directly connected, Serial0

Usted puede utilizar el comando show ip route de ver que las listas 172.16.11.0 de la tabla de ruteo del router 7 como directamente subred conectada:

router-7# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 5 subnets
C       172.16.12.0 is directly connected, Serial0.8
C       172.16.9.0 is directly connected, Serial0.5
C       172.16.11.0 is directly connected, Serial0.6
C       172.16.5.0 is directly connected, Ethernet0
S       172.16.6.0 [1/0] via 172.16.11.6

Ahora que ha establecido claramente qué NAT se debe realizar, necesita verificar que esté funcionando correctamente. Comience con la revisión de la tabla de traducción NAT y la verificación de que exista la traducción esperada. Puesto que la traducción que usted está interesado adentro se crea dinámicamente, usted debe primero enviar el tráfico IP originado de la dirección apropiada. Después de que un ping enviado, originado de 10.10.50.4 y destinado a 172.16.11.7, la tabla de traducción en el router 6 muestre esto:

router-6# show ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.6.14        10.10.10.4         ---                ---
--- 172.16.11.70       10.10.50.4         ---                ---

Al estar la traducción esperada en la tabla de traducción, le permite saber que los paquetes de eco ICMP se están traduciendo apropiadamente, pero ¿qué sucede con los paquetes de respuesta de eco? Como se mencionó anteriormente, puede supervisar las estadísticas NAT, pero no es muy útil en un entorno complejo. Otra opción es ejecutar el depurador NAT en el router NAT (Router 6). En este caso, usted debe girar el IP del debug nacional en el router 6 mientras que usted envía un ping originado de 10.10.50.4 destinó a 172.16.11.7. Los resultados del debug están abajo.

Nota: Cuando usted utiliza cualquier comando debug en un router, usted podría sobrecargar al router que la hace llegar a ser inoperable. Tenga mucho cuidado siempre, y si es posible nunca ejecutada un debug en un router de producción fundamental sin la supervisión de un ingeniero de soporte técnico de Cisco.

router-6# show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
       Console logging: level debugging, 39 messages logged
       Monitor logging: level debugging, 0 messages logged
       Buffer logging: level debugging, 39 messages logged
       Trap logging: level informational, 33 message lines logged

Log Buffer (4096 bytes):

05:32:23: NAT: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [70]
05:32:23: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [70]
05:32:25: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [71]
05:32:25: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [71]
05:32:27: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [72]
05:32:27: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [72]
05:32:29: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [73]
05:32:29: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [73]
05:32:31: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [74]
05:32:31: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [74]

Como puede observar en el resultado de la depuración anterior, la primera línea muestra que la dirección de origen de 10.10.50.4 se está traduciendo a 172.16.11.70. La segunda línea muestra a la dirección destino de 172.16.11.70 que es traducida de nuevo a 10.10.50.4. Este patrón se repite durante el resto de la depuración. Esto le informa que el Router 6 está convirtiendo los paquetes en ambas direcciones.

Ahora revise más detalladamente exactamente qué debe suceder. El Router4 envía un paquete originado de 10.10.50.4 destinó para 172.16.11.7. El router 6 realiza el NAT en el paquete y reenvía un paquete con un origen de 172.16.11.70 y un destino de 172.16.11.7. El Router 7 envía una respuesta con 172.16.11.7 como dirección de origen y 172.16.11.70 como destino. El router 6 realiza el NAT en el paquete, que da lugar a un paquete con la dirección de origen 172.16.11.7 y la dirección destino 10.10.50.4. En este momento el router 6 debe rutear el paquete a 10.10.50.4 basó en la información que tiene en su tabla de ruteo. Usted necesita utilizar el comando show ip route de confirmar que el router 6 tiene la ruta necesario en su tabla de ruteo.

router-6# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 5 subnets
C 172.16.8.0 is directly connected, Serial1
C 172.16.10.0 is directly connected, Serial2.8
C 172.16.11.0 is directly connected, Serial2.7
C 172.16.6.0 is directly connected, Ethernet0
C 172.16.7.0 is directly connected, Serial0
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Ethernet1

Resumen de problemas

En primer lugar, definió claramente lo que se suponía que NAT debería lograr. Segundo, verificó que las traducciones necesarias existieran en la tabla de traducciones. Tercero, usted utilizó los comandos debug or show verificados que ocurría la traducción realmente. Por último, usted repasó con más detalle lo que le ocurría al paquete y las necesidades de los routers para reenviar o responder al paquete.

Listas de Verificación de Resolución de Problemas

Ahora que usted tiene un procedimiento básico para encontrar las causas del problema de conectividad, aquí están algunas listas de verificación para resolver problemas los problemas frecuentes.

No está instalada la traducción en la tabla de traducción

Si no logra que se instale la traducción correcta en la tabla de traducciones, verifique que:

  • La configuración está correcta. Conseguir el NAT para lograr lo que usted quiere puede a veces ser difícil. Para una cierta ayuda de la configuración, refiera a configurar la traducción de dirección de red: Introducción.

  • No hay ninguna listas de acceso de entrada que niegan los paquetes de ingresar al router NAT.

  • Si el paquete se dirige desde el interior hacia el exterior, el router NAT tiene la ruta adecuada en la tabla de ruteo. Refiera al Orden NAT de funcionamiento para más información.

  • La lista de acceso referida por el comando nat permite todas las redes necesarias.

  • Existen suficientes direcciones en la agrupación NAT. Esto únicamente será un problema si NAT no se configura para sobrecargas.

  • Que las interfaces del router están correctamente definidas como NAT interna y NAT externa.

  • En el caso de traducir los paquetes de la carga útil del sistema de nombres de dominio (DNS), aseegurese que la traducción ocurre en el direccionamiento en el encabezado IP del paquete. Si esto no sucede, el NAT no busca la carga útil del paquete.

No se está utilizando la entrada de traducción correcta

Si la entrada de la traducción correcta está instalada en la tabla de traducción, pero no utilizada, marque éstos:

  • Verifique allí no son cualquier lista de acceso de entrada que niegue los paquetes de ingresar al router NAT.

  • Para los paquetes que van de adentro hacia afuera, verifique que haya una ruta hasta el destino, dado que esto se comprueba antes de la traducción. Refiera al Orden NAT de funcionamiento para más información.

NAT está funcionando correctamente pero aún existen problemas de conectividad

Si el NAT está actuando correctamente, comience a resolver problemas el problema de conectividad como sigue:

  • Verifique la Conectividad de la capa 2.

  • Verifique la información de ruteo de Capa 3.

  • Busque los filtros de paquete que puedan estar causando el problema.

La traducción de NAT para el puerto 80 no trabaja

La traducción de NAT para el puerto 80 no trabaja, solamente el transalation para otros trabajos de los puertos normalmente.

Complete estos pasos para resolver el problema:

  1. Funcione con las traducciones y los comandos debug ip packet nacionales del IP del debug para ver si las traducciones están correctas y la entrada de la traducción correcta está instalada en la tabla de traducción.

  2. Verifique que responda el servidor.

  3. Inhabilite al servidor HTTP.

  4. Borre el NAT y las tablas ARP.

%NAT: Sistema ocupado. Intento más adelante

El %NAT: Sistema ocupado. El mensaje de error posterior del intento aparece cuando un comando show se relacionó con el NAT o ejecutan un ejecutar-config o a un comando write memory de la demostración. Este problema es debido al aumento en el tamaño de la tabla NAT. Cuando el tamaño de la tabla NAT aumenta, el router se ejecuta de la memoria.

Recargue al router para solucionar este problema. Si aparece el mensaje de error cuando se configura el HSRP SNAT, configure estos comandos para resolver el problema:

Router(config)#standby delay minimum 20 reload 20
Router(config)#standby 2 preempt delay minimum 20 reload 20 sync 10

La tabla de traducción grande aumenta el CPU

Un host puede enviar los centenares de traducciones, que a su vez lleva CPU elevada al uso. Es decir puede hacer la tabla tan grande que hace el CPU ejecutarse en el 100 por ciento. El comando nacional de las MAX-entradas 300 de la traducción del IP hace los 300 por el límite del host o un límite global de la cantidad de traducciones en el router. La solución alternativa es utilizar el comando nacional de los todo-host 300 de las MAX-entradas de la traducción del IP.

% del IP Address público asociado ya (IP Address interno - > IP Address público)

Este mensaje aparece cuando usted intenta configurar dos IP Address internos a un IP Address público que escuchan en los mismos puertos.

% X.X.X.X already mapped (172.30.62.101 -> X.X.X.X)

Para el NAT el IP Address público a dos IP Address internos, utiliza a dos IP Address públicos en el DNS.

Ningunas entradas en la tabla ARP

Éste es un resultado de la opción del ninguno-alias que se utiliza en las entradas de NAT. La opción del ninguno-alias significa que el router no responde para los direccionamientos y no instala una entrada ARP. Si otro router utiliza a un agrupamiento NAT como agrupación global interior que consista en los direccionamientos en una subred conectada, un alias se genera para ese direccionamiento de modo que el router pueda contestar a las peticiones de Address Resolution Protocol (ARP) para esos direccionamientos. Esto hace al router tener entradas ARP para los direccionamientos falsos.

Conclusión

Los problemas anteriores demostraron que la NAT no es siempre la causa de los problemas de conectividad IP. En muchos casos, la causa es algo con excepción de NAT y requiere la investigación adicional. Este documento explica los pasos básicos que se deben seguir para la resolución de problemas y la verificación del funcionamiento de NAT. Estos pasos incluyen:

  • Defina claramente qué NAT se supone para alcanzar.

  • Verifique las traducciones correctas existen en la tabla de traducción.

  • Utilice los comandos show and debug de verificar la traducción está ocurriendo.

  • El estudio detalladamente qué está sucediendo al paquete y verifica que el Routers tenga la información de ruteo correcta para mover el paquete adelante.

Mún token 0, TOK_NUMBER querido|TOK_PUNCT

Este mensaje de error es apenas un mensaje de información y no tiene ningún impacto en el comportamiento normal del dispositivo.

Bad token 0, wanted TOK_NUMBER|TOK_PUNCT

El error significa que las tentativas NAT de hacer un arreglo de la capa 4 en el direccionamiento en un FTP abierto, y no puede encontrar los IP Addresses que necesita traducir en el paquete.

La razón por la que el mensaje incluye los tokens es que los IP Addresses en el paquete son encontrados buscando un token, o un conjunto de los símbolos, en el paquete del IP, para encontrar los detalles necesitados para traducir.

Cuando inician a una sesión FTP, negocia dos canales, un comando channel y un canal de datos. Éstos son ambos IP Addresses con diversos números del puerto. El FTP cliente y el servidor negocian un segundo canal de datos para transferir los archivos. El paquete intercambiado a través del canal de control tiene el formato “PUERTO, i, i, i, i, p, p”, donde está los cuatro bytes i, i, i, i de una dirección IP y de un p, p especifica el puerto. Intentos NAT para hacer juego este modelo y para traducir el /port del direccionamiento en caso necesario. El NAT debe traducir los esquemas de direccionamiento de ambos canales. El NAT analiza para los números en la secuencia del comando hasta que piense que ha encontrado un comando port que requiere la traducción. Intenta analizar hacia fuera la traducción, que calcula con el modelo según lo descrito anterior.

Si el paquete es corrupto o el servidor FTP o el cliente tiene comandos malforming, el NAT no puede calcular correctamente la traducción y genera ese error. Una sugerencia es fijar al FTP cliente a la “voz pasiva” de modo que inicie ambos canales. Esto ayuda a veces con el FTP con el NAT.


Información Relacionada


Document ID: 8605