khmm12
-
Posts
3 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by khmm12
-
-
Дано:
1. KN-1011 3.9.5
2. Несколько политик доступа в интернет.
3. Несколько профилей DNS.
4. Вручную добавленная DNS запись (ip host).
При переносе устройства из системной политики доступа на созданную руками наблюдается следующее:
1. Отваливается транзит DNS запросов для всех профилей DNS. Любые обращения к любым DNS-серверам уходят на DNS сервер Keenetic.
2. Запросы, которые должны идти сервер, указанный в созданном профиле DNS, резволвятся системным профилем. Если отключить транзит для созданного профиля, то запросы начинают ходить правильно.
Как воспроизвести.
Подготовка:
1. Создаем политику доступа в интернет.
2. Создаём профиль DNS, где указываем сервер (например локальный Dnsmasq/AdGuard Home), резволвящий mc.yandex.ru на 0.0.0.0. Транзит DNS запросов разрешён.
3. Добавляем DNS запись `ip host google.me 192.168.1.2`
Сценарий №1. Политика доступа системная. Профиль DNS системный (транзит включён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – актуальный адрес, запрос ушёл на указанный сервер в настройках. ✅
1.3 `dig @8.8.8.8 google.me` – нет ответа, запрос ушёл на 8.8.8.8. ✅
1.4 `dig @8.8.8.8 mc.yandex.ru` – актуальный адрес, запрос ушёл на 8.8.8.8. ✅
1.5 `dig @8.8.8.8 google.com` – актуальный адрес, запрос ушёл на 8.8.8.8. ✅
Сценарий №2. Политика доступа системная. Профиль DNS созданный (транзит включён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – 0.0.0.0, запрос ушёл на созданный профиль. ✅
1.3 `dig @8.8.8.8 google.me` – нет ответа, запрос ушёл на 8.8.8.8. ✅
1.4 `dig @8.8.8.8 mc.yandex.ru` – актуальный адрес, запрос ушёл на 8.8.8.8. ✅
Сценарий №3. Политика доступа созданная. Профиль DNS системный (транзит включён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – актуальный адрес, запрос ушёл на системный профиль. ✅
1.3 `dig @8.8.8.8 google.me` – 192.168.1.2, перехвачен. ❌
1.4 `dig @8.8.8.8 mc.yandex.ru` – актуальный адрес, но перехвачен и ушёл на системный профиль. ❌
Сценарий №4. Политика доступа созданная. Профиль DNS созданный (транзит включён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – актуальный адрес, запрос ушёл на системный профиль. ❌
1.3 `dig @8.8.8.8 google.me` – 192.168.1.2, перехвачен. ❌
1.4 `dig @8.8.8.8 mc.yandex.ru` – актуальный адрес, но перехвачен и ушёл на системный профиль. ❌
Сценарий №5. Политика доступа созданная. Профиль DNS созданный (транзит отключён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – 0.0.0.0, запрос ушёл на созданный профиль. ✅
1.3 `dig @8.8.8.8 google.me` – 192.168.1.2, перехвачен ✅
1.4 `dig @8.8.8.8 mc.yandex.ru` – 0.0.0.0, перехвачен и ушёл на созданный профиль. ✅
-
1
-
-
Наткнулся на аналогичную проблему.
Дано:
1. KN-1011 3.9.5
2. Несколько политик доступа в интернет.
3. Несколько профилей DNS.
4. Вручную добавленная DNS запись (ip host).
При переносе устройства из системной политики доступа на созданную руками, наблюдается следующее:
1. Отваливается транзит DNS запросов для всех профилей DNS. Любые обращения к любым DNS-серверам уходят на DNS сервер Keenetic.
2. Запросы, которые должны идти сервер, указанный в созданном профиле DNS, резволвятся системным профилем. Если отключить транзит для созданного профиля, то запросы начинают ходить правильно.
Как воспроизвести.
Подготовка:
1. Создаем политику доступа в интернет.
2. Создаём профиль DNS, где указываем сервер (например локальный Dnsmasq/AdGuard Home), резволвящий mc.yandex.ru на 0.0.0.0. Транзит DNS запросов разрешён.
3. Добавляем DNS запись `ip host google.me 192.168.1.2`
Сценарий №1. Политика доступа системная. Профиль DNS системный (транзит включён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – актуальный адрес, запрос ушёл на указанный сервер в настройках. ✅
1.3 `dig @8.8.8.8 google.me` – нет ответа, запрос ушёл на 8.8.8.8. ✅
1.4 `dig @8.8.8.8 mc.yandex.ru` – актуальный адрес, запрос ушёл на 8.8.8.8. ✅
1.5 `dig @8.8.8.8 google.com` – актуальный адрес, запрос ушёл на 8.8.8.8. ✅
Сценарий №2. Политика доступа системная. Профиль DNS созданный (транзит включён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – 0.0.0.0, запрос ушёл на созданный профиль. ✅
1.3 `dig @8.8.8.8 google.me` – нет ответа, запрос ушёл на 8.8.8.8. ✅
1.4 `dig @8.8.8.8 mc.yandex.ru` – актуальный адрес, запрос ушёл на 8.8.8.8. ✅
Сценарий №3. Политика доступа созданная. Профиль DNS системный (транзит включён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – актуальный адрес, запрос ушёл на системный профиль. ✅
1.3 `dig @8.8.8.8 google.me` – 192.168.1.2, перехвачен. ❌
1.4 `dig @8.8.8.8 mc.yandex.ru` – актуальный адрес, но перехвачен и ушёл на системный профиль. ❌
Сценарий №4. Политика доступа созданная. Профиль DNS созданный (транзит включён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – актуальный адрес, запрос ушёл на системный профиль. ❌
1.3 `dig @8.8.8.8 google.me` – 192.168.1.2, перехвачен. ❌
1.4 `dig @8.8.8.8 mc.yandex.ru` – актуальный адрес, но перехвачен и ушёл на системный профиль. ❌
Сценарий №5. Политика доступа созданная. Профиль DNS созданный (транзит отключён).
1. Проверяем:
1.1 `dig @192.168.1.1 google.me` – 192.168.1.2. ✅
1.2 `dig @192.168.1.1 mc.yandex.ru` – 0.0.0.0, запрос ушёл на созданный профиль. ✅
1.3 `dig @8.8.8.8 google.me` – 192.168.1.2, перехвачен ✅
1.4 `dig @8.8.8.8 mc.yandex.ru` – 0.0.0.0, перехвачен и ушёл на созданный профиль. ✅
-
1
-
3.9.x Сломан транзит DNS запросов при использовании профилей доступа в интернет
in Тестирование Dev-сборок
Posted
Если ограничение (limitation) / особенности не описаны в документации, то значит – сломано.
Сценарий №4 говорит о другом. Что для созданной политики доступа системный профиль перехватывает запросы до тех пор, пока назначенный профиль допускает транзит.