Можно ли использовать iptables для контроля тайм-аутов TCP / сбросов в масштабах всей системы?

Я пытаюсь определить, является ли соединение приложения с базой данных внутренним для приложения или из-за сетевого события. Это похоже на то, что сетевой фильтр будет иметь общесистемную видимость. С этой целью я хотел использовать -j LOG с iptables для регистрации всех сбросов TCP и тайм-аутов, которые происходят в системе. Однако я не знаю, что использовать для соответствия критериям.

Я чувствую, что в conntrack то момент ответ будет включать в conntrack модуль conntrack но я смог найти рядом с ним ничего. Сервер базы данных – это MS-SQL, а приложение J2EE работает на виртуальной машине RHEL 5.10. Последний – это машина, с которой я пытаюсь выполнить регистрацию.

РЕДАКТИРОВАТЬ:

Я нашел это сообщение в блоге, в котором показано, как протоколировать сброс TCP (среди прочего) с опцией --tcp-flags для iptables . Таким образом, проблема заключается в том, чтобы выяснить, как протоколировать соединения без явного RST, но закрыты из-за того, что соединение рассматривается как устаревшее / тайм-аут.

После некоторого запроса IRC, кажется, что общее ожидание состоит в том, что если один узел считает, что соединение по какой-либо причине прекратилось ненормально (включая достижение тайм-аута с внутренней точки зрения), ожидается, что он отправит удаленный узел пакет RST до закрытия соединения на своем боковая сторона. Таким образом, на оба вопроса возникает ответ на одно и то же решение: log TCP сбрасывается с помощью --tcp-flags .

Основная команда для этого в моей системе RHEL 5.10 (также должна работать на дистрибутивах на базе Debian):

 root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -m tcp -p tcp --tcp-flags RST RST -j LOG root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -m tcp -p tcp --tcp-flags FIN FIN -j LOG 

Без подходящих критериев я, вероятно, в конечном итоге сопоставил бы довольно много пакетов, поэтому я создал новое правило, специально предназначенное для системы, которую я буду делать:

 root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -d xxx.xxx.64.248/32 -m tcp -p tcp --tcp-flags RST RST -j LOG root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -d xxx.xxx.64.248/32 -m tcp -p tcp --tcp-flags FIN FIN -j LOG root@xxxxxxvlt01 ~ $ iptables -nvL Chain INPUT (policy ACCEPT 767K packets, 108M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 448K packets, 68M bytes) pkts bytes target prot opt in out source destination 0 0 LOG tcp -- * * 0.0.0.0/0 xxx.xxx.64.248 tcp flags:0x04/0x04 LOG flags 0 level 4 0 0 LOG tcp -- * * 0.0.0.0/0 xxx.xxx.64.248 tcp flags:0x01/0x01 LOG flags 0 level 4 root@xxxxxxvlt01 ~ $ 

Что намного лучше. Поскольку мое подтверждение материала RST-time-timeout от кого-то из IRC, я оставлю это открытым / не отвеченным, если кто-то может доказать мне, что я ошибаюсь. Через неделю я приму свой ответ на этот вопрос, если не буду противоречить.