Andrew Dolgov

да, за это еще раз спасибо, ваш пост спас положение у меня было включено автообновление, проблема вылезла в понедельник утром (как обычно, угу). какая версия была до этого я не помню уже, но думаю что предыдущий пойнт-релиз. а есть рсс фид для ченжлогов? ред: 172.17.172.254.log.4.gz:Oct 26 13:24:39 172.17.172.254 ndm: Dns::Manager: enabled rebind protection. т.е. включено-то оно было давно. но при этом никаких проблем с резолвом не было. сейчас посмотрел, роутер ребутался 2 недели назад. :shrug:

почему тогда сломалось только сейчас? это не аргумент. Juniper SRX поставляется с дефолтной конфигурацией работающей для типового бранча из коробки без настроек вообще. можно ничего не настраивать, просто воткнуть пипку от провайдера в один порт, и локалочников в другие. при этом он почему-то не пытается быть самым умным и молча подменять транзитный трафик на ложное сообщение REFUSED, который сервер на самом не отправлял. я не против вашего желания защитить хомячков от атак, которые 99.999% из них никогда не затронут. просто постарайтесь ломать свои стабильные прошивки немного аккуратнее, и документировать изменения получше. сегодня фальшивый REFUSED, завтра фальшивый HTTP 401. как это вообще предполагается отлаживать, обвешивать кинетики с двух сторон тцпдампом? я пока так и не понял где мне узнать про эту опцию, кроме как спросив на форуме. поддержка мне до сих пор не ответила. для придания легкой остроте ситуации давайте предположим что в данный момент 16384 пользователей локалки не могут получить доступ к KDC, со всеми вытекающими последствиями.

кстати, я сейчас пролистал ченжлоги всех версий от 3.6.12 до 3.6.1 включительно, и там нет никаких упоминаний защиты от dns rebinding вообще, я уж молчу про изменения её работы по умолчанию (которые явно произошли, т.к. до недавнего времени резолв работал нормально и жалоб от пользователей не было) и то как ее отключить.

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

keenetic viva, 3.6.12. столкнулся с ситуацией, что рабочие станции в сети не могут отрезолвить KDC (и еще много что), похоже что ввиду навязчивой заботы разработчиков KeeneticOS, которые в одностороннем порядке запретили мне держать в днс записи, ведущие на зарезервированные диапазоны айпи адресов: Nov 22 12:12:37 172.17.172.254 ndnproxy: possible DNS-rebind attack detected: "kdc.example.org." IN A "172.17.172.12" (client 172.17.172.1) naboo:~:$ host -v kdc.example.org 172.17.172.254 Trying "kdc.example.org" Using domain server: Name: 172.17.172.254 Address: 172.17.172.254#53 Aliases: Host kdc.example.org not found: 5(REFUSED) Received 34 bytes from 172.17.172.254#53 in 518 ms аналогично и с прямым запросом на днс сервер, отвечающий за зону: naboo:~:$ host kdc.example.org luke.ns.cloudflare.com Using domain server: Name: luke.ns.cloudflare.com Address: 2803:f800:50::6ca2:c1c8#53 Aliases: Host kdc.example.org not found: 5(REFUSED) зона живет на клаудфларе, домен принадлежит мне. резолв идет через запущенный в entware dnsmasq+stubby (DoT). интересно, по мнению разработчиков, какое должно быть решение этой проблемы? - не держать сервера в локалке? - выдать каждому серверу белый IP? - иметь отдельный днс сервер в локалке с отдельным поддоменом для неё? - заменить кинетик на роутер, который не пытается быть умнее Папы Римского? - что-то ещё? второй вопрос: opkg dns-override в теории должен отключить встроенный днс форвардер кинетика и освободить 53ий порт для днс сервера в opkg/entware. почему при этом описанная выше фильтрация не отключается? я зарепортил вышеописанную ситуацию через https://help.keenetic.com/ (тикет 566790).

Столкнулся с аналогичной проблемой после той же инструкции. Помогло следующее: 1. Отключил fastnat, 2. на сервере опенвпн вписал topology subnet чтоб роутилось через .1 а не через какой-то странный не пингующийся pointtopoint адрес. До конца проблему с не всегда срабатывающими скриптами к сожалению это не решает, надо ковырять дальше, но по крайней мере странные зависания описанные вами выше пропадают. Дополнение: скопировал скрипт который в fs.d еще в ifipchanged.d и поменял проверку первого параметра на hook, не знаю правда насколько это поможет. fs.d и правда не особо правильное для него место.