2019-06-03 Настороженно Относиться К Необкатанным Решениям
Постановка задачи: Нужно было добавить LOG-правило в iptables для логирования определенного трафика.
Как сделали: Чтобы защитить логи от флуда - было решено использовать лимит, наиболее гибко под задачу можно было настроить hashlimit. Так и сделали:
iptables -A reductor_forward -p tcp -m hashlimit --hashlimit-upto 10/min --hashlimit-mode srcip,dstip --hashlimit-name service1_log --hashlimit-htable-expire 120000 -m set --match-set service1_dst dst,dst -j LOG --log-prefix "Service1: "
В чем была проблема: Есть простое и «обкатанное в продакшене» правило limit, опыта поведения правила hashlimit у нас не было. Нарушили много правил, таких как «не усложняй» и «не используй не обкатанные технологии». Но подвоха ни кто не ждал, тем более что модуль hashlimit идет в стандартной поставке.
После изменений и отладки цепочки в iptables на большом трафике, заподозрили, что пакеты где-то теряются. Добавили правила-счетчики, увидели:
22 3571 all -- * * 0.0.0.0/0 10.90.1.23 453 35254 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: up to 10/min burst 5 mode srcip-dstip htable-expire 120000 match-set service1_dst dst,dst LOG flags 0 level 4 prefix 'Service1: ' 0 0 all -- * * 0.0.0.0/0 10.90.1.23
Т.е. из-за правила log дропались пакеты в форварде!
Как нужно было сделать: нужно было использовать простое правило limit.
~~OWNERAPPROVE~~
Прочитал правила разработки 2019-06-03 настороженно относиться к необкатанным решениям |
Обсуждение
Не совсем корректно звучит, -j LOG точно не дропает пакеты.
В hashlimit есть код, который выставляет *par→hotdrop = 1, скорее всего это оно. Довольно интересно в том плане, что можно дропать пакеты в match-правиле, я думал вердикты выставляются только в target'ах. По iptables -m hashlimit –help не ясно, можно ли это поведение выключать.
…