У меня и моих коллег возникают проблемы с доступом к FTP-серверам Heart Internet.
Мы используем несколько компьютеров Mac и ПК, и у нас есть Linux в офисе. Ни одна из наших машин не может подключиться.
При запуске nmap с моего IP-адреса порт 21 не появляется.
Использование такого программного обеспечения, как FileZilla, просто возвращает "Время ожидания соединения истекло", как и ftp в ящике Linux.
Используя Wireshark, я могу видеть ответы «ICMP Destination unreachable (Port unreachable)» на пакеты TCP SYN.
Я могу получить доступ к тем же серверам на других портах, я могу пинговать серверы и могу отслеживать маршруты к серверам.
С моего IP:
$ telnet ftp20.extendcp.co.uk 21
Trying 79.170.44.20...
telnet: Unable to connect to remote host: Connection refused
С удаленного сервера:
$ telnet ftp20.extendcp.co.uk 21
Trying 79.170.44.20...
Connected to ftp20.extendcp.co.uk.
Escape character is '^]'.
220 FTP server ready
Telnet-соединение с другим сервером работает нормально:
$ telnet ftp.mirrorservice.org 21
Trying 212.219.56.184...
Connected to ftp.mirrorservice.org.
Escape character is '^]'.
220-----------------------------------------------------------------------------
220-Welcome to the University of Kent's UK Mirror Service.
220-
220-More information can be found at our web site: http://www.mirrorservice.org/
220-Please send comments or questions to help@mirrorservice.org.
220-----------------------------------------------------------------------------
220
Traceroute:
$ traceroute ftp20.extendcp.co.uk
traceroute to ftp20.extendcp.co.uk (79.170.44.20), 30 hops max, 60 byte packets
1 home.gateway.home.gateway (192.168.2.254) 0.608 ms 0.904 ms 2.152 ms
2 88.215.57.252 (88.215.57.252) 20.283 ms 21.010 ms 21.254 ms
3 88.215.62.78 (88.215.62.78) 20.983 ms 20.973 ms 21.014 ms
4 88.215.62.230 (88.215.62.230) 27.175 ms 27.348 ms 27.509 ms
5 88.215.62.218 (88.215.62.218) 50.552 ms 49.958 ms 50.975 ms
6 * * *
7 mx02-xe0.0.1-lon.gs.nodefour.net (83.166.164.85) 24.098 ms 26.726 ms 22.204 ms
8 mx01-xe2.0.0-lon.gs.nodefour.net (83.166.164.34) 22.147 ms 22.165 ms 24.208 ms
9 mx02-xe1.2.0-dry.dc2.nodefour.net (83.166.164.38) 35.475 ms 35.532 ms 35.879 ms
10 83.166.164.54 (83.166.164.54) 25.316 ms 34.015 ms 34.401 ms
11 ftp20.extendcp.co.uk (79.170.44.20) 25.529 ms 28.205 ms 26.298 ms
Пинг:
$ ping ftp20.extendcp.co.uk
PING ftp20.extendcp.co.uk (79.170.44.20) 56(84) bytes of data.
64 bytes from ftp20.extendcp.co.uk (79.170.44.20): icmp_req=1 ttl=53 time=24.3 ms
64 bytes from ftp20.extendcp.co.uk (79.170.44.20): icmp_req=2 ttl=53 time=21.3 ms
64 bytes from ftp20.extendcp.co.uk (79.170.44.20): icmp_req=3 ttl=53 time=24.7 ms
64 bytes from ftp20.extendcp.co.uk (79.170.44.20): icmp_req=4 ttl=53 time=21.5 ms
64 bytes from ftp20.extendcp.co.uk (79.170.44.20): icmp_req=5 ttl=53 time=25.1 ms
Telnet на другой порт:
$ telnet ftp20.extendcp.co.uk 22
Trying 79.170.44.20...
Connected to ftp20.extendcp.co.uk.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.3
TCPdump из telnet 79.170.44.20 21:
$ sudo tcpdump -n -n -v -i eth0 host 79.170.44.20
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:30:27.194966 IP (tos 0x10, ttl 64, id 1237, offset 0, flags [DF], proto TCP (6), length 60)
192.168.2.10.58366 > 79.170.44.20.21: Flags [S], cksum 0x3e9f (incorrect -> 0x00e5), seq 530375445, win 14600, options [mss 1460,sackOK,TS val 18737088 ecr 0,nop,wscale 6], length 0
14:30:27.216103 IP (tos 0xc0, ttl 53, id 12906, offset 0, flags [none], proto ICMP (1), length 88)
79.170.44.20 > 192.168.2.10: ICMP 79.170.44.20 tcp port 21 unreachable, length 68
IP (tos 0x0, ttl 54, id 1237, offset 0, flags [DF], proto TCP (6), length 60)
192.168.2.10.58366 > 79.170.44.20.21: Flags [S], cksum 0x0e94 (incorrect -> 0x00ed), seq 530375445, win 14600, options [mss 1452,sackOK,TS val 18737088 ecr 0,nop,wscale 6], length 0
TCPdump из telnet 79.170.44.20 23 продолжение сверху
14:31:23.250970 IP (tos 0x10, ttl 64, id 15043, offset 0, flags [DF], proto TCP (6), length 60)
192.168.2.10.58533 > 79.170.44.20.23: Flags [S], cksum 0x3e9f (incorrect -> 0x4da7), seq 1506485437, win 14600, options [mss 1460,sackOK,TS val 18751102 ecr 0,nop,wscale 6], length 0
14:31:23.273111 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 40)
79.170.44.20.23 > 192.168.2.10.58533: Flags [R.], cksum 0x0e1a (correct), seq 0, ack 1506485438, win 0, length 0
Мой провайдер и Heart Internet не сообщают о видимых проблемах.
Какие инструменты я могу использовать, чтобы определить, в чем проблема?
Можно ли узнать, где на сетевом маршруте к серверам отказано в соединении? (т.е. если это мой маршрутизатор или их брандмауэры, можно ли обнаружить, что это то, что отказывает в соединении?)
Мы исключили общую блокировку исходящих подключений к ftp-серверам из вашей сети, и это хорошо. Следующим шагом, вероятно, будет traceroute; в вашей сети могут быть проблемы с доступом к сетевому блоку, в котором находится целевой сервер. К счастью, они позволяют traceroute, так что ваш следующий шаг, вероятно, - проследить маршрут к месту назначения и посмотреть, где что-то упадет. Я вставил результаты трассировки для сравнения.
[me@risby]$ traceroute ftp20.extendcp.co.uk
traceroute to ftp20.extendcp.co.uk (79.170.44.20), 30 hops max, 60 byte packets
1 192.168.3.1 (192.168.3.1) 0.200 ms 0.113 ms 0.102 ms
2 lns18.inx.dsl.enta.net (188.39.1.30) 23.466 ms 23.318 ms 24.988 ms
3 gi1-8.inx.dist.dsl.enta.net (188.39.1.29) 23.782 ms 24.622 ms 25.546 ms
4 te2-2.interxion.dsl.enta.net (78.33.141.89) 26.186 ms 26.963 ms 26.802 ms
5 te2-3.interxion.core.enta.net (87.127.236.209) 27.554 ms 28.360 ms 29.085 ms
6 te4-2.telehouse-east.core.enta.net (87.127.236.137) 28.818 ms 28.512 ms 28.349 ms
7 * * *
8 mx01-xe2.3.0-lon.gs.nodefour.net (83.166.164.85) 28.397 ms 29.967 ms 30.681 ms
9 mx01-xe2.2.0-lon.gs.nodefour.net (83.166.164.34) 31.404 ms 31.112 ms 32.733 ms
10 mx02-xe1.2.0-dry.dc2.nodefour.net (83.166.164.38) 32.465 ms 33.060 ms 33.776 ms
11 83.166.164.54 (83.166.164.54) 33.529 ms 34.628 ms 34.356 ms
12 ftp20.extendcp.co.uk (79.170.44.20) 34.043 ms 30.541 ms 30.543 ms
Также было бы полезно узнать, можете ли вы получить доступ к чему-либо еще в пункте назначения; не могли бы вы вставить вывод ping ftp20.extendcp.co.uk?
редактировать: теперь мы установили, что вы используете Linux на рабочем столе, вы можете продуктивно использовать tcpdump чтобы увидеть, как далеко идет отказ. Вот мой вывод из tcpdump -n -n -v -i p1p1 host 79.170.44.20, когда я делаю telnet ftp20.extendcp.co.uk 22 (который соединяет), то telnet ftp20.extendcp.co.uk 23 (который получает Connection refused, как это должно):
14:20:40.047720 IP (tos 0x10, ttl 64, id 57773, offset 0, flags [DF], proto TCP (6), length 60)
192.168.3.11.57105 > 79.170.44.20.22: Flags [S], cksum 0x5a67 (correct), seq 2606771394, win 14600, options [mss 1460,sackOK,TS val 6671727 ecr 0,nop,wscale 7], length 0
14:20:40.078615 IP (tos 0x0, ttl 47, id 0, offset 0, flags [DF], proto TCP (6), length 60)
79.170.44.20.22 > 192.168.3.11.57105: Flags [S.], cksum 0xc8ec (correct), seq 28398605, ack 2606771395, win 14480, options [mss 1412,sackOK,TS val 609884153 ecr 6671727,nop,wscale 7], length 0
[packets deleted]
14:20:48.193195 IP (tos 0x10, ttl 64, id 34283, offset 0, flags [DF], proto TCP (6), length 60)
192.168.3.11.57462 > 79.170.44.20.23: Flags [S], cksum 0x1fa0 (correct), seq 2030528683, win 14600, options [mss 1460,sackOK,TS val 6679872 ecr 0,nop,wscale 7], length 0
14:20:48.222609 IP (tos 0x0, ttl 47, id 0, offset 0, flags [DF], proto TCP (6), length 40)
79.170.44.20.23 > 192.168.3.11.57462: Flags [R.], cksum 0xae1d (correct), seq 0, ack 2030528684, win 0, length 0
Обратите внимание, как ttl в самом первом пакете, возвращаемом с сервера, в первом случае 47. Обратите внимание, как ttl поле в пакете сброса (flags [R.]) во втором случае также 47, что является правильным и правильным для сброса, происходящего с целевого сервера. Если вы видите намного более высокий TTL, это означает, что отказ исходит откуда-то гораздо ближе.
Редактировать 2: учитывая то, что вы сказали о TTL в вашем случае, действительно похоже, что этот сервер решил не принимать ваше соединение. Возможно что-то по пути притворяется, что TCP-порт недоступен, но сделать это правильно сложно, и большинство инструментов брандмауэра не беспокоят (iirc, даже великий китайский брандмауэр, как известно, не смог правильно установить TTL для своих отказов).
Что касается Зачем удаленный сервер решил сделать это (автоматически, может быть, через fail2ban? вручную, из-за чрезмерных загрузок?), кто может сказать? Если вы не сможете связаться с администраторами сервера, вы, вероятно, не узнаете почему. Если у вас есть деловые отношения с ftp20.extendcp.co.uk, эскалация по этим маршрутам. В противном случае я бы пожал плечами и использовал прокси-сервер, если бы мне отчаянно нужно было получить пару файлов на этот сервер или с него.
Каков IP-адрес источника ответа «ICMP Destination unreachable (Port unreachable)»? Если это IP-адрес ftp-сервера, настоятельно рекомендуется (хотя и странно), что целевой сервер действительно отказывается от вашего подключения к порту 21. Поскольку 99,9% межсетевых экранов просто отбрасывают заблокированные пакеты и никогда не возвращают ЛЮБОЙ ответ. Такая ошибка ICMP обычно означает, что вы успешно достигли ftp-сервера, но на этом порту нет слушающего сокета. Учитывая, что ftp-сервер работает, остается думать, что по какой-то странной причине их программное обеспечение FTP-сервера отказывается принимать соединение с вашего IP-адреса. Кроме того, есть ли у вас возможность изменить свой IP (только для теста)?