>> Во-первых не весь фаерволл, а только один порт и только для одного
>> клиента. Во-вторых у меня уже есть готовая комбинация port-knocking-а, открывающая порт
>> только на 20 секунд максимум раз в час. К тому же
>> в этой комбинации при попытке стучаться на соседние порты клиент банится
>> на этот самый час, поэтому сканер портов скорее приведёт к временному
>> бану, а не наоборот.
> Охотно верю. Но возникают следующие вопросы:
> 1. Оправдано ли такое усложнение в конкретном случае?

Ну есть готовая связки - копипасти сколько угодно. Кому как удобнее.

> 2. Не логичнее ли такой сложный функционал реализовать внешними средствами?

Не логичнее. В фаерволле всё делается элементарно, быстро и элегантно, и работает в полном kernel space.

Тем более внешние средства НИКАК не помогут, если допустил косяк в правилах фаерволла, про что мы собственно и упоминали. Разве что сброс фаерволла по кронтабу :)

>> при настройке шейпера приходилось всё это разделять (особенно когда используется прозрачный
>> прокси, задача неприятным образом усложняется). Это мелочь конечно, но, как говорится,
>> "с миру по нитке".
> А зачем шейпить файерволлом прозрачный прокси, если в том же squid есть
> delay pools, которые справляются с этой задачей не в пример лучше
> и гибче?

Я что-то не понял, а остальной трафик (который идёт в обход прокси) вы предлагаете не шейпить? Я ж подчеркнул, что прокси прозрачный. Как раз частью усложнения было отделить трафик прокси, трафика пользователей с проксёй, трафик пользователей с интернетом в обход прокси, трафик прокси в интернет. В iptables же всё это находится в разных цепочках, поэтому ничего разделять и не надо, т.к. уже всё зарание разделено. Собственно именно из-за этого усложнения в iptables он кажется таким монструозным, AFAIK.

И что там с ipset, не нашёлся? :)