Я хочу подключиться к FTP-серверу из моей локальной сети, которая находится за NAT.
Шлюз - это сервер Win 2008, настроенный с включенной маршрутизацией и удаленными службами / Nat. Проблема существует на компьютерах XP, Vista sp1 и Vista sp2.
Вот что я получаю (используя ftp-клиент DOS по умолчанию, но я получаю то же самое, используя FileZilla)
ftp> open ftp.foo.com
Connected to ftp.foo.com.
220-
[here I wait for 30s before getting the following line]
Connection closed by remote host.
ftp>
Как видите, я отключился до входа в систему, поэтому у меня нет возможности использовать PASSV.
Вот что работает:
Компания, предоставляющая ftp, говорит, что проблема не в их стороне, поскольку я могу подключиться со своего NAT-сервера. Те же рассуждения приводят к тому, что проблема не на моей стороне (я могу подключиться к другим ftp-серверам)
Что я должен проверить?
РЕДАКТИРОВАТЬ: вот что я получаю, когда обнюхиваю соединение на шлюзе при попытке подключиться с моего компьютера, находящегося за натурой:
В интерфейсе с выходом в Интернет:
No. Time Source Destination Protocol Info
1312 320.576218 213.186.xx.xxx 192.168.1.1 FTP Response: 220-
1313 320.576602 213.186.xx.xxx 192.168.1.1 FTP Response: 220-Bienvenue,
1315 320.610911 213.186.xx.xxx 192.168.1.1 FTP Response: 220-
И на моем внутреннем интерфейсе LAN:
No. Time Source Destination Protocol Info
9288 118.698920 213.186.xx.xx 192.168.0.100 FTP Response: 220-
9293 118.890406 213.186.xx.xx 192.168.0.100 FTP Response: 220-Bienvenue,
Frame 9293 (166 bytes on wire, 166 bytes captured)
Ethernet II, Src: Tp-LinkT_c6:e2:3f (00:21:27:c6:e2:3f), Dst: Giga-Byt_22:b0:99 (00:1f:d0:22:b0:99)
Internet Protocol, Src: 213.186.xx.xx(213.186.xx.xx), Dst: 192.168.0.100 (192.168.0.100)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: jini-discovery (4160), Seq: 7, Ack: 1, Len: 112
Source port: ftp (21)
Destination port: jini-discovery (4160)
Sequence number: 7 (relative sequence number)
[Next sequence number: 119 (relative sequence number)]
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 65536 (scaled)
Checksum: 0xa5bc [incorrect, should be 0x96cb (maybe caused by "TCP checksum offload"?)]
[SEQ/ACK analysis]
File Transfer Protocol (FTP)
9306 119.187327 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue,
9326 119.787350 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue,
No. Time Source Destination Protocol Info
9373 120.987450 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue,
Есть идеи, почему может возникнуть эта проблема с CRC?
Кстати, вот мои настройки mtu (на шлюзе), и они идентичны на моем компьютере.
C:\Windows\system32>netsh interface ipv4 show interfaces
Idx Met MTU State Name
--- --- ----- ----------- -------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
10 30 1500 connected Local Area Connection
13 20 1500 connected Local Area Connection 2
А вот анализ MTU на моем компьютере:
Pinging 192.168.0.1 with 1472 bytes of data:
Reply from 192.168.0.1: bytes=1472 time<1ms TTL=128
Pinging 192.168.0.1 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Вот что я получу, если попытаюсь подключиться с помощью telnet:
220-
Connection to host lost.
Press any key to continue...
Небольшой текст, который все же проходит, предполагает, что это может быть какая-то проблема с MTU. Лучший способ двигаться дальше - установить Wireshark на шлюз и захватить весь трафик, связанный с FTP-соединением. Если вы видите, что большой пакет отправляется несколько раз, это MTU. В противном случае вставьте след куда-нибудь, и кто-нибудь сможет его интерпретировать за вас, если он вам не понятен.
Прокси-сервер приложения FTP в вашем NAT-шлюзе, похоже, обрабатывает многострочный код ответа «220-».
Коды ответов FTP обычно состоят из одной строки, но знак «-» после числа указывает на то, что поступают дополнительные строки вывода.
Я видел это раньше - в моем случае это был брандмауэр PIX.
Я, кажется, припоминаю, что некоторым FTP-серверам можно запретить отправлять многострочные ответы, добавив к паролю входа префикс '-', РЕДАКТИРОВАТЬ, однако в данном случае это не решение, потому что 220- ответ отправляется до того, как пользователь попытается войти.
Если вы дружелюбны с администратором FTP-сервера, попросите его временно отключить баннер входа на сервер и посмотреть, продолжится ли ваш вход в систему.
В качестве примечания, проблема CRC обычно вызвана контрольной суммой, выполняемой непосредственно на сетевой карте в оборудовании. Тогда стек ОС больше не видит контрольную сумму правильно.
Попробуйте открыть свойства сетевой карты и отключить любую разгрузку, она должна удалить эти сообщения.
Обновить:
После дальнейшего анализа ваших журналов, кажется, что пакет, который не был получен, имеет длину всего 166 байт (это "Bienvenue"тот, который повторно передается снова и снова через интерфейс LAN), поэтому я не думаю, что здесь проблема с MTU. auth/ident потому что сервер отправляет все пакеты. Хотя это первый из них, в котором есть ошибка CRC.
Попробуйте отключить все аппаратные ускорения (разгрузку) на внутреннем нике, а в конечном итоге и на внешнем, если это не помогает. Наличие фиксированной скорости и дуплексного режима также очень удобно при поиске и устранении неисправностей, позволяя активировать одну потенциальную причину за раз (10 / полудуплекс - хорошее начало). Если это сработает, просто активируйте одно за другим, чтобы определить причину проблемы.
Если ничего не работает, возможно, виновато программное обеспечение FTP-NAT: FTP - это протокол, который необходимо изменить для работы через NAT (обычно не здесь). Попробуйте использовать программное обеспечение FTP-прокси (Layer 7). Если это сработает, у вас будет обходной путь, поскольку он, похоже, только для FTP.
Я думаю, у меня в офисе такая же неприятная проблема с IPtables, только мы знаем, что это происходит, и не хотим ее исправлять.
Это может помочь проверить, какие порты вы блокируете для входящего трафика. Я почти уверен, что FTP использует только 21 для входящих соединений (т.е. вы можете подключиться к чему-то, но вы не можете управлять этим).
Я почти уверен, что порт, который вы получите взамен, подлежит обсуждению, поэтому было бы неплохо отказаться от FTP и использовать SFTP в этом случае, если вы можете.
Вы можете попробовать использовать debug команда в командной строке Windows ftp. Возможно, он покажет вам дополнительную информацию, которая приведет к решению.
Пациент: Доктор, доктор! Когда я выпиваю чашку чая, у меня колющая боль в глазу.
Врач: Попробуйте вынуть ложку из чашки!
Дело в том, почему вы используете свой сервер в качестве шлюза NAT? Разве ваш модем / роутер этого не делает? Почему бы не убрать сервер с пути?
Наш FTP-сервер (proftpd) работает так: слушает соединения на порт 21, а затем * после подключения увеличивает его до диапазона 60000 ** (устанавливается в proftpd.conf как PassivePorts)
Наш NAT изначально был настроен только для пересылки порта 21 на FTP-сервер, и мы наблюдали поведение, подобное тому, что вы видите.
По ограничение PassivePorts определенным диапазоном, и пересылка этого диапазона в конфигурации NAT это решило нашу проблему.
Конечно, это с точки зрения сервера
Однако это можно легко протестировать, временно настроив NAT для всех портов и посмотрев, решит ли это проблему.