LINUX.ORG.RU

пинг есть, а связь по портам пропадает


0

1

Привет всем!

Столкнулся со странным «явлением». На домашнем компе стоит Fedora 15, на рабочем еще 14-я.

У меня есть несколько серверов, с которыми я непосредственно работаю, поэтому примеры буду приводить на них.

Суть такова - временами любой из серверов может стать недоступным на некоторое время, т.е. в браузер пишем адрес - видим «ожидание ответа» (wget-ом тоже самое, т.е. DNS резолвит, проблема не в них), в этот же момент можно осуществить попытку доступа к SSH и видим такое же ожидание. Если подождать немного, то связь с сервером появляется, как бы пробиваемся до него и далее все работает нормально. Но через время эта история периодически повторяется. При всем этом PING никогда не пропадает до сервера, traceroute тоже в норме всегда.

В счет не берем никакие фаерволы, iptables отключал как на сервере, так и на рабочем компе, результат - один и тот же.

Я подозреваю, что что-то странное происходит с десктопом, потому что ради интереса перегружался в винду - там такого не наблюдал.

Также параллельно повторяется ситуация на всех компах в локалке (тоже федора) и на ноуте, подключенным через wifi (тоже федора).

Сегодня на работе заранее запустил vmware c WinXP и когда такой момент недоступности сервера настал, то в винде виртуальной - все было нормально, а линукс пробивался до сервера еще с пол-минуты.

Встречался ли кто-то с таким «чудом»? Может что посоветуете?

Ответ на: комментарий от AlexeyVitebsk

ок, я раскрою всю ассоциативную цепочку.
Связь до сервера организовывается чем? - Пакетами
Пакетами она организовывается когда? - В момент попытки достучаться до сервера.
Это была вводная.
Теперь теория:
Пакеты ловят чем? - сниффером
Пакеты ловят когда? - в момент попытки.

Значится что?
Значится запустите tcpdump и посмотрите что происходит в проводах и радиоволнах во время - уходят они или да, если да то приходят ли на них ответы.
Приборы что? Приборы 120

zolden ★★★★★ ()

провайдер по-разному шейпит icmp и tcp ?

Лютая перестановка порядка пакетов ?

У тя может, серваки тормозят несусветно? TCP-ответы генерит юзерспейс, А ICMP-генерит ядро сервака.

кароче, без тисипидампа - «по телефону диагнозы не ставят».

mmarkk ()
Ответ на: комментарий от mmarkk

>> У тя может, серваки тормозят несусветно? Вот только не надо самоутверждаться и считать всех вокруг нубами. Сервера ниразу не тормозят, или вы считаете, что при запросе к нему с линуха - он тормозит, а при запросе с винды - он лётает? Или другой вариант - с другого компа (и даже города) - нормально, а у меня тормозят?

Ваш коммент из серии - «пришел и ляпнул» бесполезного.

AlexeyVitebsk ()
Ответ на: комментарий от AlexeyVitebsk

эта тема из серии пришел и ляпнул, а слушать и думать не хочет. тебе тут никто лекарство не даст. могут дать направление куда копать.

anonymous ()
Ответ на: комментарий от anonymous

/etc/resolv.conf

вообще-то тут днс сервера, которые отвечают за резолв, который идеально работает. Ответ не приходит от сервера, именно от конкретного ip например

AlexeyVitebsk ()
Ответ на: комментарий от AlexeyVitebsk

что-что? в /etc/resolv.conf днс-серверы, это да. на них отправляется запрос на резолв имени. днс-сервер отвечает в соответствии с записями в бази или отправляет запрос другому днс-серверу. хост, чье имя резолвим, здесь никак не участвует. повторяю на понятном тебе языке: ответ не приходит от ip, именно от днс-сервера например. всетаки разговор лишен смысла в виду каких-либо действий от топик-стартера, направленных на прояснение ситуации. анализ выхлопа tcpdump'а, например.

anonymous ()
Ответ на: комментарий от AlexeyVitebsk

В ряде случаев, при не совсем корректном резолвере, банальный ССШ демон адово тупит при попытке от бекрезолвить IP с которого подключаются. Потому и упомянул )
Впрочем при таких раскладах и всякие профтпд тоже адово тупят :)

Jetty ★★★★★ ()
Ответ на: комментарий от anonymous

Все верно, ответ от днс сервера на domain.com = 111.222.333.444 и это идеально работает.

дальше идет запрос на 80 порт (или 22 порт ссш) на 111.222.333.444 которых стопориться при этом с ping 111.222.333.444 и traceroute 111.222.333.444 никаких проблем!

AlexeyVitebsk ()
Ответ на: комментарий от zolden

Вот что говорит tcpdump, когда пытаюсь сделать wget http://178.124.137.139

[root@alex etc]# tcpdump |grep 178.124.137.139 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 17:02:58.130670 IP 192.168.1.2.54153 > 178.124.137.139.http: Flags [S], seq 3440517680, win 14600, options [mss 1460,sackOK,TS val 32170683 ecr 0,nop,wscale 6], length 0 17:03:01.135269 IP 192.168.1.2.54153 > 178.124.137.139.http: Flags [S], seq 3440517680, win 14600, options [mss 1460,sackOK,TS val 32173688 ecr 0,nop,wscale 6], length 0 17:03:07.143275 IP 192.168.1.2.54153 > 178.124.137.139.http: Flags [S], seq 3440517680, win 14600, options [mss 1460,sackOK,TS val 32179696 ecr 0,nop,wscale 6], length 0 17:03:19.159558 IP 192.168.1.2.54153 > 178.124.137.139.http: Flags [S], seq 3440517680, win 14600, options [mss 1460,sackOK,TS val 32191712 ecr 0,nop,wscale 6], length 0 17:03:43.191260 IP 192.168.1.2.54153 > 178.124.137.139.http: Flags [S], seq 3440517680, win 14600, options [mss 1460,sackOK,TS val 32215744 ecr 0,nop,wscale 6], length 0 17:04:31.255555 IP 192.168.1.2.54153 > 178.124.137.139.http: Flags [S], seq 3440517680, win 14600, options [mss 1460,sackOK,TS val 32263808 ecr 0,nop,wscale 6], length 0

Ожидал несколько минут, так и не пробившись до сервера.

Для примера, сделал то же, но с другим сервером

[root@alex etc]# tcpdump |grep 178.124.137.130 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:09.383868 IP 192.168.1.2.43737 > 178.124.137.130.http: Flags [S], seq 2160904260, win 14600, options [mss 1460,sackOK,TS val 32361936 ecr 0,nop,wscale 6], length 0 17:06:09.400705 IP 178.124.137.130.http > 192.168.1.2.43737: Flags [S.], seq 497132510, ack 2160904261, win 5792, options [mss 1400,sackOK,TS val 1000817706 ecr 32361936,nop,wscale 9], length 0 17:06:09.400764 IP 192.168.1.2.43737 > 178.124.137.130.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 32361953 ecr 1000817706], length 0 17:06:09.400872 IP 192.168.1.2.43737 > 178.124.137.130.http: Flags [P.], seq 1:114, ack 1, win 229, options [nop,nop,TS val 32361953 ecr 1000817706], length 113 17:06:09.419856 IP 178.124.137.130.http > 192.168.1.2.43737: Flags [.], ack 114, win 12, options [nop,nop,TS val 1000817725 ecr 32361953], length 0 17:06:09.421934 IP 178.124.137.130.http > 192.168.1.2.43737: Flags [P.], seq 1:335, ack 114, win 12, options [nop,nop,TS val 1000817725 ecr 32361953], length 334 17:06:09.421967 IP 192.168.1.2.43737 > 178.124.137.130.http: Flags [.], ack 335, win 245, options [nop,nop,TS val 32361974 ecr 1000817725], length 0 17:06:09.422534 IP 192.168.1.2.43737 > 178.124.137.130.http: Flags [F.], seq 114, ack 335, win 245, options [nop,nop,TS val 32361975 ecr 1000817725], length 0 17:06:09.439246 IP 178.124.137.130.http > 192.168.1.2.43737: Flags [F.], seq 335, ack 115, win 12, options [nop,nop,TS val 1000817744 ecr 32361975], length 0 17:06:09.439303 IP 192.168.1.2.43737 > 178.124.137.130.http: Flags [.], ack 336, win 245, options [nop,nop,TS val 32361992 ecr 1000817744], length 0

тут видно, что ответы от него приходят.

В первом случае еще проверил, приходят ли от моего ip вообще хоть один запрос на сервер, - не приходит. Сразу поясню, сервер не тормозит, фаерволов не стоит, которые могут резать 80-е порты, селинукс не включен.

Еще один интересный факт, если перезапущу wan соединение на модеме - то секунд на 20-30 доступ к серверу появляется, после чего снова до него не достучатся. Модемов перепробовал несколько - дело не в них. При этом из-под винды - все всегда нормально.

Есть у кого мысли что может быть?

AlexeyVitebsk ()
Ответ на: комментарий от Komintern

[alexey@alex ~]$ ssh -vv 178.124.137.139 OpenSSH_5.6p1, OpenSSL 1.0.0d-fips 8 Feb 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 178.124.137.139 [178.124.137.139] port 22. debug1: connect to address 178.124.137.139 port 2202: Connection timed out ssh: connect to host 178.124.137.139 port 2202: Connection timed out

вот такая беда. мы просто не можем до сервера достучаться

AlexeyVitebsk ()
Ответ на: комментарий от AlexeyVitebsk

эту мешанину не сказать что легко прочитать.
Используйте tcpdump -i any host 178.124.137.130 и какой-нибудь LORCODE либо, пишите дамп в файл и потом выложите куда-нибудь tcpdump -i any host 178.124.137.130 -s0 -w dump.pcap
Также покажите ip r, ip a, ip r g 178.124.137.130 и таблицу маршрутов с винды

zolden ★★★★★ ()
Ответ на: комментарий от zolden

tcpdump -i any host 178.124.137.139

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

10:56:32.112351 IP 192.168.1.2.45474 > 178.124.137.139.http: Flags [S], seq 402997438, win 14600, options [mss 1460,sackOK,TS val 3657663 ecr 0,nop,wscale 6], length 0

10:56:35.121074 IP 192.168.1.2.45474 > 178.124.137.139.http: Flags [S], seq 402997438, win 14600, options [mss 1460,sackOK,TS val 3660672 ecr 0,nop,wscale 6], length 0

10:56:41.137446 IP 192.168.1.2.45474 > 178.124.137.139.http: Flags [S], seq 402997438, win 14600, options [mss 1460,sackOK,TS val 3666688 ecr 0,nop,wscale 6], length 0


Вот это тот, до которого достучатся не получается.

А это нормальный ответ от другого сервера


tcpdump -i any host 178.124.137.130

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

10:59:36.799935 IP 192.168.1.2.57449 > 178.124.137.130.http: Flags [S], seq 3288665409, win 14600, options [mss 1460,sackOK,TS val 3842350 ecr 0,nop,wscale 6], length 0

10:59:36.815202 IP 178.124.137.130.http > 192.168.1.2.57449: Flags [S.], seq 3057919578, ack 3288665410, win 5792, options [mss 1400,sackOK,TS val 1151625225 ecr 3842350,nop,wscale 9], length 0

10:59:36.815269 IP 192.168.1.2.57449 > 178.124.137.130.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 3842366 ecr 1151625225], length 0

10:59:36.815383 IP 192.168.1.2.57449 > 178.124.137.130.http: Flags [P.], seq 1:114, ack 1, win 229, options [nop,nop,TS val 3842366 ecr 1151625225], length 113

10:59:36.832946 IP 178.124.137.130.http > 192.168.1.2.57449: Flags [.], ack 114, win 12, options [nop,nop,TS val 1151625243 ecr 3842366], length 0

10:59:36.833702 IP 178.124.137.130.http > 192.168.1.2.57449: Flags [P.], seq 1:335, ack 114, win 12, options [nop,nop,TS val 1151625243 ecr 3842366], length 334

10:59:36.833722 IP 192.168.1.2.57449 > 178.124.137.130.http: Flags [.], ack 335, win 245, options [nop,nop,TS val 3842384 ecr 1151625243], length 0

10:59:36.834313 IP 192.168.1.2.57449 > 178.124.137.130.http: Flags [F.], seq 114, ack 335, win 245, options [nop,nop,TS val 3842385 ecr 1151625243], length 0

10:59:36.849406 IP 178.124.137.130.http > 192.168.1.2.57449: Flags [F.], seq 335, ack 115, win 12, options [nop,nop,TS val 1151625259 ecr 3842385], length 0

10:59:36.849463 IP 192.168.1.2.57449 > 178.124.137.130.http: Flags [.], ack 336, win 245, options [nop,nop,TS val 3842400 ecr 1151625259], length 0


Самое интересное, что вчера ближе к вечеру, сервер, который не отзывается, стал доступным на какое-то время, потом снова исчез.

В локалке у нас всего 3 компа.
2 с 15-й федорой рабочие и один центос 5.6 - девелоперский.
Интересно, что с девелоперского вообще все идеально видит, когда с двух рабочих - нет.

AlexeyVitebsk ()
Ответ на: комментарий от aol
em1       Link encap:Ethernet  HWaddr 00:26:18:FE:2C:36  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::226:18ff:fefe:2c36/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28643 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25491 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:27366835 (26.0 MiB)  TX bytes:2830231 (2.6 MiB)
          Interrupt:41 Base address:0x8000

Способ стандартный, локалка, в ней adsl модем в режиме роутера.

route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     1      0        0 em1
default         192.168.1.1     0.0.0.0         UG    0      0        0 em1
AlexeyVitebsk ()
Ответ на: комментарий от zolden

Спасибо за советы :)

arping ничего не дал, мак как был, так и остается.

Заметил еще одну особенность. Если рестартануть модем, потом быстренько в браузере начать запрашивать домен, который расположен на том сервере - все работает, так нужно продолжать некоторое время, рефрешить страницу. Далее - из консоли wget-ом - уже не хочет, в то время, когда в браузере без проблем отрабатывает. Чудеса. Если перестать рефрешить в браузере - то через некоторое время и в браузере не будет доступно.

Вот tcpdump из консоля, wget-ом, через некоторое время, когда не доступно ничего

19:00:33.625050 IP 192.168.1.2.40677 > 178.124.137.139.http: Flags [S], seq 2921580912, win 14600, options [mss 1460,sackOK,TS val 1232176 ecr 0,nop,wscale 6], length 0
19:00:43.921795 IP 192.168.1.2.40679 > 178.124.137.139.http: Flags [S], seq 3228906840, win 14600, options [mss 1460,sackOK,TS val 1242472 ecr 0,nop,wscale 6], length 0
19:00:45.641053 IP 192.168.1.2.40677 > 178.124.137.139.http: Flags [S], seq 2921580912, win 14600, options [mss 1460,sackOK,TS val 1244192 ecr 0,nop,wscale 6], length 0
19:00:46.929328 IP 192.168.1.2.40679 > 178.124.137.139.http: Flags [S], seq 3228906840, win 14600, options [mss 1460,sackOK,TS val 1245480 ecr 0,nop,wscale 6], length 0
19:00:52.937037 IP 192.168.1.2.40679 > 178.124.137.139.http: Flags [S], seq 3228906840, win 14600, options [mss 1460,sackOK,TS val 1251488 ecr 0,nop,wscale 6], length 0

А это тут же, но из браузера

19:01:04.205875 IP 192.168.1.2.43555 > 178.124.137.139.http: Flags [P.], seq 18818:19696, ack 70958, win 1002, options [nop,nop,TS val 1262756 ecr 6529352], length 878
19:01:04.272694 IP 178.124.137.139.http > 192.168.1.2.43555: Flags [.], ack 19696, win 126, options [nop,nop,TS val 6565826 ecr 1262756], length 0
19:01:04.372139 IP 178.124.137.139.http > 192.168.1.2.43555: Flags [.], seq 70958:72346, ack 19696, win 126, options [nop,nop,TS val 6565922 ecr 1262756], length 1388
19:01:04.372180 IP 192.168.1.2.43555 > 178.124.137.139.http: Flags [.], ack 72346, win 1002, options [nop,nop,TS val 1262923 ecr 6565922], length 0
19:01:04.375288 IP 178.124.137.139.http > 192.168.1.2.43555: Flags [.], seq 72346:73734, ack 19696, win 126, options [nop,nop,TS val 6565922 ecr 1262756], length 1388
19:01:04.375322 IP 192.168.1.2.43555 > 178.124.137.139.http: Flags [.], ack 73734, win 1002, options [nop,nop,TS val 1262926 ecr 6565922], length 0
19:01:04.378500 IP 178.124.137.139.http > 192.168.1.2.43555: Flags [.], seq 73734:75122, ack 19696, win 126, options [nop,nop,TS val 6565922 ecr 1262756], length 1388
19:01:04.378541 IP 192.168.1.2.43555 > 178.124.137.139.http: Flags [.], ack 75122, win 1002, options [nop,nop,TS val 1262929 ecr 6565922], length 0
19:01:04.382034 IP 178.124.137.139.http > 192.168.1.2.43555: Flags [.], seq 75122:76510, ack 19696, win 126, options [nop,nop,TS val 6565922 ecr 1262756], length 1388
19:01:04.382073 IP 192.168.1.2.43555 > 178.124.137.139.http: Flags [.], ack 76510, win 1002, options [nop,nop,TS val 1262933 ecr 6565922], length 0
19:01:04.385412 IP 178.124.137.139.http > 192.168.1.2.43555: Flags [.], seq 76510:77898, ack 19696, win 126, options [nop,nop,TS val 6565922 ecr 1262756], length 1388
19:01:04.385430 IP 192.168.1.2.43555 > 178.124.137.139.http: Flags [.], ack 77898, win 1002, options [nop,nop,TS val 1262936 ecr 6565922], length 0
19:01:04.396947 IP 178.124.137.139.http > 192.168.1.2.43555: Flags [P.], seq 77898:79197, ack 19696, win 126, options [nop,nop,TS val 6565942 ecr 1262926], length 1299
19:01:04.396981 IP 192.168.1.2.43555 > 178.124.137.139.http: Flags [.], ack 79197, win 1002, options [nop,nop,TS val 1262947 ecr 6565942], length 0
19:01:04.463649 IP 192.168.1.2.43556 > 178.124.137.139.http: Flags [P.], seq 10559:11501, ack 1960, win 513, options [nop,nop,TS val 1263014 ecr 6529322], length 942
19:01:04.463792 IP 192.168.1.2.43557 > 178.124.137.139.http: Flags [P.], seq 10526:11448, ack 2042, win 497, options [nop,nop,TS val 1263014 ecr 6529337], length 922
19:01:04.463899 IP 192.168.1.2.43559 > 178.124.137.139.http: Flags [P.], seq 10668:11535, ack 1878, win 480, options [nop,nop,TS val 1263014 ecr 6529366], length 867
19:01:04.477570 IP 178.124.137.139.http > 192.168.1.2.43555: Flags [.], seq 79197:80585, ack 19696, win 126, options [nop,nop,TS val 6566027 ecr 1262947], length 1388

На всякий случай, это с 3-й машинки (centos 5.6) из этой же локалки, где все работает всегда.

tcpdump -i any host 178.124.137.139
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
19:11:08.117843 IP 192.168.1.4.52664 > 178.124.137.139.http: S 399705049:399705049(0) win 5840 <mss 1460,sackOK,timestamp 368132453 0,nop,wscale 7>
19:11:08.133168 IP 178.124.137.139.http > 192.168.1.4.52664: S 420287970:420287970(0) ack 399705050 win 5792 <mss 1400,sackOK,timestamp 7170002 368132453,nop,wscale 9>
19:11:08.133184 IP 192.168.1.4.52664 > 178.124.137.139.http: . ack 1 win 46 <nop,nop,timestamp 368132469 7170002>
19:11:08.133398 IP 192.168.1.4.52664 > 178.124.137.139.http: P 1:121(120) ack 1 win 46 <nop,nop,timestamp 368132469 7170002>
19:11:08.150590 IP 178.124.137.139.http > 192.168.1.4.52664: . ack 121 win 12 <nop,nop,timestamp 7170020 368132469>
19:11:08.151313 IP 178.124.137.139.http > 192.168.1.4.52664: P 1:335(334) ack 121 win 12 <nop,nop,timestamp 7170020 368132469>
19:11:08.151323 IP 192.168.1.4.52664 > 178.124.137.139.http: . ack 335 win 54 <nop,nop,timestamp 368132487 7170020>
19:11:08.152003 IP 192.168.1.4.52664 > 178.124.137.139.http: F 121:121(0) ack 335 win 54 <nop,nop,timestamp 368132487 7170020>
19:11:08.166662 IP 178.124.137.139.http > 192.168.1.4.52664: F 335:335(0) ack 122 win 12 <nop,nop,timestamp 7170036 368132487>
19:11:08.166678 IP 192.168.1.4.52664 > 178.124.137.139.http: . ack 336 win 54 <nop,nop,timestamp 368132502 7170036>

Насчет модема, менял. История точно такая же. Дело точно в федоре, т.к. как я уже и говорил, в этой же сетке стоит машина с центос 5.6 и с нее все всегда доступно, также как и из винды (запущенной в vmware).

Есть еще мысли?

AlexeyVitebsk ()
Ответ на: комментарий от AlexeyVitebsk

Я опишу случай из жизни:
у товарища тоже был какой-то ADSL модем, в дуал буте стояла винда и линупс, или даже там два ноута было разных - не суть.
Суть в том, что с винды всё работало, с линупса иногда работало, но чаще всего нет. Списывал на полтергейст и происки Билли.
Посмотрели в сторону ARP, увидели что на одном IP светятся разные МАС'и (по количеству портов).
Хозяин модема в итоге курил форумы провайдера который дал ему модем и ковырял настройки бриджа.
Как я понял, у винды и линупса разные дефолтные тайминги для хранения ARP или что-то в этом роде.
В итоге она успевала достучаться до правильного порта модема и запоминала правильный MAC адрес.
Часть симптомов похожи на ваш случай, поэтому могу только предположить, что собака порылась примерно там же.

zolden ★★★★★ ()
Ответ на: комментарий от zolden

а как же тогда с рабочим CentOS и глюками в федоре в одно и то же время в одной и той же сети? :)

Еще, кстати, на офисе у меня еще 14-я федора... там такие глюки наблюдаются, но интересно, что если долбиться на сервер в течение 20-30 сек - связь появляется. Потом снова может исчезнуть (а может нет).

AlexeyVitebsk ()
Ответ на: комментарий от zolden

Вот сейчас ночь, 2-й комп с федорой выключен и у меня идеально доступен тот самый сервер, до которого днями не достучаться.... совпадение?

AlexeyVitebsk ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.