boco

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

мой пойнт в том, что затраты на переключение контекста даже несколько раз в секунду (тем более, что контекст все равно переключается для валидных пакетов, коих, очевидно, значительно больше) - ничто по сравнению с пробеганием каждого пакета по коннтраку. если же вас сознательно дрочат, то тут и фаер не спасет - банально засрут пакетами бандвис, это для атакующих стоит примерно ничего. гораздо эффективнее в таком случае дропать пакеты до рекурсера, например на границе сети. лучше предложите топикстартеру правила без коннтрака, все полезнее чем стращать переключениями контекста для исчезающе малой доли невалидных пакетиков =) ps. для прикола посчитал, сколько раз отработал tcp wrappers для ssh за вчера на одном из наших рекурсеров - получилось 1 раз в 10 минут. и вот ради этого включать фаервол? [:facepalm:]

да, речь именно про это. про диапазон портов - зачем же себя ограничивать? так можно и не вписаться. и главное - все это извращение весь этот файнтюнинг только чтобы недайбох не сделать болт в юзерспейсе, это же пипец как накладно. =) вощем мне тоже надоело. =) я предложил простое, эффективное и главное проверенное практикой решение. настаивать не буду. мир дружба жевачка.

если не убрать политику дроп на инпут, рекурсер без коннтрака не получит ответ от авторитетного сервера

ну то есть политику дроп на инпут убрать и файнтюнить правила? уже не так лаконично получается. в принципе, рабочее решение, если сеть ничто больше не слушает и не будет слушать.

да, здесь вы правы. в линухе не тормозит. можете показать, как должны выглядеть правила в этом случае?

я думаю эти mpps'ы у вас софтроутер гоняет слева направо. tcp wrappers тут ортогонально. более того, именно в таких софтроутерах с целью минимизации числа правил фаервола (для ускорения пересылки пакетов слева направо) рекомендуется прикрывать tcp wrappers'ами и собственными acl слушающие сеть сервисы.

1 mpps к рекурсеру?! если это не шутка, поделитесь как и чем вы это перевариваете? а то у меня есть твердая уверенность, что скалировать dnsdist до 1 mpps не получится

ну вы клаудфлэр-то с обычными гражданами не сравнивайте 😃 те, кто оперируют клаудфлеровскими пакетрейтами, на наге совета не спрашивают... а так да, можно и микроскопом гвоздь забить. я например не уверен, что прогон каждого пакета по табличке коннтрак на сервере с запущеным рекурсером (это важно, потому что удп) будет быстрее, чем раз в пару минут акцептнуть соединение и послать нахер в юзерспейсе

я хз как тут цитировать нормально, после какого-то обновления форума перестала вообще работать тема nag classic. поетому отвечу без цитат. 1. без понятия, надо в исходники конкретного рекурсера смотреть. это важно? 2. как изменить? я вот вижу что в предложенном конфиге без коннтрака рекурсер не получит ответов на свои запросы. 3. в чем принципиальная разница закрыть ssh фаерволом или tcp wrappers? я не понимаю, поясните.

нет. я предполагаю, что кроме зябликс-агента, рекурсера и sshd никто сеть не слушает. в чем вред?

за счет чего? и насколько затратнее? топикстартеру я бы вообще рекомендовал отключить фаервол: зябликс и рекурсер имеют свои acl, а ssh прикрывается в hosts.allow. зато не надо каждый пакет через фаер прогонять и не наступишь на граблю с размером коннтрак.

не надо фаервола, используйте acl самого резолвера

ну так это будет работать тока если бинлог хранит все транзакции с момента создания бд. что, в общем случае, не так. я все пытаюсь намекнуть, что слейв ни в какую базу не лезет, а лезет тока в бинлог. и что поэтому, а не по какой-то другой причине нужен дамп бд разумной давности (для которого еще не протух бинлог).

то есть: 1. закидываем в бд данные 2. включаем gtid 3. включаем бинлог 4. настраиваем второй сервер, запускаем на нем slave 5. данные из бд автомагически перетекают на slave я правильно понял? вы сами так делали?