Перейти к содержанию

Вопрос

Опубликовано (изменено)

Настроены несколько WG тунелей, созданы политики, к каждой политике свои клиенты. Такая схема работала уже пару лет, недавно обновился на 4.2 Beta 3, т.к. нужны некоторые функции беты.

Раньше: домены резолвились четко через ДНС, указанный в конфиге WG, через утилиты проверки на утечку ДНС был четко один айпи адрес выходной от WG (так настроено на сервере WG)

Сейчас: Проверка на утечку ДНС показывается все ДНС резолверы от всех WG тунелей и даже ДНС от провайдера.

Перечитал лог апдейта, не нашел ничего похожего, чтобы так могло сломаться.

Почему всё сломалось само на ровном месте?

Баг прошивки или я упустил что-то в обновлениях?

 

Изменено пользователем Veltik

Рекомендуемые сообщения

  • 0
Опубликовано

Ну и получается я теперь не могу для Connection Policy выставить нужный ДНС, только для отдельных Клиентов или Сегмента сети. Каждому клиенту получается надо свою конфигурацию ДНС создавать и присваиваить. Двойная работа, хоть и более гибко стало.

 

Но! Смог создать только 8 профилей ДНС тут internet-filter/dns-configuration

Как создать больше?

  • 0
Опубликовано (изменено)

Всё равно мутно всё как-то. Недостаточно создать профили ДНС с нужными ДНС серверами, надо их еще продублировать в Системном профиле, чтобы всё работало. Ну и больше 8-ми профилей не добавишь.

Как с минимальными усилиями сделать как раньше? Каждый клиент идет на ДНС, который указан в соединении в его политике.

Изменено пользователем Veltik
  • 0
Опубликовано (изменено)

Вообщем, явно что-то сломали.

Сейчас можно добиться отсутствия утечки ДНС, но надо создавать отделный профиль ДНС, в нем указывать айпи ДНС сервера в локалке и этот же айпи указывать в Системном профиле для нужного интерфейс. Тогда утечка пропадает. Если в системном убрать айпи днс, оставить только в конкретном профиле, то утечка появляется.

Куда можно отрепортить проблему? Сюда? https://forum.keenetic.ru/forum/52-dev-channel-issues-test-reports/

Изменено пользователем Veltik
  • 0
Опубликовано

Ох, это сложно, рабочую систему придется даунгрейдить, боюсь чтобы ничего не отвалилось и работу останавливать не вариант. Других вариантов нет?

  • 0
Опубликовано

У меня есть второй такой же роутер, попробую воссоздать на нем аналогичную ситуацию, сделать дамп на 4.1.7 прошивке и потом на 4.2 бета 3.

  • 0
Опубликовано (изменено)
В 11.09.2024 в 14:55, Le ecureuil сказал:

А можете прислать сюда self-testы на старом ПО, где все работает, и на новом? Хочу сравнить, что же поменялось.

 

Загружаю два файла.

 

Первый - 4.1.7 стабильная, утечки ДНС нет, второй файл - сразу после обновления на 4.2 Бета 3 - утечка есть.

 

Сделал даунгрейд до 4.1.7 - утечка пропала.

 

Утечка выражается в том, что на версии 4.1.7 резолв идет ТОЛЬКО через WG, а в 4.2 Бета 3 еще и через 1.1.1.1 1.0.0.1

self-test_KN-1811_stable_4.01.C.7.0-1_router_2024-09-12T14-21-35.035Z.txt self-test_KN-1811_preview_4.02.B.3.0-0_router_2024-09-12T14-27-22.667Z.txt

Изменено пользователем Veltik
  • 0
Опубликовано
9 минут назад, Le ecureuil сказал:

Какие у вас DNS настроены и используются на клиенте? Покажите скриншот.

> cat /etc/resolv.conf

# Generated by NetworkManager
nameserver 192.168.1.1

 

В обоих случаях.

  • 0
Опубликовано

На клиентах ничего не менялось, клиентов много и разных, винда, линух, мобильники, все одинаково на новой версии прошивки утекают в днс. Клиенты здесь не причем.

  • 0
Опубликовано

Если кратко: раньше политика перехватывала вообще все DNS-запросы, направленные не только на 192.168.1.1 в роутер, но транзитные на 1.1.1.1 или к DNS-провайдера. Теперь перехватываются только запросы непосредственно в роутер, на 192.168.1.1. Если ваши клиенты из локалки отправляют прямые транзитные запросы к DNS провайдера, то теперь они будут пропущены. Потому прошу еще раз проверить, куда же на самом деле идут запросы - можете сделать это через захват в Wireshark на клиенте.

  • 0
Опубликовано (изменено)
54 минуты назад, Le ecureuil сказал:

Если кратко: раньше политика перехватывала вообще все DNS-запросы, направленные не только на 192.168.1.1 в роутер, но транзитные на 1.1.1.1 или к DNS-провайдера. Теперь перехватываются только запросы непосредственно в роутер, на 192.168.1.1. Если ваши клиенты из локалки отправляют прямые транзитные запросы к DNS провайдера, то теперь они будут пропущены. Потому прошу еще раз проверить, куда же на самом деле идут запросы - можете сделать это через захват в Wireshark на клиенте.

Почему так решили сделать? Т.е. настройка в профилях Транзит запросов утратила силу? Совсем транзитные ловить нельзя? Или же вы имеете в виду, что описанное вами поведение справедливо как раз тогда, когда стоит галка Транзит запросов, а когда снята, всё перехватывается и перенаправляется, как и прежде?

Изменено пользователем keenet07
  • 0
Опубликовано
1 час назад, Le ecureuil сказал:

Если кратко: раньше политика перехватывала вообще все DNS-запросы, направленные не только на 192.168.1.1 в роутер, но транзитные на 1.1.1.1 или к DNS-провайдера. Теперь перехватываются только запросы непосредственно в роутер, на 192.168.1.1. Если ваши клиенты из локалки отправляют прямые транзитные запросы к DNS провайдера, то теперь они будут пропущены. Потому прошу еще раз проверить, куда же на самом деле идут запросы - можете сделать это через захват в Wireshark на клиенте.

Попробую сделать, хоть и не вижу смысла. Явно беда в механизме обработки ДНС в прошивке роутера, клиенты знают только айпи роутера, ни о каких других ДНС они не знают, тем более не могу знать о ДНС других WG сетей, но почему-то знают. Т.е. роутер палит все ДНС, которые находятся в политике ДНС Системная и не важно к какому интерфейсу привязан ДНС, все ДНС уходят на все интерфейсы.

  • 0
Опубликовано
4 часа назад, keenet07 сказал:

Почему так решили сделать? Т.е. настройка в профилях Транзит запросов утратила силу? Совсем транзитные ловить нельзя? Или же вы имеете в виду, что описанное вами поведение справедливо как раз тогда, когда стоит галка Транзит запросов, а когда снята, всё перехватывается и перенаправляется, как и прежде?

Это все работает только в системном профиле, не в политиках. В политиках всегда были свои прибамбасы.

  • 0
Опубликовано
2 часа назад, Veltik сказал:

Попробую сделать, хоть и не вижу смысла. Явно беда в механизме обработки ДНС в прошивке роутера, клиенты знают только айпи роутера, ни о каких других ДНС они не знают, тем более не могу знать о ДНС других WG сетей, но почему-то знают. Т.е. роутер палит все ДНС, которые находятся в политике ДНС Системная и не важно к какому интерфейсу привязан ДНС, все ДНС уходят на все интерфейсы.

Покажите же тогда дамп, причем желательно снятый компонентом монитор на Home интерфейсе роутера в момент теста по определению утечки.

  • 0
Опубликовано
13 часа назад, Le ecureuil сказал:

Покажите же тогда дамп, причем желательно снятый компонентом монитор на Home интерфейсе роутера в момент теста по определению утечки.

Подскажите команды, которые надо ввести через телнет на роутере.

  • 0
Опубликовано
13 минуты назад, Veltik сказал:

Подскажите команды, которые надо ввести через телнет на роутере.

Все делается через веб-интерфейс. Нужно установить компонент monitor и сделать захват на странице "Диагностика".

  • 0
Опубликовано
1 минуту назад, Le ecureuil сказал:

Все делается через веб-интерфейс. Нужно установить компонент monitor и сделать захват на странице "Диагностика".

NetFlow Monitor? У меня почему-то не появилась кнопка захвата на странице Диагностики.

  • 0
Опубликовано
1 час назад, Le ecureuil сказал:

Все делается через веб-интерфейс. Нужно установить компонент monitor и сделать захват на странице "Диагностика".

Прикрепил захват с 3х интерфейсов на всякий случай. И 3 скрина с результатом теста.

Screenshot_20240913_110248.png

Screenshot_20240913_110237.png

Screenshot_20240913_110216.png

capture-GigabitEthernet0-Vlan1-Sep 13 14-01-12.pcapng capture-Bridge0-Sep 13 14-01-14.pcapng capture-Bridge1-Sep 13 14-01-17.pcapng

  • 0
Опубликовано
3 часа назад, Le ecureuil сказал:

Спасибо за приложенную информацию, баг обнаружен и поправлен.

Будет в следующей версии 4.2.

Спасибо, отлично.

 

А можно хоть капельку информации где был баг? Интересно для саморазвития.

  • 0
Опубликовано
18 часов назад, Veltik сказал:

Спасибо, отлично.

 

А можно хоть капельку информации где был баг? Интересно для саморазвития.

В netfilter в правилах перехвата DNS добавлялся адрес 192.168.1.1/24 из-за опечатки, а не 192.168.1.1/32. Как оказалось, такой формат задания подсети вызывает проблемы.

  • 0
Опубликовано

Купил этот роутер только из-за WG и такое. как по мне это очень критично для меня, утечка днс. как это можно в данный момент исправить? если не ждать 4.2

  • 0
Опубликовано
22 hours ago, michaelkim said:

Купил этот роутер только из-за WG и такое. как по мне это очень критично для меня, утечка днс. как это можно в данный момент исправить? если не ждать 4.2

4.2 вышла, можете установить и пользоваться.

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.