Отладка соединения отклонила ответ на порт 21
У нас с коллегами проблемы с доступом к 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 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 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 of 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 of 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 не сообщают о видимых проблемах.
Какие инструменты я могу использовать, чтобы определить, где проблема?
Можно ли определить, где по сетевому маршруту к серверам отказывается соединение? (т. е. если это мой роутер или их брандмауэры, можно ли обнаружить, что именно он отказывается от соединения?)
2 ответа
Мы исключили общий блок для исходящих соединений с ftp-серверами из вашей сети, и это хорошо. Следующим шагом, вероятно, является traceroute; В вашей сети могут возникнуть проблемы с доступом к сетевому блоку, в котором находится целевой сервер. К счастью, они позволяют 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 недоступно (порт недоступен)"? Если это IP-адрес ftp-сервера, он настоятельно рекомендует (хотя и странно), что действительно сервер назначения отказывает в вашем подключении к порту 21 . 99,9% брандмауэров просто сбрасывают заблокированный пакет и никогда не возвращают ЛЮБОЙ ответ. Такая ошибка ICMP обычно означает, что вы успешно достигли ftp-сервера, но на этом порту нет прослушивающего сокета. Учитывая, что FTP-сервер работает, остается подумать, что по какой-то странной причине их программное обеспечение FTP-сервера отказывается принимать соединение с вашего IP. Кроме того, у вас есть возможность изменить свой IP (только для теста)?