Фильтрация определенных сетевых пакетов

Что такое «типа keeap alive»? Если это keep alive, то хотя бы протокол укажите, а лучше признаки, оличающие эти конкретные пакеты от прочих.

С помощью iptables можно сделать очень много чего, но некторые вещи потребуют написания модуля ядра/iptables.

Если оно укладывается в понятия u32 в iptables, то можно и без программирования обойтись.

Хотя блокировка таких пакетов выглядит странно...

Да, пакеты именно «keep alive». Это те пакеты, которые отправляются для проверки состояния канала. Рубить пакеты «keep alive» мне необходимо для того, чтобы «убедить» TCP закрыть данное соединение ввиду того, что якобы удаленный хост не отвечает на запросы «keep alive». А все это вытекает из проблемы, которая хорошо описана вот тут: http://wesmorgan.blogspot.com/2011/03/tcp-zero-windows-and-why-they-can-be.html Вот так и у меня: серверное приложение, которое обслуживает сокет – подвисло, что привело к переполнению исходящего буфера на стороне клиента и он отослал «TCP Window Full». Приложение на стороне сервера выходить из ступора, когда оно уже в него вошло – не собирается, соответственно пакеты «ZeroWindowProbe» могут ходить вечно, ведь сам канал жив, а очередь на входе никогда не будет обработана и буфер не освободится. Само приложение не умеет обрабатывать такую ситуацию. Выходит, что все висит и полечить можно только рестартом приложения. Но, приложение умеет отрабатывать ситуацию при разрыве соединения. Если соединение разорвано, приложение его переустанавливает и тем самым начинает снова нормально работать. К сожалению, изменить что-то на уровне ПО нет возможности, поэтому, стоит задача, при возникновении ситуации с «ZeroWindowProbe» - обрывать соединение. Причем, сделать это необходимо не через скрипты, а нативными средствами OS Linux. Вот и было предложение: при наступлении ситуации с «ZeroWindowProbe», на стороне клиента или сервера блокировать «keep alive» пакеты которые отвечают за поддержание канала в состоянии ESTABLISHED при данной ситуации. Если эти пакеты доходить до одной из сторон не будут – соединение будет разорвано, ПО его переустановит и работа возобновится, конечно, до следующего повисания )))

бррр. Набор слов по которым понять смысл крайне трудно.

серверное приложение, которое обслуживает сокет – подвисло, что привело к переполнению исходящего буфера на стороне клиента и он отослал «TCP Window Full».

Я верю, что сервер не читающий данные заставит tcp передать клиенту «tcp window full», но не наоборот.

Соединение можно оборвать через REJECT --reject-with tcp-reset, а в комбинации с recent возможно дасться реализовать нужный функционал.

пакеты от tcp-keepalive ничем особым ( кроме 0-й длины данных ) не отличаются от других, так что тупо резать такие пакеты iptables-ом опасно.

IMHO проще всего на стороне клиента ходить через tcp-прокси с определенным таймаутом.

Спасибо большое за ответ. А можно ли сыграть на интенсивности прохождения пакетов через сокет. Ведь, при нормальной работе проходит около 200 тысяч пакетов в секунду, а при проблеме - всего два пакета в минуту?

Я верю, что сервер не читающий данные заставит tcp передать клиенту «tcp window full», но не наоборот.

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

нет. Если не места в буфере передачи, то передающий процесс усыпляется до появления этого места или возникновения ошибки.

Это приемная сторона говорит, что хорош слать, у меня тут никто ранные не забирает (в виде win=0 и неподтверждения нового сегмента) в ответ на попытку передачи клиента.

Перед тем, как передающий процесс усыпляется, он отсылает «tcp window full». А сервер потом отправляет первую zero-window пробу. Мы оба правы. Все зависит от того, какой из процессов считается передающим. В данном случае, сервер отсылает клиенту окно - мол давай шли, а у клиента уже нет места в буфере чтобы слать. Согласно RFC1122 (http://tools.ietf.org/html/rfc1122#page-92), «The transmitting host SHOULD send the first zero-window» - так и происходит в моей случае.

IMHO проще всего на стороне клиента ходить через tcp-прокси с определенным таймаутом.

Сделали этим способом. Однако, ввиду все той же проблемы с переполнением буфера, сессия клиента теперь постоянно висит в состоянии FIN_WAIT1. Опция tcp_orphan_retries = 1 не помогает - висит уже час. Если посмотреть статистику сокетов : cat /proc/net/sockstat, у меня как раз один зависший сокет. Это и есть FIN_WAIT1. У меня вопрос: чем чревата установка переменной net.ipv4.tcp_max_orphans в 0 ?

Дык прокся обычно работает с сокетом в неблокирующем режиме и она в любой момент может сказать shutdown(socket,SHUT_RDWR) & close(socket). SO_LINGER с нулевым таймаутом вроде должно закрывать сразу.

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

net.ipv4.tcp_max_orphans в 0 ? не знаю чем это может помочь.

Не проще ли на серверной стороне ресетить соединение ?

Мы сделали таким образом: socat -ls -T60 TCP-LISTEN:13668,fork TCP:xx.xx.xx.xx:3668,sndtimeo=15,rcvtimeo=15 Может посоветуете другое ПО или подход в общем?

net.ipv4.tcp_max_orphans в 0 ? не знаю чем это может помочь.

Она должна вообще исключить наличие соединений в состоянии FIN_WAIT1

У тебя оно на close() ждет или процесс завершается а в системе остается бесхозный сокет в FIN_WAIT1 ?

IMHO готовое решение может и отсутствовать. Готовых исходников навалом. Можно что-нибудь подправить.

процесс завершается а в системе остается бесхозный сокет в FIN_WAIT1 ?

Да, совершенно верно

Касательно исходников, можете что-то посоветовать от себя для RedHat&

что-то типа simple-tcp-proxy.c или tcproxy в гугле

подправить на предмет таймаутов.

А чем мешает этот бесхозный сокет ? Он же не должен мешать установить новое соединение ?

Есть свое ограничение на количество портов на стороне клиента для соединения с сервером - они их занимать будут. Спасибо!