Все соединения из этой сети застревают в состоянии SYN_RECV, соединения из моего дома или телефона правильно устанавливаются

Вчера мой сервер (линодный VPS) внезапно начинал отключаться по таймауту при каждом запросе.

Я довольно неопытен в работе с сетями и хотел бы изучить процесс отладки этих проблем с подключением.

Меня смущает то, что вчера некоторые люди (мой телефон, я дома, друзья дома) могли постоянно заходить на сайт, и я вижу с помощью netstat что соединение установлено. Я отключил межсетевые экраны и настроил iptables на прием всех подключений, чтобы исключить любые странные автоматические правила, помещающие наш IP в черный список. Я не уверен, что это актуально, но время трассировки из локальной сети истекло - трассировка с некоторых машин за пределами находит мой сервер.

Я подтвердил правильность различных настроек, сравнив их с настройками на моем сервере разработки, который работает правильно.

Следующие файлы соответствуют моей среде разработки (за исключением соответствующих IP-адресов):

/etc/hosts 
/etc/hosts.allow
/etc/hosts.deny
/etc/networking/interfaces 
ifconfig

Apache прослушивает порт 80, и настройка выглядит точно так же, как мой работающий сервер.

# server that doesn't work:
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      22008/apache2
tcp        0      0 69.164.201.172:80       71.56.137.10:57487      SYN_RECV    -

# server that does work
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      3334/apache2
tcp        0      0 72.14.189.46:80         71.56.137.10:57490      ESTABLISHED 20931/apache2

Моя попытка понять

Каждый раз, когда я загружаю страницу один раз, netstat -an | grep :80 показывает все соединения в состоянии SYN_RECV.

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 69.164.201.172:80       71.56.137.10:56657      SYN_RECV
tcp        0      0 69.164.201.172:80       71.56.137.10:56669      SYN_RECV
tcp        0      0 69.164.201.172:80       71.56.137.10:56671      SYN_RECV

Так что SYN_RECV означает, что сервер ожидает ACK для отправки обратно от клиента.
Как мне отладить, отправляется ли обратно ACK? Как мне отладить, где эта связь не работает?

Вот как выглядит tcpdump, когда я пытаюсь загрузить страницу один раз.

В вставке ниже мой сервер постоянно отправляет пакеты клиенту и не получает ответа.

Что это значит? Что клиент не получает ответа? А может я глотаю ответ где-то на сервере? Как мне узнать, как еще больше сузить виновника?

tcpdump -i eth0 -n -tttt port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
2011-05-25 20:12:54.627417 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2011-05-25 20:12:54.627512 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:54.814463 IP 69.164.201.172.80 > 71.56.137.10.57157: Flags [S.], seq 604630211, ack 496040070, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:55.214482 IP 69.164.201.172.80 > 71.56.137.10.57158: Flags [S.], seq 998358186, ack 2224730755, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:57.624737 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2011-05-25 20:12:57.624793 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:59.014477 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:03.618790 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,nop,sackOK], length 0
2011-05-25 20:13:03.618866 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:05.014514 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:17.014504 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0

tcpdump для функционального сервера

Посмотрев на tcpdump для моего функционального сервера, я действительно вижу обратную и четвертую связь между сервером и клиентом.

00:00:00.000000 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [S], seq 34114118s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
00:00:00.000110 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [S.], seq 2454858 win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
00:00:00.061827 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 1, win 100:00:00.004292 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 1:597, ngth 596
00:00:00.000074 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 597, win00:00:00.493990 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], seq 1:2921, ngth 2920
00:00:00.000024 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 2921:30, length 98
00:00:00.065135 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 3019, wi00:00:00.034766 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 597:12925, length 699
00:00:00.000035 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 1296, wi00:00:00.000457 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 3019:328, length 211
00:00:00.019196 IP 71.56.137.10.57262 > 72.14.189.46.80: Flags [S], seq 10674886s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0

Мы будем очень благодарны за любые предложения, пояснения или комментарии, чтобы я мог немного больше понимать TCP и, надеюсь, будет немного более полезным в следующий раз, когда мне понадобится отладить подобную проблему.

Спасибо!

На этот усталый глаз похоже, что рядом с рассматриваемым сервером возникла какая-то проблема с маршрутизацией. Пакеты приходят по одному пути, но, кажется, уходят по другому пути, и что-то с отслеживанием состояния находится на этом пути и отбрасывает странные пакеты «ACK без SYN».

Однажды со мной такое случилось. В конечном итоге у сервера была плохая сетевая маска, поэтому при поступлении трафика из другой подсети он выдавал ARP-запрос, чтобы получить MAC-адрес узла. К сожалению, для меня как маршрутизатор, так и наш балансировщик нагрузки были включены для Proxy-ARP, и балансировщик нагрузки был немного быстрее при срабатывании триггера, чем маршрутизатор. Таким образом, пакеты SYN приходили через маршрутизатор, но пытались покинуть подсеть через балансировщик нагрузки. Поскольку у LB не было соединения для этого пакета ACk, он уронил его на пол.

В вашем случае некоторые разумные маршруты трассировки могут пролить свет на проблемы сетевого пути. С затронутого сервера попытайтесь проследить маршрут до IP-адресов, которые вызывают проблему, и сделайте то же самое с тех же IP-адресов. Если вы идете разными путями, возможно, это именно то, что вам нужно.

просто была такая же проблема.

В моем случае это была неправильная конфигурация сети.

сервер был настроен с 10.0.1.111 255.255.254.0, а клиент был настроен с 10.0.0.15 255.255.255.0. Изменение сетевой маски на стороне клиента на / 23 решило мою проблему.

надеюсь, это может помочь.

с уважением tcpdump