LINUX.ORG.RU
Форум — Admin  

Пропадает сеть

 , ,


2

2

Временами бывает что сервер(Debian 9.4) недоступен по сети, не знаю то ли у провайдера (сапорт пока молчит), то ли на сервере проблемы.

Симптомы
* Zabbix(на этом же сервере) показывает падение трафика почти до 0
* PPS тоже 0
* Пинг с другого сервера FAIL
* Нагрузка на проц падает
* netstat -na | grep SYN_RECV | wc -l = 502
* dropped\missed\fifo по нулям (network-top)
* В syslog пусто

Единственная аномалия это возросшие записи conntrack c ~7000 до 441 389 записей с флагом SYN_SENT UNREPLIED. Но переполнения таблицы не регистрируется.
/etc/sysctl.conf

net.core.somaxconn = 65535
net.core.netdev_max_backlog = 10000
net.core.netdev_budget = 600
net.netfilter.nf_conntrack_max=1048576
net.netfilter.nf_conntrack_tcp_loose = 0
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syncookies = 1
net.netfilter.nf_conntrack_tcp_timeout_established = 7200


Что может быть? Похоже на syn flood, но в syslog пусто и нагрузки на проц нет

★★★★
← Astra linix 1.6
А как ускорить поиск в примонтированной SMB шаре? →

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

в syslog пусто и дропов нет

gobot ★★★★
() автор топика

Если я правильно понимаю, то «SYN_SENT UNREPLIED» - это попытка установить соединение со стороны сервера.

Если есть возможность, то потыкай его с машины в той же сети. «Пинг с другого сервера FAIL» - это оно?

Вообще похоже, что помирает сетевуха или зависает коммутатор, к которому сервер подключен. Ставлю на второе.

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

SYN_SENT UNREPLIED

Значение SYN_SENT говорит о том, что через данное соединение проследовал единственный пакет TCP SYN

Здесь же видно ключевое слово [UNREPLIED], которое сообщает о том, что ответного трафика через это соединение еще не было

http://www.opennet.ru/docs/RUS/iptables/#THECONNTRACKENTRIES

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

Если бы тебя досили, то было бы SYN_RECV.

SYN_SENT - это твой сервер послал SYN, а ему пока не ответили.

собери информацию «netstat -atnp» в момент когда отваливаются соседи ( лучше всего через arping ) и резко увеличивается «conntrack -С».

А оно само восстанавливается или кто-то что-то делает ?

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

SYN_SENT - это твой сервер послал SYN, а ему пока не ответили

А понял, получается это мой сервер шлет SYN. Остается вопрос, зачем это он делает

собери информацию «netstat -atnp» в момент когда отваливаются соседи

Это информация есть. Но что там смотреть? Там всего 1921 записей, почти как при нормальной работе.

когда отваливаются соседи ( лучше всего через arping )

Какие соседи? Я проверяю доступность канала через ping и собираю статистику(tcpdump, conntrack, netstat etc...) когда потерянных пакетов > 0

А оно само восстанавливается или кто-то что-то делает ?

Восстанавливается само, примерно через 30 сек., потом через 5 минут снова и т.д. Получаются такие волны-скачки трафика на графике

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

Вот примерно такие запросы поступают в момент сбоя, IP Бразилия
tcpdump -n -r tcpdump.pcap host 177.20.229.36

14:02:22.047015 IP 177.20.229.36.39138 > myserver:443: Flags [S], seq 1844776455, win 14600, options [mss 1460,sackOK,TS val 41149198 ecr 0,nop,wscale 5], length 0
14:02:22.779441 IP 177.20.229.36.39143 > myserver:443: Flags [S], seq 3366942756, win 14600, options [mss 1460,sackOK,TS val 41149270 ecr 0,nop,wscale 5], length 0
14:02:24.198069 IP 177.20.229.36.39157 > myserver:443: Flags [S], seq 4040873696, win 14600, options [mss 1460,sackOK,TS val 41149413 ecr 0,nop,wscale 5], length 0
14:02:24.761126 IP 177.20.229.36.39164 > myserver:443: Flags [S], seq 3526023513, win 14600, options [mss 1460,sackOK,TS val 41149470 ecr 0,nop,wscale 5], length 0
14:02:25.665427 IP 177.20.229.36.39175 > myserver:443: Flags [S], seq 2256191787, win 14600, options [mss 1460,sackOK,TS val 41149561 ecr 0,nop,wscale 5], length 0


Получается 1 раз в сек. на сервер шлет SYN

Или вот, Сингапур
tcpdump -n -r tcpdump.pcap host 111.223.75.181
14:02:21.842121 IP 111.223.75.181.13886 > myserver:443: Flags [S], seq 3150106902, win 5840, options [mss 1460,sackOK,TS val 131546792 ecr 0,nop,wscale 1], length 0
14:02:21.989360 IP 111.223.75.181.13942 > myserver:443: Flags [S], seq 2514185408, win 5840, options [mss 1460,sackOK,TS val 131546804 ecr 0,nop,wscale 1], length 0
14:02:21.989547 IP myserver:443 > 111.223.75.181.13942: Flags [S.], seq 1346753742, ack 2514185409, win 43440, options [mss 1460,sackOK,TS val 1152929937 ecr 131546804,nop,wscale 11], length 0
14:02:22.187738 IP 111.223.75.181.14032 > myserver:443: Flags [S], seq 4094003038, win 5840, options [mss 1460,sackOK,TS val 131546824 ecr 0,nop,wscale 1], length 0
14:02:22.187935 IP myserver:443 > 111.223.75.181.14032: Flags [S.], seq 187094566, ack 4094003039, win 43440, options [mss 1460,sackOK,TS val 1152930001 ecr 131546824,nop,wscale 11], length 0
14:02:22.306224 IP 111.223.75.181.13942 > myserver:443: Flags [.], ack 1, win 2920, options [nop,nop,TS val 131546836 ecr 1152929937], length 0
14:02:22.322549 IP 111.223.75.181.14086 > myserver:443: Flags [S], seq 272280700, win 5840, options [mss 1460,sackOK,TS val 131546837 ecr 0,nop,wscale 1], length 0
14:02:22.324522 IP 111.223.75.181.13942 > myserver:443: Flags [P.], seq 1:2, ack 1, win 2920, options [nop,nop,TS val 131546838 ecr 1152929937], length 1
14:02:22.445722 IP 111.223.75.181.12347 > myserver:443: Flags [F.], seq 34472750, ack 481170492, win 2920, options [nop,nop,TS val 131546850 ecr 1152929105], length 0
14:02:22.502254 IP 111.223.75.181.14032 > myserver:443: Flags [.], ack 1, win 2920, options [nop,nop,TS val 131546855 ecr 1152930001], length 0
14:02:22.542347 IP 111.223.75.181.14216 > myserver:443: Flags [S], seq 2346575509, win 5840, options [mss 1460,sackOK,TS val 131546859 ecr 0,nop,wscale 1], length 0
14:02:22.545902 IP 111.223.75.181.14219 > myserver:443: Flags [S], seq 2646393580, win 5840, options [mss 1460,sackOK,TS val 131546860 ecr 0,nop,wscale 1], length 0
14:02:22.587462 IP 111.223.75.181.14232 > myserver:443: Flags [S], seq 1678541490, win 5840, options [mss 1460,sackOK,TS val 131546864 ecr 0,nop,wscale 1], length 0
14:02:22.812461 IP 111.223.75.181.14032 > myserver:443: Flags [P.], seq 1:5, ack 1, win 2920, options [nop,nop,TS val 131546886 ecr 1152930001], length 4
14:02:22.812467 IP 111.223.75.181.14032 > myserver:443: Flags [F.], seq 5, ack 1, win 2920, options [nop,nop,TS val 131546886 ecr 1152930001], length 0
14:02:22.812472 IP myserver:443 > 111.223.75.181.14032: Flags [R], seq 187094567, win 0, length 0
14:02:22.838053 IP myserver:443 > 111.223.75.181.9911: Flags [F.], seq 3100479665, ack 2635499017, win 22, options [nop,nop,TS val 1152930166 ecr 131546364], length 0
14:02:22.937356 IP 111.223.75.181.14437 > myserver:443: Flags [S], seq 674914887, win 5840, options [mss 1460,sackOK,TS val 131546900 ecr 0,nop,wscale 1], length 0
14:02:22.939502 IP 111.223.75.181.13942 > myserver:443: Flags [FP.], seq 2:5, ack 1, win 2920, options [nop,nop,TS val 131546900 ecr 1152929937], length 3
14:02:23.074996 IP 111.223.75.181.14482 > myserver:443: Flags [S], seq 436679417, win 5840, options [mss 1460,sackOK,TS val 131546913 ecr 0,nop,wscale 1], length 0
14:02:23.150662 IP 111.223.75.181.9911 > myserver:443: Flags [.], ack 1, win 2920, options [nop,nop,TS val 131546920 ecr 1152930166], length 0
14:02:23.338987 IP 111.223.75.181.13942 > myserver:443: Flags [FP.], seq 1:5, ack 1, win 2920, options [nop,nop,TS val 131546940 ecr 1152929937], length 4
14:02:23.386150 IP myserver:443 > 111.223.75.181.13942: Flags [.], ack 6, win 21, options [nop,nop,TS val 1152930303 ecr 131546940], length 0
14:02:23.621755 IP 111.223.75.181.14784 > myserver:443: Flags [S], seq 1139951888, win 5840, options [mss 1460,sackOK,TS val 131546969 ecr 0,nop,wscale 1], length 0
14:02:23.676121 IP 111.223.75.181.14825 > myserver:443: Flags [S], seq 992581158, win 5840, options [mss 1460,sackOK,TS val 131546974 ecr 0,nop,wscale 1], length 0
14:02:24.785621 IP 111.223.75.181.15364 > myserver:443: Flags [S], seq 2343859015, win 5840, options [mss 1460,sackOK,TS val 131547084 ecr 0,nop,wscale 1], length 0
14:02:24.852570 IP 111.223.75.181.15393 > myserver:443: Flags [S], seq 2797909678, win 5840, options [mss 1460,sackOK,TS val 131547090 ecr 0,nop,wscale 1], length 0
14:02:24.947417 IP 111.223.75.181.15451 > myserver:443: Flags [S], seq 294173306, win 5840, options [mss 1460,sackOK,TS val 131547099 ecr 0,nop,wscale 1], length 0
14:02:25.225868 IP 111.223.75.181.15576 > myserver:443: Flags [S], seq 2446164435, win 5840, options [mss 1460,sackOK,TS val 131547127 ecr 0,nop,wscale 1], length 0
14:02:25.301620 IP 111.223.75.181.15608 > myserver:443: Flags [S], seq 2562315855, win 5840, options [mss 1460,sackOK,TS val 131547135 ecr 0,nop,wscale 1], length 0
14:02:25.301829 IP myserver:443 > 111.223.75.181.15608: Flags [S.], seq 4156905409, ack 2562315856, win 43440, options [mss 1460,sackOK,TS val 1152930769 ecr 131547135,nop,wscale 11], length 0
14:02:25.530708 IP 111.223.75.181.15702 > myserver:443: Flags [S], seq 3241908014, win 5840, options [mss 1460,sackOK,TS val 131547158 ecr 0,nop,wscale 1], length 0
14:02:25.659410 IP 111.223.75.181.15608 > myserver:443: Flags [R], seq 2562315856, win 0, length 0
14:02:25.730991 IP 111.223.75.181.15841 > myserver:443: Flags [S], seq 3837423990, win 5840, options [mss 1460,sackOK,TS val 131547178 ecr 0,nop,wscale 1], length 0
14:02:25.736915 IP 111.223.75.181.15849 > myserver:443: Flags [S], seq 303456269, win 5840, options [mss 1460,sackOK,TS val 131547179 ecr 0,nop,wscale 1], length 0
14:02:25.946089 IP 111.223.75.181.15929 > myserver:443: Flags [S], seq 3727107489, win 5840, options [mss 1460,sackOK,TS val 131547199 ecr 0,nop,wscale 1], length 0


Тут тоже SYN шлет, но почаще

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

А понял, получается это мой сервер шлет SYN. Остается вопрос, зачем это он делает

Криво настроенный прокси, использование уязвимостнй, взлом.

Единственная аномалия это возросшие записи conntrack c ~7000 до 441389

Вот как conntrack превысит хотя бы 30-40к тогда и смотри.

Интерес представляет и «netstat -atnp» и «conntrack -L»

Соседи - это соседние хосты в твоей ip-сети. Самый подходящий пример - шлюз по умолчанию. Пинги дропаются в первую очередь, а вот arp-запросы фильтруют и дропают крайне редко.

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

Криво настроенный прокси, использование уязвимостнй, взлом.

прокси нет. Уязвимости в чем, стеке TCP, приложении? Взлом вряд ли...

Вот как conntrack превысит хотя бы 30-40к тогда и смотри

Так он и так превысил, 441 389 больше чем 30-40к

Интерес представляет и «netstat -atnp»

Так он есть. Что там смотреть? 

cat netstat.log | wc -l
1921
cat netstat.log | grep SYN_RECV | wc -l
500
cat netstat.log | grep TIME_WAIT | wc -l
315
cat netstat.log | grep ESTABLISHED | wc -l
537


conntrack -L

conntrack: command not found
Но это же аналогично
cat /proc/net/nf_conntrack | wc -l
?

Про соседей не понял, что там смотреть? ARP таблицу? Шлюз пинговать?

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

правильно ли я понимаю, что если SYN_SENT, то это значит сервер инициализировал конект к другому хосту и послал SYN пакет? Если да, то таких пакетов не было

Фильтрую только SYN от myserver
tcpdump -n -r tcpdump.pcap "tcp[tcpflags] & (tcp-syn) != 0" and "tcp[tcpflags] & (tcp-ack) = 0" and src myserver and host not myserver2
ничего не найдено
#myserver2 - это тоже мой сервер, на который  myserver может делать сам конект


Т.е. сам сервер не посылал SYN. SYN-ACK да, но SYN не было. Почему так? Фильтр tcpdump верный

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

cat /proc/net/nf_conntrack | wc -l

В старых ядрах «cat /proc/net/nf_conntrack» эквивалент «conntrack -L». С 4.9 /proc/net/nf_conntrack ликвидировали

Единственная аномалия это возросшие записи conntrack c ~7000 до 441 389 записей с флагом SYN_SENT UNREPLIED

А твой сервер роутером не работает? SYN прошедший через роутер будет как раз давать «SYN_SENT UNREPLIED» в conntrack и в netstat будет тихо.

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

Кстати вот ещё что заметил в conntrack src стоит не ИП моего сервера, а удаленный, хотя флаг SYN_SENT. Как такое может быть?

ipv4     2 tcp      6 106 SYN_SENT src=122.176.65.143 dst=myserver sport=59036 dport=443 [UNREPLIED] src=myserver dst=122.176.65.143 sport=443 dport=59036 mark=0 zone=0 use=2


И подобных записей 99%
cat nf_conntrack.log |  wc -l
474921
cat nf_conntrack.log |  grep SYN_SENT | wc -l
441381


Ведь если SYN_SENT стоит, то в src должен быть IP моего сервера?

Сделал эксперимент, послал с сервера SYN пакет на несуществующий адрес
hping3 -p 7799 -s 9999 --count 1 --syn  245.55.55.55


потом смотрю 
cat /proc/net/nf_conntrack | grep 245.55.55.55
ipv4     2 tcp      6 115 SYN_SENT src=myserver dst=245.55.55.55 sport=9999 dport=7799 [UNREPLIED] src=245.55.55.55 dst=myserver sport=7799 dport=9999 mark=0 zone=0 use=2

Все верно, флаги SYN_SENT UNREPLIED и в src стоит мой сервер, а не удаленный

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

А твой сервер роутером не работает?

Хмм... как раз таки роутером и был.
Было
net.ipv4.ip_forward = 1
Изменил сейчас на
net.ipv4.ip_forward = 0

Может в этом дело было?

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

ipv4 2 tcp 6 106 SYN_SENT src=122.176.65.143 dst=myserver sport=59036 dport=443 [UNREPLIED] src=myserver dst=122.176.65.143 sport=443

Такая запись характерна для пересылки пакета, а не приема пакета.

myserver точно твой адрес? «ip ro get myserver» говорит, что «local» ?

Сколько на машине сетевых интерфейсов кроме lo ?

У тебя в iptables/nat пусто?

443 порт на myserver слушается (sudo lsof -nP -iTCP@myserver:443 говорит, что LISTEN)?

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

Такая запись характерна для пересылки пакета, а не приема пакета.

А куда он пересылать долженен, сам себе?

myserver точно твой адрес? «ip ro get myserver» говорит, что «local» ?

Да


Сколько на машине сетевых интерфейсов кроме lo ?

Кроме ЛО ещё есть docker0. Кстати недавно установил

У тебя в iptables/nat пусто?

В самой цепочке NAT пусто, а так правила есть в iptables кое какие


443 порт на myserver слушается (sudo lsof -nP -iTCP@myserver:443 говорит, что LISTEN)?

Да, команда выводит список из 50 ESTABLISHED

Все же не понять, если есть какое либо переполнение в ядре или стеке сетевом, ну недостаточно каких то ресурсов, то в syslog это обязательно должно попадать? Или нужно гадать и методом тыка все проверять? А то получается как будто ищешь черную кошку в темной комнате

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

Все немного проще.

SYN_SENT для conntrack и netstat это немного разные события. Видимо к пятнице у меня совсем с головой стало плохо, чтоб я не вспомнил про наличие разницы.

Состояния conntrack:

  • SYN_SENT: SYN-only packet seen
  • SYN_RECV: SYN-ACK packet seen

conntrack не знает про адреса (локальный или нет) и на любой (входящий, исходящий) syn-пакет будет SYN_SENT.

А в netstat SYN_SENT будет только для исходящих.

В твоем случае к тебе приходит syn который тихо дропнут (какой-то счетчик наверняка это учитывает) по причине переполнения очереди (net.ipv4.tcp_max_syn_backlog).

О том, что он дропнут conntrack не узнает и состояние соединения останется SYN_SENT, в отличии от ситуации, когда этот пакет был дропнут в самом conntack.

Ты над настройкой SYNPROXY не задумывался? IMHO в твоем случае это уже становится необходимостью.

vel ★★★★★
()
Ответ на: комментарий от vel 
35637794 times the listen queue of a socket overflowed
35640975 SYNs to LISTEN sockets dropped


Т.е. при переполнении очереди SYN этот счетчик увеличивается? Если в очереди было > net.ipv4.tcp_max_syn_backlog SYN запросов?

Кстати сейчас даже когда conntrack ~400 000, то сеть перестала падать и в syslog появилось nf_conntrack: table full, dropping packet, хотя net.netfilter.nf_conntrack_max=1048576. Почему так?

Не знаю из-за чего. В sysctl я добавил

net.ipv4.ip_forward = 0
net.ipv4.tcp_synack_retries = 1

net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.enp4s0.accept_source_route = 0
net.ipv4.tcp_rfc1337 = 1

и ещё очистил iptables -F

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

Кстати сейчас даже когда conntrack ~400 000, то сеть перестала падать и в syslog появилось nf_conntrack: table full, dropping packet, хотя net.netfilter.nf_conntrack_max=1048576. Почему так?

машина всегда права! Если говорит full, значит full.

Не знаю из-за чего. В sysctl я добавил

Ну так прочитай чем правляют эти настройки.

С точки зрения борьбы с synflood они тебе почти ничем не помогут.

и ещё очистил iptables -F

а нафига ?

Недоступность по сети может быть в двух случаях: недостаток ресурсов (ограничения) и запрет (iptables)

Если есть фильтрация по состоянию соединения (-m state) и conntrack переполнен, то получаем невозможность новых соединения.

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

Если есть фильтрация по состоянию соединения (-m state) и conntrack переполнен, то получаем невозможность новых соединения.

Если он был переполнен, почему в сислог не было ничего? В сислог посыпались сообщения после сброса iptables. Какой же он нудный этот линупс!

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

Недоступность по сети может быть в двух случаях: недостаток ресурсов (ограничения) и запрет (iptables)

Как мне узнать в какой линуксовский счетчик я уперся, если в логах пусто было?

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

переполнение backlog-а происходит тихо.

дефолтный backlog 512, a contrack_max 1M

Тебе пачку syn сунули, сервис заткнулся, а больше и не нужно :)

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

переполнение backlog-а происходит тихо

Ахренеть, а как же понять что именно переполняется? Там этих счетчиков-ограничителей сотни

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

Там у каждого счетчика есть название, а в документации к ядру обычно есть описание.

Если погуглить темы про synflood, то там можно найти эту информацию.

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

Поставил 2 дебиана в 2 virtualbox и начал гонять SYN. SYN_SENT устанавливается когда через соединение(не важно в какую сторону) прошел 1 SYN, но не было SYN+ACK. После прохождения SYN+ACK устанавливается флаг SYN_RECV.

Провел эксперимент

10.0.0.2 - атакуемая машина
10.0.0.3 - вымышленный досер с которого идут SYN

Это в нормальном состоянии

hping3 --syn -p 80  10.0.0.2  --count 1
conntrack -E -p tcp
    [NEW] tcp      6 120 SYN_SENT src=10.0.0.3 dst=10.0.0.2 sport=2469 dport=80 [UNREPLIED] src=10.0.0.2 dst=10.0.0.3 sport=80 dport=2469
 [UPDATE] tcp      6 60 SYN_RECV src=10.0.0.3 dst=10.0.0.2 sport=2469 dport=80 src=10.0.0.2 dst=10.0.0.3 sport=80 dport=2469

Как видно SYN_SENT обновился до SYN_RECV
Потом делаю так, чтобы SYN+ACK пакет дропался на атакуемой машине
iptables  -A OUTPUT -d 10.0.0.3/32 -p tcp  -j DROP

и получаю только SYN_SENT 
hping3 --syn -p 80  10.0.0.2  --count 1
conntrack -E -p tcp
[NEW] tcp      6 120 SYN_SENT src=10.0.0.3 dst=10.0.0.2 sport=2891 dport=80 [UNREPLIED] src=10.0.0.2 dst=10.0.0.3 sport=80 dport=2891

SYN_SENT так и остался висеть

Тогда назревает другой вопрос, почему сервер не посылал SYN+ACK? Как ты говорил этот пакет мог дропнутся, но как понять что вызвало этот дроп? Переполнение чего, какой то очереди?

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

Удалось выцепить из tcpdump лог конкретного соединения

ipv4     2 tcp      6 114 SYN_SENT src=220.175.182.113 dst=myserver sport=37416 dport=443 [UNREPLIED] src=myserver dst=220.175.182.113 sport=443 dport=37416 mark=0 zone=0 use=2

tcpdump -n -r tcpdump.pcap port 37416 and host 220.175.182.113

00:00:37.529378 IP 220.175.182.113.37416 > myserver: Flags [S], seq 2248147994, win 14520, options [mss 1412,sackOK,TS val 592082560 ecr 0,nop,wscale 7], length 0
00:00:37.529675 IP myserver > 220.175.182.113.37416: Flags [S.], seq 3573150500, ack 2248147995, win 43440, options [mss 1460,sackOK,TS val 1140303839 ecr 592082560,nop,wscale 11], length 0
00:00:37.797558 IP 220.175.182.113.37416 > myserver: Flags [.], ack 1, win 114, options [nop,nop,TS val 592082828 ecr 1140303839], length 0
00:00:37.797804 IP 220.175.182.113.37416 > myserver: Flags [P.], seq 1:5, ack 1, win 114, options [nop,nop,TS val 592082828 ecr 1140303839], length 4
00:00:37.797839 IP myserver > 220.175.182.113.37416: Flags [.], ack 5, win 22, options [nop,nop,TS val 1140303906 ecr 592082828], length 0
00:00:37.797845 IP 220.175.182.113.37416 > myserver: Flags [F.], seq 5, ack 1, win 114, options [nop,nop,TS val 592082828 ecr 1140303839], length 0
00:00:37.838198 IP myserver > 220.175.182.113.37416: Flags [.], ack 6, win 22, options [nop,nop,TS val 1140303917 ecr 592082828], length 0

Как видно SYN+ACK был, но состояние почему то все равно SYN_SENT

ещё
ipv4     2 tcp      6 118 SYN_SENT src=50.63.13.254 dst=myserver sport=57991 dport=443 [UNREPLIED] src=myserver dst=50.63.13.254 sport=443 dport=57991 mark=0 zone=0 use=2

tcpdump -n -r tcpdump.pcap host 50.63.13.254
00:00:36.308187 IP 50.63.13.254.38415 > myserver.443: Flags [.], ack 3563600361, win 115, options [nop,nop,TS val 3574171771 ecr 1140303486], length 0
00:00:36.318210 IP myserver.443 > 50.63.13.254.54422: Flags [.], ack 2182165257, win 22, options [nop,nop,TS val 1140303537 ecr 3574171743], length 0
00:00:36.362048 IP 50.63.13.254.40968 > myserver.443: Flags [P.], seq 3029813984:3029813988, ack 1293330620, win 115, options [nop,nop,TS val 3574171834 ecr 1140300685], length 4
00:00:36.370877 IP 50.63.13.254.33503 > myserver.443: Flags [P.], seq 3881296825:3881296826, ack 3331889950, win 115, options [nop,nop,TS val 3574171835 ecr 1140289239], length 1
00:00:36.370922 IP myserver.443 > 50.63.13.254.33503: Flags [.], ack 1, win 21, options [nop,nop,TS val 1140303550 ecr 3574171835], length 0
00:00:36.372622 IP 50.63.13.254.44246 > myserver.443: Flags [S], seq 743622599, win 14600, options [mss 1460,sackOK,TS val 3574171835 ecr 0,nop,wscale 7], length 0
00:00:36.457132 IP 50.63.13.254.57991 > myserver.443: Flags [S], seq 1176745173, win 14600, options [mss 1460,sackOK,TS val 3574171922 ecr 0,nop,wscale 7], length 0
00:00:36.485158 IP 50.63.13.254.35594 > myserver.443: Flags [P.], seq 3249399266:3249399267, ack 3426429847, win 115, options [nop,nop,TS val 3574171948 ecr 1140296599], length 1
00:00:36.536751 IP 50.63.13.254.43824 > myserver.443: Flags [S], seq 3637653306, win 14600, options [mss 1460,sackOK,TS val 3574172007 ecr 0,nop,wscale 7], length 0
00:00:36.537155 IP myserver.443 > 50.63.13.254.43824: Flags [S.], seq 2965607175, ack 3637653307, win 43440, options [mss 1460,sackOK,TS val 1140303591 ecr 3574172007,nop,wscale 11], length 0
00:00:36.563958 IP 50.63.13.254.33503 > myserver.443: Flags [FP.], seq 1:4, ack 1, win 115, options [nop,nop,TS val 3574172028 ecr 1140303550], length 3
00:00:36.606204 IP myserver.443 > 50.63.13.254.33503: Flags [.], ack 5, win 21, options [nop,nop,TS val 1140303609 ecr 3574172028], length 0
00:00:36.634241 IP myserver.443 > 50.63.13.254.53070: Flags [S.], seq 2900089544, ack 2291918149, win 43440, options [mss 1460,sackOK,TS val 1140303616 ecr 3574168600,nop,wscale 11], length 0
00:00:36.634253 IP myserver.443 > 50.63.13.254.49010: Flags [S.], seq 4263040109, ack 583458044, win 43440, options [mss 1460,sackOK,TS val 1140303616 ecr 3574168833,nop,wscale 11], length 0
00:00:36.671103 IP 50.63.13.254.56687 > myserver.443: Flags [P.], seq 295311165:295311169, ack 2081598565, win 115, options [nop,nop,TS val 3574172143 ecr 1140300766], length 4
00:00:36.723965 IP 50.63.13.254.43824 > myserver.443: Flags [.], ack 1, win 115, options [nop,nop,TS val 3574172194 ecr 1140303591], length 0
00:00:36.724098 IP 50.63.13.254.43824 > myserver.443: Flags [P.], seq 1:5, ack 1, win 115, options [nop,nop,TS val 3574172194 ecr 1140303591], length 4
00:00:36.826606 IP 50.63.13.254.49010 > myserver.443: Flags [.], ack 1, win 115, options [nop,nop,TS val 3574172291 ecr 1140299803], length 0
00:00:36.871954 IP 50.63.13.254.43824 > myserver.443: Flags [F.], seq 5, ack 1, win 115, options [nop,nop,TS val 3574172342 ecr 1140303591], length 0
00:00:36.916004 IP 50.63.13.254.34328 > myserver.443: Flags [P.], seq 2445478925:2445478929, ack 1884409419, win 115, options [nop,nop,TS val 3574172388 ecr 1140298199], length 4
00:00:36.916040 IP myserver.443 > 50.63.13.254.34328: Flags [.], ack 4, win 22, options [nop,nop,TS val 1140303686 ecr 3574172388], length 0
00:00:36.984096 IP 50.63.13.254.37241 > myserver.443: Flags [S], seq 2560391429, win 14600, options [mss 1460,sackOK,TS val 3574172449 ecr 0,nop,wscale 7], length 0
00:00:37.101175 IP 50.63.13.254.34328 > myserver.443: Flags [F.], seq 4, ack 1, win 115, options [nop,nop,TS val 3574172573 ecr 1140303686], length 0
00:00:37.142198 IP myserver.443 > 50.63.13.254.34328: Flags [.], ack 5, win 22, options [nop,nop,TS val 1140303743 ecr 3574172573], length 0
00:00:37.351393 IP 50.63.13.254.47880 > myserver.443: Flags [P.], seq 1296873606:1296873610, ack 1435745394, win 115, options [nop,nop,TS val 3574172821 ecr 1140290071], length 4
00:00:37.367145 IP 50.63.13.254.48665 > myserver.443: Flags [S], seq 3028348907, win 14600, options [mss 1460,sackOK,TS val 3574172832 ecr 0,nop,wscale 7], length 0
00:00:37.399628 IP 50.63.13.254.53329 > myserver.443: Flags [S], seq 2402011460, win 14600, options [mss 1460,sackOK,TS val 3574172862 ecr 0,nop,wscale 7], length 0
00:00:37.461795 IP 50.63.13.254.43824 > myserver.443: Flags [P.], seq 1:5, ack 1, win 115, options [nop,nop,TS val 3574172932 ecr 1140303591], length 4
00:00:37.562205 IP myserver.443 > 50.63.13.254.43824: Flags [S.], seq 2965607175, ack 3637653307, win 43440, options [mss 1460,sackOK,TS val 1140303848 ecr 3574172932,nop,wscale 11], length 0
00:00:37.643429 IP 50.63.13.254.53095 > myserver.443: Flags [S], seq 662719225, win 14600, options [mss 1460,sackOK,TS val 3574173115 ecr 0,nop,wscale 7], length 0
00:00:37.670448 IP 50.63.13.254.37099 > myserver.443: Flags [P.], seq 706867502:706867506, ack 434669468, win 115, options [nop,nop,TS val 3574173140 ecr 1140290583], length 4
00:00:37.728890 IP 50.63.13.254.34307 > myserver.443: Flags [S], seq 97173990, win 14600, options [mss 1460,sackOK,TS val 3574173192 ecr 0,nop,wscale 7], length 0
00:00:37.729337 IP myserver.443 > 50.63.13.254.34307: Flags [S.], seq 4064796847, ack 97173991, win 43440, options [mss 1460,sackOK,TS val 1140303889 ecr 3574173192,nop,wscale 11], length 0
00:00:37.742778 IP 50.63.13.254.60475 > myserver.443: Flags [S], seq 2470078795, win 14600, options [mss 1460,sackOK,TS val 3574173206 ecr 0,nop,wscale 7], length 0
00:00:37.745976 IP myserver.443 > 50.63.13.254.41734: Flags [F.], seq 1962332736, ack 1579870579, win 21, options [nop,nop,TS val 1140303893 ecr 3574168215], length 0
00:00:37.749011 IP 50.63.13.254.43824 > myserver.443: Flags [.], ack 1, win 115, options [nop,nop,TS val 3574173219 ecr 1140303591], length 0
00:00:37.886769 IP 50.63.13.254.53753 > myserver.443: Flags [S], seq 4048367729, win 14600, options [mss 1460,sackOK,TS val 3574173358 ecr 0,nop,wscale 7], length 0
00:00:37.887221 IP myserver.443 > 50.63.13.254.53753: Flags [S.], seq 231733211, ack 4048367730, win 43440, options [mss 1460,sackOK,TS val 1140303929 ecr 3574173358,nop,wscale 11], length 0
00:00:37.896873 IP myserver.443 > 50.63.13.254.46685: Flags [F.], seq 772417627, ack 4110561192, win 22, options [nop,nop,TS val 1140303931 ecr 3574168374], length

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

А ты догадливый :)

Да, у каждого tcp-сокета который сделал listen() есть очередь (backlog). Размер его задается при вызове listen(). Но он не будет больше net.core.somaxconn

Кроме того, backlog для одного сокета не может быть больше net.ipv4.tcp_max_syn_backlog/4

Превышение любого из этих ограничений приводит к дропу и увеличению ListenDrops в /proc/net/netstat

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

Что смотреть, это «times the listen queue of a socket overflowed»?

netstat -s | grep -iE "LISTEN|drop" | grep -vi "ICMP"
    169290 outgoing packets dropped
    1232747 dropped because of missing route
    281 fragments dropped after timeout
    68 packets dropped from out-of-order queue because of socket buffer overrun
    35637794 times the listen queue of a socket overflowed
    36862918 SYNs to LISTEN sockets dropped
    TCPOFODrop: 329

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

обнулить - IMHO reboot-ом или хаком ядра.

ListenOverflows - это переполнение очередей сокетов.

ListenDrops - это индикатор слишком большого числа запросов на установление tcp-соединений.

ListenDrops включает в себя ListenOverflows

Точнее, второе ограничение (через sysctl_max_syn_backlog) выглядит так

если sysctl_max_syn_backlog - backlog_length(socket) < sysctl_max_syn_backlog/4 , то drop и увеличение ListenDrops

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

Спасибо, буду эксперементировать со счетчиками этими. Как я понял нужно сопоставлять счетчики переполнений netstat -s с параметрами ядра sysctl

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

В твоем случае это уже не нужно. У тебя есть synflood атака.

Просто увеличение размеров backlog тут не поможет.

Есть много статей на тему борьбы с synflood в условиях линукса. Рецепт один SYNPROXY.

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

Куки включены сейчас

net.ipv4.tcp_syncookies=1

Кстати я заметил почему был SYN_SENT, но не было SYN_RECV. Это происходит когда куки выключены и скорость\колличество SYN большая, то SYN_RECV не посылается. Если куки включены то SYN_RECV всегда отправляется, какой бы поток не был. Почему так и в какое ограничение упирается пока не понял )

И ещё заметил, что в логи «nf_conntrack: nf_conntrack: table full, dropping packet» попадает как то странно и не всегда. Например было nf_conntrack_max=65535, то при привышении писалось в логи, потом я установил nf_conntrack_max=1000000 и снова превысил
cat /proc/sys/net/netfilter/nf_conntrack_count
1000000

Как видно уперлось в ограничитель, но в syslog этого уже нет

И ещё заметил, что когда идет большой SYN флуд, то в дебиане полностью пропадает сеть на интерфейсе. Лечится только ifdown, ifup, В логах ничего. Мак адреса в arp все incomplete

gobot ★★★★
() автор топика
Последнее исправление: gobot (всего исправлений: 2)
Ответ на: комментарий от gobot

tcp_syncookies = 1

И что, помогло?! :)

У тебя задача чтобы synflood не попадал в conntrack!

flood попадающий в conntrack сжирает все ресурсы.

И ещё заметил, что когда идет большой SYN флуд, то в дебиане полностью пропадает сеть на интерфейсе. Лечится только ifdown, ifup, В логах ничего. Мак адреса в arp все incomplete

Ну так разберись в чем проблема. Это может быть как аппаратная проблема сетевой карты, так и настройки системы.

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

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

У тебя задача чтобы synflood не попадал в conntrack!

да, это я потом сделаю, читал https://www.opennet.ru/tips/info/2928.shtml

Я сейчас отключил вообще conntrack для теста.

Увеличивается 

66907 SYNs to LISTEN sockets dropped


Где смотреть какая в данный момент очередь «LISTEN sockets»? Сервер не отправляет SYN+ACK в ответ. Не удается подключится вообще к порту на который идет атака. Проц загружен ~5%
Увеличил уже все что можно
net.core.netdev_max_backlog = 100000
net.core.somaxconn = 6553500
net.ipv4.tcp_max_syn_backlog = 4096000


Что ещё увеличивать?

Ну так разберись в чем проблема

Да это не критично, может в виртуалке глюк какой

gobot ★★★★
() автор топика
Последнее исправление: gobot (всего исправлений: 1)
Ответ на: комментарий от vel

Вроде разобрался, у приложения есть ещё своя очередь при вызове listen(), как ты говорил выше ) В нее упирается, в частности nginx. Вопрос теперь другой, как эту очередь увеличить?

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

С этим разобрался, у nginx есть параметр backlog

listen backlog=16384


Все! Теперь сервер посылает SYN+ACK )

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

Протестил куки. Тормозят. 1 ядро грузит 30%(почему то). Неужели это хэш так вычисляется

gobot ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Astra linix 1.6
Admin
А как ускорить поиск в примонтированной SMB шаре? →