LINUX.ORG.RU
решено Форум — Admin  

CentOs 5. connection timeout. NAT


0

2

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

Есть сервер под управлением CentOs 5.
Два пользователя, которые подключаются удаленно к серверу, находятся за общим натом.
Оба стараются подключиться к серверу - неважно какому сервису http ил smtp.

Кто подключается первым - у того все в порядке.
Второй же ничего от сервера получить не может. Получает ошибки Connection timeout.

Совершенно неважно к какому сервису подключается первый. Подключившись к тому же http второй пользователь уже не может подключиться ни к http на к smtp

tcpdump второго в эти моменты показывает следущее.
00:00:00.000007 IP 192.168.3.254.47362 > server.80: Flags [S], seq 2981129532, win 5840, options [mss 1460,sackOK,TS val 24025938 ecr 0,nop,wscale 7], length 0
00:00:00.000028 IP 192.168.3.254.47363 > server.80: Flags [S], seq 2979964165, win 5840, options [mss 1460,sackOK,TS val 24025938 ecr 0,nop,wscale 7], length 0
00:00:00.000020 IP 192.168.3.254.47365 > server.80: Flags [S], seq 2973523087, win 5840, options [mss 1460,sackOK,TS val 24025938 ecr 0,nop,wscale 7], length 0
00:00:00.000029 IP 192.168.3.254.47366 > server.80: Flags [S], seq 2983260111, win 5840, options [mss 1460,sackOK,TS val 24025938 ecr 0,nop,wscale 7], length 0
00:00:00.000029 IP 192.168.3.254.47367 > server.80: Flags [S], seq 2978387893, win 5840, options [mss 1460,sackOK,TS val 24025938 ecr 0,nop,wscale 7], length 0
00:00:00.000035 IP 192.168.3.254.47368 > server.80: Flags [S], seq 2983111306, win 5840, options [mss 1460,sackOK,TS val 24025938 ecr 0,nop,wscale 7], length 0


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

Ситуация повторяется вне зависимости от того где находятся клинетские машины. Главное что бы они были за общим натом.

Остановка iptables ни к чему не приводит.
sysctl содержит дефолтовые настройки.

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

Сначала вас не понял.
Думаю проблема не в конфигурации ната.
Потому что я просил разных людей в разных городах протестировать ситуацию. И у всех было одно и тоже.
Тем не менее

В одном месте в качестве роутера выступает бытова АПешка.
В другом месте

# Generated by iptables-save v1.3.8 on Sat Jul 9 18:37:08 2011
*mangle
:PREROUTING ACCEPT [14665067:11327556495]
:INPUT ACCEPT [10097570:8774979945]
:FORWARD ACCEPT [4564771:2552224442]
:OUTPUT ACCEPT [10591549:8736595014]
:POSTROUTING ACCEPT [15077378:11270363862]
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Sat Jul 9 18:37:08 2011
# Generated by iptables-save v1.3.8 on Sat Jul 9 18:37:08 2011
*nat
:PREROUTING ACCEPT [207244:12944935]
:POSTROUTING ACCEPT [74819:4746512]
:OUTPUT ACCEPT [71343:4521550]
-A POSTROUTING -s 192.168.1.1 -o ppp0 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.1.50 -o ppp0 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.1.250 -o ppp0 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.1.50 -o ppp0 -p tcp -m multiport --dports 53 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.1.50 -o ppp0 -p udp -m multiport --dports 53 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.1.7 -o ppp0 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.2.5 -o ppp0 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.1.223 -o eth0 -j SNAT --to-source 192.168.2.7
-A POSTROUTING -s 192.168.3.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 53 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.2.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 53 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.3.0/255.255.255.0 -o ppp0 -p udp -m multiport --dports 53 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.2.0/255.255.255.0 -o ppp0 -p udp -m multiport --dports 53 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.3.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 110 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.2.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 110 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.3.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 995 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.3.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 7002 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.3.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 25 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.2.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 25 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 25 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.0.21 -o ppp0 -p tcp -m multiport --dports 5568 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.0.21 -o ppp0 -p tcp -m multiport --dports 465 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.0.21 -o ppp0 -p tcp -m multiport --dports 110 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -p tcp -m multiport --dports 53 -j SNAT --to-source 85.90.197.186
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -p udp -m multiport --dports 53 -j SNAT --to-source 85.90.197.186
COMMIT
# Completed on Sat Jul 9 18:37:08 2011
# Generated by iptables-save v1.3.8 on Sat Jul 9 18:37:08 2011
*filter
:INPUT DROP [4492:342717]
:FORWARD DROP [83086:18883328]
:OUTPUT ACCEPT [10591602:8736601118]
-A INPUT -s 212.42.77.202 -j ACCEPT
-A INPUT -s 91.196.98.234 -j ACCEPT
-A INPUT -s 193.106.163.249 -j ACCEPT
-A INPUT -s 93.183.196.41 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -i eth0 -j ACCEPT
-A INPUT -s 192.168.1.7 -i eth0 -j ACCEPT
-A INPUT -s 192.168.0.21 -i eth0 -j ACCEPT
-A INPUT -s 192.168.1.50 -i eth0 -j ACCEPT
-A INPUT -s 192.168.1.250 -d 77.88.202.130 -i eth0 -j ACCEPT
-A INPUT -s 192.168.1.250 -d 77.88.202.131 -i eth0 -j ACCEPT
-A INPUT -s 192.168.1.250 -i eth0 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -s 192.168.2.0/255.255.255.0 -i eth0 -j ACCEPT
-A INPUT -s 192.168.3.0/255.255.255.0 -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i ppp0 -p tcp -m multiport --dports 25 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m multiport --dports 22 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m multiport --dports 3128 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m multiport --dports 8080 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m multiport --dports 443 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m multiport --dports 53 -j ACCEPT
-A INPUT -i ppp0 -p udp -m multiport --dports 53 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m multiport --dports 80 -j ACCEPT
-A INPUT -i ppp0 -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i ppp0 -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -i ppp0 -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -i ppp0 -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i ppp0 -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -i ppp0 -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.1.50 -j ACCEPT
-A FORWARD -d 192.168.1.50 -j ACCEPT
-A FORWARD -s 192.168.1.250 -j ACCEPT
-A FORWARD -d 192.168.1.250 -j ACCEPT
-A FORWARD -s 192.168.1.7 -j ACCEPT
-A FORWARD -d 192.168.1.7 -j ACCEPT
-A FORWARD -s 192.168.1.1 -j ACCEPT
-A FORWARD -d 192.168.1.1 -j ACCEPT
-A FORWARD -s 192.168.1.223 -j ACCEPT
-A FORWARD -d 192.168.1.223 -j ACCEPT
-A FORWARD -d 192.168.2.5 -j ACCEPT
-A FORWARD -s 192.168.2.5 -j ACCEPT
-A FORWARD -s 192.168.3.0/255.255.255.0 -j ACCEPT
-A FORWARD -s 192.168.2.0/255.255.255.0 -j ACCEPT
-A FORWARD -d 192.168.3.0/255.255.255.0 -j ACCEPT
-A FORWARD -s 192.168.0.0/255.255.255.0 -j ACCEPT
-A FORWARD -d 192.168.0.0/255.255.255.0 -j ACCEPT
COMMIT
# Completed on Sat Jul 9 18:37:08 2011



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

а если очистить iptables, поставить в FORWARD политику ACCEPT, а в POSTROUTING - "-A POSTROUTING -o ppp0 -j SNAT --to-source 85.90.197.186", работает также?

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

Тогда всё очень загадочно. Я правильно понял, что схема такая:

server <- интернет -> NAT <- внутренняя сеть -> clients

1) server - твой сервер
* с «белым» (valid) внешним IP
* подключен к провайдеру напрямую
* ни iptables, ни selinux ничего не запрещают
* открыты 80/tcp, 25/tcp

2) nat - любой маршрутизатор с NAT

3) clients - два клиента


Я бы начал с того, что из сети клиентов во время проблемы попытался подключиться telnet'ом. Если не получается - собрал бы полный (-s 0) дамп со стороны
а) сервера
б) клиента с проблемой

и внимательно смотрел бы эти дампы wireshark'ом

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

> а если очистить iptables, поставить в FORWARD политику ACCEPT, а в POSTROUTING - "-A POSTROUTING -o ppp0 -j SNAT --to-source 85.90.197.186", работает также?

да. Ничего не изменилось

Demimurych
() автор топика
Ответ на: комментарий от router

> Тогда всё очень загадочно. Я правильно понял, что схема такая: 1)совершенно верно.

2) Да.

3) Да

Буквально черная магия. Еще одна вводная, которая делает все еще загадочнее.

Такое просиходит только с клинетами на которых установлен линукс. Дистрибутивы разные.

т.е. Если один клиент с Linux Desktopa второй с windows desktopa то все работает как надо.

как только оба клиента используют Linux в качестве десктопа начинается такая петрушка.

Ситуация воспроизводится 100%.

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

«tcpdump не бубен, а средство диагностики». Да пребудет с тобой сила, брат

router ★★★★★
()

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

Сервер как подключен --- чистый ethernet или pptp или ещё что? Может просто провайдер блокирует пакеты, считая их сканом портов.

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

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


Записи поялвяются не сразу. А одна за другой через определенный промежуток времени.

Вкладка одна.


Сервер как подключен --- чистый ethernet или pptp или ещё что? Может просто провайдер блокирует пакеты, считая их сканом портов


чистый ethernet

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

Да не может здесь быть никакой магии, сколько раз таких постов в Admin было, мол, магия, а на деле кривые настройки :)

Короче, как я понял:

Есть сервер (heaz.kharkov.ru) 

22/tcp   open   ssh
25/tcp   open   smtp
53/tcp   closed domain
80/tcp   open   http
443/tcp  closed https
3128/tcp open   squid-http
8080/tcp open   http-proxy

К нему, соответственно коннектятся клиенты на 80 порт. Ну надо же, во-первых вывод tcpdump на стороне сервера, логи апача и т.д.

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

Есть сервер (heaz.kharkov.ru)

нет

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


tcpdump попробую сделать

в логах апача и прочих серверов никаких записей о соединении не появляется.


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

>Записи поялвяются не сразу. А одна за другой через определенный промежуток времени.

Если считать, что «00:00:00.000007» показывает время, то я бы назвал такой промежуток времени «одновременно». За 20 мкс пакет никуда сбегать не успеет.

mky ★★★★★
()

посмотри тцпдамп на стороне сервера в момент попытки установки соединения вторым клиентом. для чистоты эксперимента устанавливай соединения сам, телнетом например. если окажется, что сервер видит SYN и шлет ответ, то проблема однозначно в нате. я практически уверен что проблема именно в клиентском нате и на сервере все нормально. еще можно на самом нате посмотреть.

// вообще не помешало дампы сюда и ип-схему сети (чтобы понятно сразу было что и куда), телепаты уехали на лето в отпуск, за них отдуваться сложно

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

У клиента и на сервере запустил tcpdump следующей строкой
tcpdump -n -nn -ttt port 25

на стороне клиента в момент проблемы запустил
telnet server 25

Вывод tcpdump на стороне клиента

00:02:17.344276 IP 192.168.3.254.35173 > server.25: Flags [S], seq 1015882732, win 5840, options [mss 1460,sackOK,TS val 6080272 ecr 0,nop,wscale 7], length 0
00:00:03.005717 IP 192.168.3.254.35173 > server.25: Flags [S], seq 1015882732, win 5840, options [mss 1460,sackOK,TS val 6080573 ecr 0,nop,wscale 7], length 0
00:00:06.010002 IP 192.168.3.254.35173 > server.25: Flags [S], seq 1015882732, win 5840, options [mss 1460,sackOK,TS val 6081174 ecr 0,nop,wscale 7], length 0
00:00:12.020061 IP 192.168.3.254.35173 > server.25: Flags [S], seq 1015882732, win 5840, options [mss 1460,sackOK,TS val 6082376 ecr 0,nop,wscale 7], length 0
00:00:24.079972 IP 192.168.3.254.35173 > server.25: Flags [S], seq 1015882732, win 5840, options [mss 1460,sackOK,TS val 6084784 ecr 0,nop,wscale 7], length 0
00:00:48.159833 IP 192.168.3.254.35173 > server.25: Flags [S], seq 1015882732, win 5840, options [mss 1460,sackOK,TS val 6089600 ecr 0,nop,wscale 7], length 0
00:01:13.044346 IP 192.168.3.254.38386 > server.25: Flags [S], seq 3637267013, win 5840, options [mss 1460,sackOK,TS val 6096904 ecr 0,nop,wscale 7], length 0
00:00:03.005796 IP 192.168.3.254.38386 > server.25: Flags [S], seq 3637267013, win 5840, options [mss 1460,sackOK,TS val 6097205 ecr 0,nop,wscale 7], length 0
00:00:06.018000 IP 192.168.3.254.38386 > server.25: Flags [S], seq 3637267013, win 5840, options [mss 1460,sackOK,TS val 6097806 ecr 0,nop,wscale 7], length 0
00:00:12.011994 IP 192.168.3.254.38386 > server.25: Flags [S], seq 3637267013, win 5840, options [mss 1460,sackOK,TS val 6099008 ecr 0,nop,wscale 7], length 0
00:00:24.080067 IP 192.168.3.254.38386 > server.25: Flags [S], seq 3637267013, win 5840, options [mss 1460,sackOK,TS val 6101416 ecr 0,nop,wscale 7], length 0
00:00:48.080001 IP 192.168.3.254.38386 > server.25: Flags [S], seq 3637267013, win 5840, options [mss 1460,sackOK,TS val 6106224 ecr 0,nop,wscale 7], length 0
--------------------
00:00:00.059842 IP server.25 > 192.168.3.254.38386: Flags [S.], seq 668319591, ack 3637267014, win 5792, options [mss 1460,sackOK,TS val 872139418 ecr 6106224,nop,wscale 10], length 0
00:00:00.000044 IP 192.168.3.254.38386 > server.25: Flags [.], ack 1, win 46, options [nop,nop,TS val 6106230 ecr 872139418], length 0
00:00:00.179854 IP server.25 > 192.168.3.254.38386: Flags [P.], seq 1:26, ack 1, win 6, options [nop,nop,TS val 872139599 ecr 6106230], length 25
00:00:00.000041 IP 192.168.3.254.38386 > server.25: Flags [.], ack 26, win 46, options [nop,nop,TS val 6106248 ecr 872139599], length 0



Вывод tcpdump на стороне сервера
137. 350614 IP host.35173 > server.25: S 1015882732:1015882732(0) win 5840 <mss 1460,sackOK,timestamp 6080272 0,nop,wscale 7>
3. 005812 IP host.35173 > server.25: S 1015882732:1015882732(0) win 5840 <mss 1460,sackOK,timestamp 6080573 0,nop,wscale 7>
6. 009635 IP host.35173 > server.25: S 1015882732:1015882732(0) win 5840 <mss 1460,sackOK,timestamp 6081174 0,nop,wscale 7>
12. 023521 IP host.35173 > server.25: S 1015882732:1015882732(0) win 5840 <mss 1460,sackOK,timestamp 6082376 0,nop,wscale 7>
24. 079014 IP host.35173 > server.25: S 1015882732:1015882732(0) win 5840 <mss 1460,sackOK,timestamp 6084784 0,nop,wscale 7>
48. 161303 IP host.35173 > server.25: S 1015882732:1015882732(0) win 5840 <mss 1460,sackOK,timestamp 6089600 0,nop,wscale 7>
73. 048577 IP host.38386 > server.25: S 3637267013:3637267013(0) win 5840 <mss 1460,sackOK,timestamp 6096904 0,nop,wscale 7>
3. 006814 IP host.38386 > server.25: S 3637267013:3637267013(0) win 5840 <mss 1460,sackOK,timestamp 6097205 0,nop,wscale 7>
6. 017630 IP host.38386 > server.25: S 3637267013:3637267013(0) win 5840 <mss 1460,sackOK,timestamp 6097806 0,nop,wscale 7>
12. 010023 IP host.38386 > server.25: S 3637267013:3637267013(0) win 5840 <mss 1460,sackOK,timestamp 6099008 0,nop,wscale 7>
24. 081764 IP host.38386 > server.25: S 3637267013:3637267013(0) win 5840 <mss 1460,sackOK,timestamp 6101416 0,nop,wscale 7>
48. 081574 IP host.38386 > server.25: S 3637267013:3637267013(0) win 5840 <mss 1460,sackOK,timestamp 6106224 0,nop,wscale 7>
----------------
000036 IP server.25 > host.38386: S 668319591:668319591(0) ack 3637267014 win 5792 <mss 1460,sackOK,timestamp 872139418 6106224,nop,wscale 10>
062429 IP host.38386 > server.25: . ack 1 win 46 <nop,nop,timestamp 6106230 872139418>
118410 IP server.25 > host.38386: P 1:26(25) ack 1 win 6 <nop,nop,timestamp 872139599 6106230>
059490 IP host.38386 > server.25: . ack 26 win 46 <nop,nop,timestamp 6106248 872139599>



Гарантирую что никто другой в этот момент к 25 порту не подключался.
То что отделено пунктирной линией, это в момент когда проблема исчезла и telnet server 25 отработал как нужно.

В это же момент на проблемном клинете запустил ping к серверу.
Пинг был нормальный без потреь.




Demimurych
() автор топика
Ответ на: комментарий от anton_jugatsu

>Это при каких правилах iptables на этом хосте? Ёще добавь

не могу ответить на это вопрос. в качестве роутера в данном эксперименте выступала бытовая апешка. Где нат включается галочкой.

Demimurych
() автор топика
Ответ на: комментарий от anton_jugatsu

> Да ху* с ней с этой точкой доступа, какие правила на сервере, _к которому_ коннектятся.

iptables остановлен

Demimurych
() автор топика

>Остановка iptables ни к чему не приводит.

Проверьте, что все цепочки пустые и везде политика ACCEPT, команой iptables-save или iptables для каждой из таблиц.

sysctl содержит дефолтовые настройки.

На правах чёрной магии попробуйте отключить rp_filter и tcp_syncookies.

В dmesg нет сообщений от переполнении каких-нибудь таблиц или чего ещё подозрительного?

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

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

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

чисто теоретически, найти себе лишний геморрой можно на динамической маршрутизации (ip table / ip rule)

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

можно. но как этим обьяснить отсутствие ответов на SYN? уходят с другого интерфейса?

// видел похожий баг на Соляре - СИН приходит, ответа нет. причем всем хостам кроме нескольких избранных. стейта в нетстате соответственно нет. оказалось - баг в коре коде стека.

val-amart ★★★★★
()
Ответ на: комментарий от router

Сервер железный или виртуалка? Какая точно версия и битность (32/64) centos ?


Своя железка. Cent OS 64


На правах чёрной магии попробуйте отключить rp_filter и tcp_syncookies.


Установил в 0 Проблема пропала.

НО, возможно это совпадение, а может и нет Сейчас, например страница, может загрузиться на половину и висеть секунд 40. Потом догрузиться.

Причем ситуация спонтанная. Возможно это просто совпадение.

Demimurych
() автор топика
Ответ на: комментарий от lvi

> А сетевой интерфейс один на сервере?, на большие пинги отвечает, 2000 например?

Сетевых интерфейсов два.

Один смотрит во внешний мир. Второй соединен гигабитным каналом со втором сервером.

ping -s 2000 server Да на пинги отвечает. Потерь 9% время 60 ms

Demimurych
() автор топика
Ответ на: комментарий от mky

Наверное, это tcp_syncookies. Вобще, много syn-пакетов идёт на сервер?


простите,
каким образом я могу это проконтролировать?

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

Запустить tcpdump, допустим с такими флагами (если надо интерфейс изменить):

tcpdump -c 10000 -n -nn -i eth0 'tcp[13] & 2 == 2' -s 500 -w /tmp/dumpfile

Потом почитать это файл (tcpdump -r /tmp/dumpfile).

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

> Запустить tcpdump, допустим с такими флагами (если надо интерфейс изменить):

еще раз простите. Получил файл в котором 10000 строк.

что с ним делать дальше?

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

Далее нужно просто посчитать, сколько syn-пакетов в секунду.

tcpdump -n -nn -r /tmp/dumpfile | cut -d . -f 1 | uniq -c

Если в секунду пакетов много (тысячи), то это, скорее всего, DoS, если немного, то вобще чёрная магия.

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

от 15 до 50

Часть вывода
28 12:08:40
13 12:08:41
19 12:08:42
17 12:08:43
34 12:08:44
21 12:08:45
33 12:08:46
48 12:08:47
25 12:08:48
26 12:08:49
44 12:08:50
48 12:08:51
28 12:08:52
22 12:08:53

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

ИМХО, пакетов не много. Не знаю, почему может неправильно срабатывать tcp_syncookies.

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