Назад | Перейти на главную страницу

Количество подключений netstat и ip_conntrack различается на порядок. Зачем?

в / proc / net / ip_conntrack у меня есть:

established 3076
time_wait 4346
total 7468

и в netstat у меня есть:

established 1051
time_wait 73
total 1165

Это почему? Где другие связи? Как понять, что они делают?

Обновить: Еще немного статистики по ip_conntrack

assured 5230
unreplied 2133
total 7427

Conntrack модуль запоминает недавние соединения в течение X секунд до их окончательного истечения. В моем понимании это связано с тем, что в iptables есть несколько других модулей, которые могут использовать эту информацию: например, если вы хотите заблокировать какой-либо IP-адрес, если он устанавливает X новых подключений в течение определенного периода времени.

netstat, с другой стороны, показывает информацию в реальном времени и не интересуется древней историей.

Вы увеличили максимальное количество записей в таблице conntrack? Что делает последнее ядро

sysctl net.ipv4.netfilter.ip_conntrack_max

... или с каким-то старым ядром,

sysctl net.ipv4.ip_conntrack_max

вернуться к вам? Вы можете постоянно повышать это значение с помощью /etc/sysctl.conf или временно (до следующей перезагрузки) через sysctl -w net.ipv4.ip_conntrack_max

Мы наткнулись на этот случай, когда использовались контейнеры (докеры).

Не уверен, поможет ли это в вашем случае или нет, но похоже netstat -nat в ОС хоста будут отображаться только соединения, предназначенные для сетевого стека хоста, тогда как conntrack -L покажет информацию как для хоста, так и для всех его контейнеров.

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

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

Из-за этого, если вы уже если перед вами брандмауэр с отслеживанием состояния, вы можете полностью отказаться от отслеживания соединений на обратном прокси-сервере (или, возможно, с одной его стороны).

Отказаться от всего этого будет примерно так:

# iptables -L -t raw
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
NOTRACK    tcp  --  anywhere             anywhere            tcp dpt:www 
NOTRACK    tcp  --  anywhere             anywhere            tcp spt:www 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
NOTRACK    tcp  --  anywhere             anywhere            tcp spt:www 
NOTRACK    tcp  --  anywhere             anywhere            tcp dpt:www

В вашем случае вы можете не отслеживать петлю -i lo:

$ iptables -t raw -A PREROUTING -i lo -j NOTRACK
$ iptables -t raw -A OUTPUT -o lo -j NOTRACK