2019-06-03 Настороженно Относиться К Необкатанным Решениям

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

--- правила_разработки:как_не_надо_делать:2019-06-03_настороженно_относиться_к_необкатанным_решениям [03.06.2019 11:34]
nikolay_carbonsoft1 Approved(nikolay_carbonsoft1 2019/06/03 11:34)
+++ правила_разработки:как_не_надо_делать:2019-06-03_настороженно_относиться_к_необкатанным_решениям [03.06.2019 11:54] (текущий)
nikolay_carbonsoft1 Approved(nikolay_carbonsoft1 2019/06/03 11:54)
@@ Строка 1: / Строка 1: @@
+**Постановка задачи:** Нужно было добавить LOG-правило в iptables для логирования определенного трафика.
+**Как сделали:** Чтобы защитить логи от флуда - было решено использовать лимит, наиболее гибко под задачу можно было настроить hashlimit. Так и сделали:
+<code bash>
+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: "
+</code>
+**В чем была проблема:** Есть простое и "обкатанное в продакшене" правило limit, опыта поведения правила hashlimit у нас не было. Нарушили много правил, таких как "не усложняй" и "не используй не обкатанные технологии". Но подвоха ни кто не ждал, тем более что модуль hashlimit идет в стандартной поставке.
+После изменений и отладки цепочки в iptables на большом трафике, заподозрили, что пакеты где-то теряются. Добавили правила-счетчики, увидели:
+<code bash>
+3571 all -- * * 0.0.0.0/0 10.90.1.23
+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 all -- * * 0.0.0.0/0 10.90.1.23
+</code>
+Т.е. из-за правила log дропались пакеты в форварде!
+**Как нужно было сделать:** нужно было использовать простое правило limit.
 ~~OWNERAPPROVE~~ /*Не удаляйте эту строку и ниже!*/

2019-06-03 Настороженно Относиться К Необкатанным Решениям

Различия