Чтобы отладить проблему с активным FTP, мы отслеживаем активный трафик FTP-сеанса с помощью tcpdump, запущенного в контейнере панели инструментов на узле GKE. Активный сеанс FTP не работает на канале данных.
Я знаком с различиями между активным режимом и пассивным режимом FTP (наша платформа должна поддерживать оба режима, и мы по возможности используем пассивный режим).
Чтобы отладить отказавший активный канал данных FTP, мы отслеживаем успешные активные сеансы FTP, чтобы прояснить поток в нашей среде с нашей реализацией FTP-сервера. Проблема здесь в следующем:
Захват пакетов из канала данных в успешном активном сеансе FTP
Посмотрел на Эта проблема и хотя он похож, он не кажется решенным, и наша ситуация может быть другой. Трассировка запускается с:
tcpdump -vnn -w 002.pcap -i eth0
Затем файл pcap открывается в Wireshark. Фильтрация по протоколу FTP четко показывает часть сеанса управления каналом. Связь FTP-клиент / сервер осуществляется должным образом между эфемерным портом клиента и портом сервера 21. Этот поток включает ожидаемые команды для аутентификации, настройки TYPE I, CWD для правильной папки, SIZE, PORT и RETR для имя файла.
Команда PORT выглядит нормально, включая IP-адрес клиента и порт для сервера, который будет использоваться в последующей части сеанса канала данных (для загрузки одного файла). Например.:
PORT 1,2,3,4,51,105
который преобразует: (51x256 + 105) в порт 13161.
Однако в Wireshark после:
client:27154 > server:21 RETR <filename>
server:21 > client:27154 150 File status okay; about to open data connection.
захватываются только дополнительные пакеты:
server:21 > client:27154 226 Transfer complete.
client:27154 > server:21 6 QUIT
server:21 > client:27154 221 Goodbye.
Наша реализация FTP-сервера не использует порт 20 для канала данных, он использует случайный доступный порт. В любом случае мы ожидали, что сервер установит канал данных следующим образом:
server:<random port> > client:13161
И еще одна или две строки, показывающие фактический перевод.
Спасибо.
Это была моя ошибка. После проверки RFC 959 и его описание канала данных для ТИПА I (изображение / двоичный) и настройка представления в Wireshark для простой последовательной трассировки (по времени); Пакеты TCP для канала данных фактически присутствуют.
Для всех, кто сталкивается с этим при активном FTP, в канал управления:
Учитывая ответ на ЗАПРОС РАЗМЕРА, подобный этому:
FTP ... Response: 213 3981
который указывает размер файла 3981 байт, и команду PORT, подобную этой:
FTP ... Request: PORT 1,2,3,4,51,105
который указывает IP-адрес и порт для использования сервером при установлении TCP-соединения с клиентом для начала канала данных.
Чтобы преобразовать 5-й и 6-й октет в номер порта:
51x256 + 105 = 13161
Wireshark должен отобразить канал данных такие пакеты:
No. | Time | Source | Destination | Protocol | Length | Info
----------------------------------------------------------------------------------------------------------------------------------------------------------------
89 | 6.982066 | 10.5.4.3 | 1.2.3.4 | TCP | 76 | 33841 → 13161 [SYN] Seq=0 Win=28400 Len=0 MSS=1420 SACK_PERM=1 TSval=3979605739 TSecr=0 WS=128
93 | 7.390712 | 1.2.3.4 | 10.5.4.3 | TCP | 64 | 13161 → 33841 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1360 SACK_PERM=1
98 | 7.390818 | 10.5.4.3 | 1.2.3.4 | TCP | 56 | 33841 → 13161 [ACK] Seq=1 Ack=1 Win=28400 Len=0
101 | 7.395054 | 10.5.4.3 | 1.2.3.4 | TCP | 2776 | 33841 → 13161 [ACK] Seq=1 Ack=1 Win=28400 Len=2720
104 | 7.395068 | 10.5.4.3 | 1.2.3.4 | TCP | 1317 | 33841 → 13161 [PSH, ACK] Seq=2721 Ack=1 Win=28400 Len=1261
107 | 7.395096 | 10.5.4.3 | 1.2.3.4 | TCP | 56 | 33841 → 13161 [FIN, ACK] Seq=3982 Ack=1 Win=28400 Len=0
Пакеты TCP выше показывают трехстороннее подтверждение TCP: SYN, SYN-ACK, ACK, а затем фактическую двоичную передачу. Вы можете суммировать длины полезной нагрузки (в столбце «Информация») из пакетов 101 и 104, чтобы получить размер файла, подтвержденный ранее в канале управления.
Len=2720 + Len=1261 = 3981
Затем вы должны увидеть окончательное подтверждение FTP 226 в канал управления:
FTP ... Response: 226 Transfer complete.