Протокол IP : Технология NAT

Проверка работы и устранение основных неисправностей NAT

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (29 июля 2008) | Английский (22 августа 2015) | Отзыв


Интерактивно этот документ предлагает анализ конкретного устройства Cisco.


Содержание


Введение

При проблемах с подключением по IP в окружении NAT зачастую трудно определить причину проблемы. Ответственность за это часто по ошибке возлагается на NAT, тогда как на самом деле причина кроется глубже. Этот документ показывает, как проверить работу NAT с помощью средств, доступных на маршрутизаторах Cisco. В этом документе также иллюстрируется выполнение основного поиска и устранения неисправностей NAT и описано, как не допустить обычных ошибок во время поиска и устранения неисправностей NAT.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Как исключить NAT

Когда вы пытаетесь определить причину неполадки IP-подключения, она помогает исключать NAT. Для проверки правильности работы NAT выполните следующие действия:

  1. В соответствии с конфигурацией, четко укажите NAT, которую нужно достичь. В это время можно определить наличие проблемы с конфигурацией. Для справки с настройкой NAT ссылаются на Настройку преобразования сетевых адресов: Начало работы.

  2. Убедитесь, что в таблице преобразований существуют правильные преобразования.

  3. Чтобы убедиться в том, что преобразование происходит, используйте команды show и debug.

  4. Анализ подробно, что происходит с пакетом и проверяет, что маршрутизаторы имеют правильные сведения о маршрутизации для перемещения пакета вперед.

Ниже некоторые примеры проблемы, в которых мы используем вышеупомянутые шаги, чтобы помочь определять причину проблемы.

Пример проблемы: Возможен обмен пакетами с одним маршрутизатором, но не с другим

В этой схеме сети маршрутизатор 4 может пропинговать маршрутизатор 5 (172.16.6.5), но не маршрутизатор 7 (172.16.11.7):

13a.gif

Нет никаких протоколов маршрутизации, работающих ни в одном из маршрутизаторов, и маршрутизатор 4 имеет маршрутизатор 6 как свой шлюз по умолчанию. Маршрутизатор 6 настроен с NAT этим способом:

Маршрутизатор 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 

Сначала следует убедиться в правильном функционировании NAT. Вы знаете от конфигурации, что IP-адрес маршрутизатора 4 (10.10.10.4), как предполагается, статически преобразован в 172.16.6.14. Можно использовать команду show ip nat translation на маршрутизаторе 6, чтобы проверить, что трансляция действительно существует в таблице преобразования:

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

Теперь, гарантируйте, что эта трансляция имеет место когда исходный IP - трафик маршрутизатора 4. Для этого на маршрутизаторе 6 можно использовать два метода: выполнить команду NAT debug или проследить статистику NAT с помощью команды show ip nat statistics. Так как команды debug должны использоваться в крайнем случае, начинать следует с команды show.

Намерение здесь состоит в том, чтобы контролировать, соответствия в противоречии с видят, увеличивается ли оно, поскольку мы передаем трафик от маршрутизатора 4. Счетчик обращений увеличивается каждый раз, когда преобразование в таблице преобразования используется для преобразования адреса. Во-первых, очистите статистику, затем отобразите статистику, попытайтесь пропинговать маршрутизатор 7 от маршрутизатора 4, и затем отобразить статистику снова.

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#

После использования команды ping 172.16.11.7 на 4-ом маршрутизаторе статистика NAT на 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: 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

Из сообщений команды show видно, что число обращений выросло на 5. В случае успешного выполнения эхо-теста маршрутизатора Cisco число обращений увеличивается на 10. Пять эха Протокола ICMP, передаваемого исходным маршрутизатором (маршрутизатор 4), должно быть преобразовано, и эти пять пакетов эхо-ответа от маршрутизатора назначения (маршрутизатор 7) должны также быть преобразованы для в общей сложности десяти соответствий. В пропаже пяти ping-сигналов скорее всего виноваты эхо-ответы, которые либо не были транслированы, либо не отправлены на маршрутизатор 7.

Посмотрите, можно ли найти, что любой маршрутизатор 7 причины не передал бы пакеты эхо-ответа к маршрутизатору 4. Сначала рассмотрите то, что NAT делает к пакету. Маршрутизатор 4 посылает эхо-пакет ICMP с адресом источника 10.10.10.4 и адресом пункта назначения 172.16.11.7. После того, как NAT присваивает пакету, полученному маршрутизатором 7, адрес источника 172.16.6.14 и адрес получателя 172.16.11.7. Маршрутизатору 7 требуется дать ответ на 172.16.6.14, а поскольку 172.16.6.14 напрямую не подключен к маршрутизатору 7, чтобы ответить, ему нужен маршрут для этой сети. Проверьте таблицу маршрутизации маршрутизатора 7, чтобы проверить, что существует маршрут.

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

Вы видите, что таблица маршрутизации маршрутизатора 7 не имеет маршрута для 172.16.6.14. Как только вы добавляете этот маршрут, эхо-запрос хорошо работает.

Краткое описание проблемы

Вы сначала определили то, что NAT, как предполагалось, выполнял. Далее проверяется существование записи статической NAT в таблице трансляции, а также что она верна. Вы проверили, отследив статистику NAT, что преобразование действительно произошло. Там вы нашли проблему, которая вела вас проверять сведения о маршрутизации на маршрутизаторе 7, где вы нашли, что маршрутизатору 7 был нужен маршрут к внутреннему глобальному адресу маршрутизатора 4.

Обратите внимание, что в этих простых лабораторных условиях полезно отследить статистику операций NAT с помощью команды show ip nat statistics. Однако в более сложной среде NAT с несколькими выполняющимися преобразованиями, команда show не будет столь полезна. В таком случае, возможно, понадобится использовать на маршрутизаторе команду debug. В следующем сценарии проблемной ситуации показано использование команд debug.

Пример проблемы: Внешние сетевые устройства не могут взаимодействовать с внутренними маршрутизаторами

В данном сценарии маршрутизатор 4 может выполнить проверку доступности маршрутизаторов 5 и 7, но устройства в сети 10.10.50.0 не могут обмениваться данными с маршрутизатором 5 или маршрутизатором 7 (в испытательной лаборатории этот процесс моделируется путем выполнения проверки доступности из интерфейса обратной связи с IP-адресом 10.10.50.4). Взгляните на диаграмму:

13a.gif

Маршрутизатор 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 

Во-первых, ясно сообщите нормальное поведение NAT. От конфигурации маршрутизатора 6, вы знаете, что NAT, как предполагается, динамично преобразовывает 10.10.50.4 в первый доступный адрес в пуле NAT "тест". Этот пул состоит из адресов 172.16.11.70 и 172.16.11.71. Из того, что было выяснено по этой прблеме выше, можно вывести, что пакеты, полученные маршрутизаторами 5 и 7, имеют исходный адрес 172.16.11.70 или 172.16.11.71. Эти адреса находятся в той же подсети, что и маршрутизатор 7, поэтому у маршрутизатора 7 должен быть напрямую подключенный маршрут, однако маршрутизатору 5 понадобится маршрут к подсети, если такой маршрут еще не настроен.

Чтобы убедиться в том, что в таблице маршрутизации 5-ого маршрутизатора действительно есть адрес 172.16.11.0, можно использовать команду show ip route:

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

Чтобы убедиться в том, что в таблице маршрутизации 7-ого маршрутизатора адрес 172.16.11.0 записан как адрес непосредственно подключенной подсети, можно использовать команду show ip route:

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

Теперь, после явного указания действий NAT, необходимо проверить, что преобразование работает корректно. Начните с проверки таблицы преобразования NAT и убедитесь, что ожидаемое преобразование существует. Так как трансляция, которой вы интересуетесь, создана динамично, необходимо сначала передать IP - трафик, полученный от верного адреса. После отправки запроса "ICMP-эхо" с помощью команды ping с адреса 10.10.50.4 на адрес 172.16.11.7, в таблице преобразований 6-ого маршрутизатора будет отображаться следующая информация:

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         ---                ---

Поскольку ожидаемое преобразование содержится в таблице преобразования, известно, что преобразование для эхо-пакетов ICMP выполняется правильно, но как получить данные о преобразовании для пакетов эхо-ответа? Как упоминалось ранее, можно отслеживать статистику NAT, но в сложной среде это не очень полезно. Другой вариант – запустить отладку NAT в маршрутизаторе NAT (маршрутизатор 6). В этом случае, во время выполнения команды ping с адреса 10.10.50.4 на адрес 172.16.11.7, необходимо выполнить команду debug ip nat на 6-ом маршрутизаторе. Результат выполнения команды debug показан ниже.

Примечание: При использовании любой команды отладки на маршрутизаторе вы могли перегрузить маршрутизатор, который заставляет ее становиться неоперабельной. Всегда будьте очень внимательны и, если возможно, никогда не прибегайте к использованию команды debug при работе с критически важными маршрутизаторами без участия специалиста Службы технической поддержки 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]

Как видно из приведенных выше результатов применения команды debug, первая строка показывает преобразование исходного адреса 10.10.50.4 в 172.16.11.70. Вторая линия показывает адрес назначения (DA) 172.16.11.70 преобразовываемый назад в 10.10.50.4. Эта схема повторяется во всех дальнейших результатах работы команды debug. Это говорит о том, что маршрутизатор 6 транслирует пакеты в обоих направлениях.

Теперь рассмотрите более подробно точно, что должно происходить. Маршрутизатор 4 передает пакет от источника от 10.10.50.4 предназначенных для 172.16.11.7. Маршрутизатор 6 выполняет NAT для пакета и пересылает пакет с источником 172.16.11.70 и пунктом назначения 172.16.11.7. Маршрутизатор 7 посылает ответ с исходным адресом 172.16.11.7 и адресом назначения 172.16.11.70. Маршрутизатор 6 выполняет NAT на пакете, который приводит к пакету с адресом источника 172.16.11.7 и адресом назначения (DA) 10.10.50.4. На этом этапе маршрутизатор 6 должен направить пакет к 10.10.50.4 на основе информации, которую это имеет в ее таблице маршрутизации. Чтобы убедиться, что 6-ой маршрутизатор имеет необходимый маршрут в своей таблице, необходимо использовать команду show ip route.

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

Краткое описание проблемы

Сначала вы ясно определили, какой NAT предполагалось достичь. Во-вторых, проверено наличие необходимых правил преобразования в таблице преобразования. В-третьих, использовалась команда debug или show, которая позволила убедиться, что преобразование действительно имело место. Наконец, был подробно рассмотрен процесс передачи пакета, а также действия маршрутизатора по его пересылке или отправке ответа.

Устранение неполадок контрольных списков

Теперь, когда у вас есть базовая процедура для обнаружения причины неполадок подключения, вот некоторые чек-листы для устранения проблем общих проблем.

Трансляция не установлена в таблице трансляции

Если обнаруживается, что соответствующая трансляция не установлена в таблице трансляций, убедитесь в следующем:

  • Конфигурация корректна. Получение NAT выполнить, что вы хотите, может иногда быть хитрым. Для некоторой справки конфигурации обратитесь к Настройке преобразования сетевых адресов: Начало работы.

  • Нет никаких списков доступа на вход, которые запрещают пакеты от ввода маршрутизатора NAT.

  • У маршрутизатора NAT есть соответствующий маршрут в таблице маршрутизации, если пакет идет изнутри наружу. Дополнительная информация содержится в документе "Порядок работы NAT".

  • Список доступа, на который ссылается команда NAT, разрешает все нужные сети.

  • В пуле NAT имеется достаточно адресов. Это будет проблемой, только если NAT не настроен для перегрузки.

  • Что интерфейсы маршрутизатора правильно определены как интерфейсы с внутренним NAT или внешним NAT.

  • В случае перевода информационного наполнения пакетов Системы доменных имен (DNS) удостоверьтесь, что трансляция имеет место на адресе в IP-заголовке пакета. Если это не происходит, то NAT не исследует полезную нагрузку пакета.

Не используется правильная запись трансляции

Если запись правильного преобразования установлена в таблице преобразования, но не используется, проверьте их:

Сейчас работает трансляция сетевых адресов, но проблемы возможности подключения остались

Если NAT работает правильно, начните устранять неполадки неполадок подключения следующим образом:

  • Проверьте подключение уровня 2.

  • Проверьте сведения маршрутизации третьего уровня.

  • Поиск фильтров пакетов, которые могут вызвать проблему.

Преобразование NAT для порта 80 не Работает

Преобразование NAT для порта 80 не работает, но трансрасположение крыльев для других портов обычно работает.

Чтобы решить эту проблему, выполните следующие действия:

  1. Выполните трансляции debug ip nat и команды debug ip packet, чтобы видеть, корректны ли трансляции, и запись правильного преобразования установлена в таблице преобразования.

  2. Проверьте, что отвечает сервер.

  3. Отключите сервер HTTP.

  4. Очистите NAT и таблицы ARP.

%NAT: занятая Система. Попробуйте позже

Когда команда показа, отнесенная к NAT или show running config или команде write memory, выполняется, сообщение об ошибках %NAT: System busy. Try later появляется. Эта проблема происходит из-за увеличения размера таблицы NAT. Когда размер увеличений таблицы NAT, маршрутизатор исчерпывает память.

Повторно загрузите маршрутизатор для решения этой проблемы. Если сообщение об ошибках появляется, когда SNAT HSRP настроен, настройте эти команды для решения вопроса:

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

Большая таблица преобразования увеличивает ЦП

Хост может передать сотни трансляций, который в свою очередь приводит к высокой загрузке ЦП. Другими словами, это может сделать таблицу столь большой, что это заставляет ЦП достигать 100 процентов. Команда ip nat translation max-entries 300 делает 300 на предел хоста или составной предел суммы трансляций на маршрутизаторе. Обходной путь должен использовать команду ip nat translation max-entries all-hosts 300.

% Открытый IP - адрес, уже сопоставленный (Внутренний IP-адрес-> Открытый IP - адрес)

Когда вы пытаетесь настроить два внутренних IP-адреса к одному открытому IP - адресу, слушающему на тех же портах, это сообщение появляется.

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

Чтобы к NAT открытый IP - адрес к двум внутренним IP-адресам, используйте два открытых IP - адреса в DNS.

Никакие Записи в таблице ARP

Это - результат опции no-alias, которая используется на Записях NAT. Опция no-alias означает, что маршрутизатор не отвечает для адресов и не устанавливает Запись ARP. Если другой маршрутизатор использует пул NAT в качестве внутреннего глобального пула, который состоит из адресов на подключенной подсети, псевдоним генерируется для того адреса так, чтобы маршрутизатор мог ответить на Запросы протокола переопределения адресов (ARP) для тех адресов. Это заставляет маршрутизатор иметь Записи ARP для поддельных адресов.

Заключение

Перечисленные выше проблемы показывают, что причиной неполадок IP-соединения не всегда является NAT. Во многих случаях причина - что-то другое, чем NAT и требует дополнительного исследования. Данный документ содержит описание основных действий, которые необходимо предпринять для устранения неисправностей и проверки функционирования NAT. Данные шаги включают:

  • Ясно определите то, чего NAT, как предполагается, достигает.

  • Проверьте, что правильные преобразования существуют в таблице преобразования.

  • Чтобы убедиться в том, что преобразование происходит, используйте команды show и debug.

  • Анализ подробно, что происходит с пакетом и проверяет, что маршрутизаторы имеют правильные сведения о маршрутизации для перемещения пакета вперед.

Плохой маркер 0, требуемый TOK_NUMBER|TOK_PUNCT

Это сообщение об ошибках является просто информационным сообщением и не оказывает влияния на нормальное поведение устройства.

Bad token 0, wanted TOK_NUMBER|TOK_PUNCT

Ошибка означает, что NAT пытается сделать, уровень 4 закрепляет на адресе в открытом FTP, и не может найти IP-адреса, которые это должно преобразовать в пакете.

Причина, почему сообщение включает маркеры, состоит в том, что IP-адреса в пакете найдены путем поиска маркера или ряда символов, в пакете IP, чтобы найти, что подробные данные должны были преобразовать.

Когда сеанс FTP инициируется, он выполняет согласование о двух каналах, командном канале и канале данных. Это оба IP-адреса с другими номерами портов. Клиент FTP и сервер выполняют согласование о втором канале данных для передачи файлов. Пакет, которым обмениваются через управляющего канал, имеет формат "ПОРТ, я, я, я, я, p, p", где я, я, я, я - четыре байта IP-адреса, и p, p задают порт. NAT пытается совпасть с этим образцом и преобразовать адрес/порт при необходимости. NAT должен преобразовать схемы адресации обоих каналов. NAT просматривает для номеров в потоке команды, пока это не думает, что нашло команду порта, которая требует трансляции. Это пытается проанализировать трансляцию, которую это вычисляет с образцом, как описано ранее.

Если пакет поврежден или сервер FTP, или у клиента есть malforming команды, NAT не может должным образом вычислить трансляцию, и это генерирует ту ошибку. Предложение должно установить клиента FTP в "пассивный" так, чтобы оно инициировало оба канала. Это иногда помогает с FTP через NAT.


Дополнительные сведения


Document ID: 8605