3.9.x Сломан транзит DNS запросов при использовании профилей доступа в интернет

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

 

 

 

 

[r13]

Он не сломан, как мне сказали это так и задумано.

Настройка транзита относится только к политике по умолчанию.

Для созданных политик запросы перехватываются всегда.

[khmm12]

17 минут назад, r13 сказал:

Он не сломан, как мне сказали это так и задумано.

 

Если ограничение (limitation) / особенности не описаны в документации, то значит – сломано. 

18 минут назад, r13 сказал:

Для созданных политик запросы перехватываются всегда.

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