Не хватает диапазона ip_local_port_range

Dimka, это не все правила. Лучше сразу смотреть вывод iptables-save, потому что есть еще nat и тд.

iptables-save

---------- Добавлено 08.03.2016 в 10:45 ----------

fail2ban стоит недавно, и до него бывали проблемы. Поставил, т.к. надоели многомегабайтные логи подбора доступа.

Dimka, если nat не задействован, непонятно откуда взялся модуль. Ну значит попробуйте тогда по одному выгрузить последовательно модули, от которых зависит conntrack : получается, nf_nat, iptable_nat, а уже потом nf_conntrack_ipv4.

И убрать их из того места где они загружались.

Большое спасибо за ответы и советы.

1. ничего важного не теряю без этих модулей?

2. может ли вообще отвалиться сеть при попытке их выгрузки?

Dimka, вряд ли.

Хочу сделать это во время минимального наплыва посетителей. А чем лучше тестить? Чем создавать нагрузку? Мне кажется, что ab не потянет.

Может быть проблема больше из-за того, что много уникальных IP коннектится к сайту (до 35-40К IP в минуту)? Или это не имеет значения, кто создает 40к коннектов в минуту: несколько IP или много?

Забыл спросить.

После уменьшения таймаутов net.ipv4.netfilter.ip_conntrack_tcp_timeout_***** при выводе стат с ip_conntrack и было очень много с [UNREPLIED]:

2416 ESTABLISHED [UNREPLIED]

53289 SYN_SENT [UNREPLIED]

Это нормально?

Dimka, да это нормально и логично. conntrack "забывает" даже быстрее чем реально соединение закрывается.

Раз правил нет - надо отключать.

Так у вас всё-таки кто-то инициирует столько исходящих соединений?

По топику, вроде как, сошлись на том, что дело не в нехватке эфемерных портов, а тут пачка SYN_SENT откуда-то.

Если conntrack дропнул запись раньше реального закрытия соединения, и сервер отправляет в ответ на входящее соединение SYN/ACK или ACK, оно будет либо INVALID (если tcp_loose=0), либо сразу же ESTABLISHED (если tcp_loose=1).

FIN или RST слёту уходящие, тоже будут INVALID.

У вас nginx сам всё же ходит так интенсивно на бэкэнд, или что-то другое? Если он, попробуйте ходить по HTTP 1.1 и держать пул keepalive, чтобы на каждый проксируемый запрос не создавать по соединению.

nf_nat - получилось отключить, iptable_nat - не дает.

---------- Добавлено 11.03.2016 в 17:38 ----------

Все запросы (почти) статика, без бакэнда.

---------- Добавлено 11.03.2016 в 17:54 ----------

netwind, как мне кажется, очень верно указал причину - модуль conntrack.

При уменьшении в sysctl net.ipv4.netfilter.ip_conntrack_tcp_timeout****** стало легче.

Было net.netfilter.nf_conntrack_count = 312231, сейчас до 40.000