uhf

Могу предположить, что фича давно готова в глазах менеджмента и в отчетах, остались лишь "мелкие баги". Обычные разработчики вряд ли захотят или смогут их переубедить, они лишь будут избегать задач, связанных с этим роутингом. Потому что знают, что быстро и легко починить его нельзя. Руководитель разработки должен взять на себя ответственность и признать, что текущее решение неподходящее, требует рефакторинга и выделения ресурсов. А у него такого желания тоже, скорее всего, нет. Поддержка держит оборону, очень сложно им доказать непостоянные ошибки, которые не воспроизводятся на стенде. Везде тупик. Чтобы не быть голословным, я поковырял прошивку. Как и ожидалось, у фичи асинхронная архитектура, из-за которой все проблемы. За DNS роутинг отвечает отдельный поток. Он читает из локального сокета сообщения от DNS-прокси, в которых тот передает события "получен от клиента запрос", и "получен ответ от DNS". Чтение идет с задержкой до 100 мс. (отсюда пропуск первых запросов), нет информации какой именно ответ ушел клиенту (отсюда путаница с IP). Также этот поток отслеживает TTL доменов, сам запускает ресолв, чистку списков, ограничение их размера, и вообще вся реализация сложная (отсюда трудноуловимые баги). Сейчас хотелось бы понять, есть ли вообще вероятность, что возьмутся переделывать, или проще не тратить время на ожидание, и поискать другие решения.

На 5.1.0? Судя по release notes, эту "фичу" тогда добавили

Потестил 5.1.0. К сожалению, изменений не видно: роутер бомбит DNS двойными запросами, и далее сам обновляет по TTL. Это означает, что в роутинге самостоятельный ресолвер, отдельный от mDNS, и живущий своей жизнью. При таком подходе нормальной работы роутинга по доменам не будет. Нужна интеграция с mDNS, в список маршрутов должен добавляться только тот IP, который mDNS отдал клиенту, и никакой другой. Не нужно ничего на роутере обновлять по TTL, это клиент должен решать. Отдали клиенту IP - добавили в ipset, бессрочно. Это единственный рабочий вариант.

Поставил логирующий DNS единственным, и обнаружилось странное. Во-первых, при получении запроса от клиента, роутер отправляет в DNS сразу два запроса одновременно. Если DNS вернет для них разные IP - вот и не работает маршрутизация. Во-вторых, роутер потом периодически продолжает слать запрос этого домена в DNS, хотя его вроде бы не просили. Не вижу причин так делать. Это еще хуже, когда маршрутизация не работает, а спустя время магическим образом начинает работать.

"- Доктор, я когда вот так вот делаю, у меня вот тут болит. - А вы так не делайте. Следующий!" 😃 Я настроил отдельный DNS профиль для клиента, указал ему свой DNS-прокси с логированием. Делаю ресолв www.youtube.com с клиента. mDNS переслал запрос на мой DNS, тот дальше, ответ проброшен до клиента, в нем один IP, тот который в моем логе. Но. В object-group fqdn добавлен другой IP, не тот, которым ответил мой DNS. Предположим, mDNS проксирует запрос на все DNS (их всего было три), а потом в список берет айпи из любого ответа, который ему понравится. Сомнительно, но ок. Оставляю только один DNS 77.88.8.8. Делаю ресолв с клиента. Сравниваю полученный клиентом IP с IP в object-group fqdn. Первая попытка - IP одинаковые. Вторая попытка - IP разные. Как это возможно!? Я не понимаю, как это работает. Перед каждой попыткой, естественно, перезагружаю роутер. UPD: OPKG нет

Вроде бы одну проблему локализовал. У меня настроены два DNS - провайдера, и яндексовский (77.88.8.8). Я с клиента делаю ресолв www.youtube.com. DNS провайдера возвращает пусто, а DNS яндекса - запись с IP. Клиент получает IP, тут все нормально. Но при этом IP не сохраняется в fqdn object-group, соответственно, маршрутизации по домену нет: Если оставить только яндексовский DNS, а провайдерский запретить, то тогда IP сохраняется в fqdn object-group, как и ожидается: <!-- show object-group fqdn --> <group> <group-name>domain-list0</group-name> <enabled>yes</enabled> <ipv4-addresses-count>1</ipv4-addresses-count> <ipv6-addresses-count>1</ipv6-addresses-count> <fqdn-count>2</fqdn-count> <entry> <fqdn>www.youtube.com</fqdn> <type>runtime</type> <deadline4>284</deadline4> <deadline6>275</deadline6> <fail-counter4>0</fail-counter4> <fail-counter6>0</fail-counter6> <last-external>19</last-external> <last-list-changed>19</last-list-changed> <parent>youtube.com</parent> <ipv4> <address>142.251.1.198</address> <ttl>291</ttl> <last-updated>19</last-updated> </ipv4> <ipv6> <address>2a00:1450:4010:c02::c6</address> <ttl>278</ttl> <last-updated>19</last-updated> </ipv6> </entry> <entry> <fqdn>youtube.com</fqdn> <type>config</type> <deadline4>2147483</deadline4> <deadline6>2147483</deadline6> <fail-counter4>0</fail-counter4> <fail-counter6>0</fail-counter6> <last-external>70</last-external> <last-list-changed>70</last-list-changed> <ipv4/> <ipv6/> </entry> <excluded-ipv4/> <excluded-ipv6/> <excluded-fqdns/> <fqdn-count-runtime>1</fqdn-count-runtime> </group> Правда, клиенту почему-то в это время доходит другой IP ping www.youtube.com Pinging wide-youtube.l.google.com [173.194.220.198] with 32 bytes of data: Reply from 173.194.220.198: bytes=32 time=89ms TTL=105 Reply from 173.194.220.198: bytes=32 time=89ms TTL=105 Может быть mDNS делает несколько запросов подряд, тут я не разбирался. Но суть в том, что пустые ответы DNS ломают логику. Совсем от провайдерского DNS отказываться не хотелось бы, там у них внутренние домены.

Так что в итоге делать-то по проблеме, описанной ТС? 5.0.11, 5.1 Beta 1 - все так же присутствует. Создан один список с одним доменом youtube.com Для этого списка создано одно правило маршрутизации в впн. В итоге, при трассировке с клиента: youtube.com - маршрутизация работает m.youtube.com - маршрутизация работает www.youtube.com - маршрутизация НЕ работает Ощущение что криво парсится DNS ответ и игнорируются CNAME. Вот что внутрях <entry> <fqdn>www.youtube.com</fqdn> <type>runtime</type> <deadline4>1749</deadline4> <deadline6>1822</deadline6> <fail-counter4>0</fail-counter4> <fail-counter6>0</fail-counter6> <last-external>103</last-external> <last-list-changed>103</last-list-changed> <parent>youtube.com</parent> <ipv4/> <ipv6/> </entry> DNS ставил гугловский - не помогает.

Простите, я не понял, это баг или фича, что на странице диагностики трассировка не использует маршрутизацию по домену? Просто у меня с клиента трассировать нет возможности. Сегодня потратил время, думал, DNS маршрутизация вообще не работает, а её оказывается не видно так.