Имеется ftp-сервер (у меня под боком), к которому подключаются из другого города. Пару недель назад вдруг подключаться перестали. Имя/пароль сервер принимает, а на попытке загрузить хотя бы список файлов из папки клиент ждет до полного таймаута. Прочий интернет (браузер, почтовик, аська) работает нормально, тамошний программист божится, что их прокси не причем. "Изнутри" нашего провайдера связь нормальная, клиент подключается, файлы передаются.
Цепочка, по которой идет сигнал, ИМХО следующая:
ftp-сервер == мой прокси == мой провайдер == провайдер клиента == прокси клиента == ftp-клиент
Как определить, что и на каком звене цепочки оказалось закрыто? Судя по тому, что из сети провайдера связь нормальная, мой прокси не виноват. Опять же, судя по тому, что имя/пароль принимаются и по результатам запускаемой со стороны клиента команды telnet xxx.xxx.xxx.xxx 21, 21-й порт открыт на всем протяжении цепочки.
Как проверить порты 20 и 11xx по которым идет связь в режиме активного клиента? Через telnet они не подключаются даже изнутри моей локалки. На программиста со стороны клиента надежды нет, максимум, что могу -- попросить оператора что-то запустить на своем "конечном" компе и прочитать с экрана, что получилось.
Как определеить, где закрыли порт
-
- Старожил
- Сообщения: 1762
- Зарегистрирован: 01.01.1970 3:00
- Откуда: Россия, Курск-Москва
- Контактная информация:
Если бы... Клиент -- написанная год назад (не мной!) программа, изменить ничего нельзя. Программа работает правильно, что подтверждает запуск тамошним оператором "под моим чутким руководством" ftp.exe. Что там, что там принимает подтверждение о получении логина/пароля, а при попытке get/put или хотя бы dir -- пауза до победного конца...
-
- Администратор Judge Dredd
- Сообщения: 17062
- Зарегистрирован: 17.01.2003 11:52
- Контактная информация:
В активном режиме FTP-сервер с порта 20 инициирует соединение с клиентом на выбранный клиентом порт >1024. Стало быть, порты закрыл или сам клиент (включил Windows Firewall, например), или его провайдер. Есть, правда, и еще вариант, http://support.microsoft.com/kb/196271/ru . Если ребята подняли у себя что-то, хапающее много временных портов (DNS сервер от MS забирает сразу 2500 портов, для примера), то клиенту может не хватать.
-
- Старожил
- Сообщения: 1762
- Зарегистрирован: 01.01.1970 3:00
- Откуда: Россия, Курск-Москва
- Контактная информация:
DrEvil,
Так что навряд ли.
На "радеоне" посоветовали tracert, но он "стучится" по UDP а не по TCP и х.з. по какому порту, а ставить на стороне клиента Linux, чтобы запустить такую расхваливаемую в гугле штуку как tcptracert, естественно, никто не будет.
в связи с этим ищется win32-аналог tcptracert, который не требует инсталляции и работает на "голой" винде (XP SP1) без обязательной установки каких-нибудь дополнительных драйверов/библиотек (чтобы можно было послать один или несколько файлов на сторону клиента по почте, там бы это скопировали в папку, запустили, и сбросили мне копию экрана или какой-нибудь лог для анализа).
У клиента XP SP1, права пользовательские, Windows Firewall был отключен, какой-либо другой не установлен, а компа мадам пользователь слегка опасается, поэтому жмет исключительно что покажутпорты закрыл или сам клиент (включил Windows Firewall, например)
Так что навряд ли.
вот мне и хочется проверить более-менее точно. Чтобы знать, к кому в этой цепочке обращаться.или его провайдер. Есть, правда, и еще вариант ...
На "радеоне" посоветовали tracert, но он "стучится" по UDP а не по TCP и х.з. по какому порту, а ставить на стороне клиента Linux, чтобы запустить такую расхваливаемую в гугле штуку как tcptracert, естественно, никто не будет.
в связи с этим ищется win32-аналог tcptracert, который не требует инсталляции и работает на "голой" винде (XP SP1) без обязательной установки каких-нибудь дополнительных драйверов/библиотек (чтобы можно было послать один или несколько файлов на сторону клиента по почте, там бы это скопировали в папку, запустили, и сбросили мне копию экрана или какой-нибудь лог для анализа).
-
- Клубмен
- Сообщения: 772
- Зарегистрирован: 01.01.1970 3:00
- Откуда: the Point of No Return ...
- Контактная информация:
http://sourceforge.net/project/showfile ... p_id=88080
tracetcp is a traceroute utility for WIN32 that uses TCP SYN packets rather than ICMP/UDP packets that the usual implementations use, thus bypassing gateways that block traditional traceroute packets. *Now works with XP sp2*
tracetcp host [options]
where host = hostName|ipAddress[:portNumber|serviceName]
if portNumber or serviceName is not present then port 80 (http)
is assumed.
tracetcp is a traceroute utility for WIN32 that uses TCP SYN packets rather than ICMP/UDP packets that the usual implementations use, thus bypassing gateways that block traditional traceroute packets. *Now works with XP sp2*
tracetcp host [options]
where host = hostName|ipAddress[:portNumber|serviceName]
if portNumber or serviceName is not present then port 80 (http)
is assumed.