khmm12

Если ограничение (limitation) / особенности не описаны в документации, то значит – сломано. Сценарий №4 говорит о другом. Что для созданной политики доступа системный профиль перехватывает запросы до тех пор, пока назначенный профиль допускает транзит.

Дано: 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. 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, перехвачен и ушёл на созданный профиль. ✅