Маршрутизация по DNS - цепочка туннелей

evsasha · March 12

Версия OS: 5.0.7

Модель: Giga (KN-1011) EAEU

В примере ниже создан список AWG_3_test_1, на него настроена маршрутизация в для двух туннелей.

Если туннель Wireguard2 падает/выключен - трафик идёт через провайдера (auto). В туннель OpkgTun10 не попадает.

Можно поменять порядок туннелей - трафик будет идти всегда через первый. Во второй не попадает.

Вопрос может ли/должна ли работать маршрутизация по DNS с цепочкой из нескольких туннелей?

object-group fqdn AWG_3_test_1
    include ip.me
!
dns-proxy
    rebind-protect auto
    route object-group AWG_3_test_1 Wireguard2 auto # первый туннель у которого есть ссылка на список AWG_3_test_1
    route object-group AWG_3_test_1 OpkgTun10 auto  # второй туннель у которого есть ссылка на список AWG_3_test_1
    tls upstream 8.8.4.4 sni dns.google
    tls upstream 9.9.9.9 sni dns.quad9.net
    filter engine opkg
!

Edited March 12 by evsasha
исправлена опечатка

evsasha · March 18

Дополню контекс, вопрос касается вот этих изменений анонсированных в версии 5.0.1 и 5.0.4

Цитата

Реализована возможность настройки маршрутов через разные шлюзы или интерфейсы для одной и той же группы объектов FQDN с помощью интерфейса командной строки (dns-proxy route object-group). Приоритет маршрутов определяется порядком их ввода. [NDM-4118]

Цитата

Реализован новый вариант маршрутизации, основанный на объектных группах FQDN, позволяющий более точно и гибко управлять трафиком, направленным на определенные доменные имена. [NDM-3946]

dns-proxy route object-group {group} [{interface} | {gateway} [interface]] [auto] [reject] — установить назначение маршрутизации {interface} или {gateway} для доменных имен, перечисленных в группе объектов {group}.

Получается есть две опции auto и reject:

* Если указать auto - трафик в случае отключения первого туннеля пойдет через провайдера

* Если указать reject - трафик в случае отключения первого туннеля не пойдёт никуда

А как работает приоритет? Как сказать чтобы трафик шёл через второй туннель?

Edited March 18 by evsasha
Дополнил контекст вопроса примерами

hoaxisr · March 18

Заявленный функционал приоритета и fallback на второй интерфейс не работает при такой настройке:

~ # curl -s http://localhost:79/rci/show/rc/dns-proxy/route
[
{
"group": "test",
"interface": "Wireguard0",
"auto": true,
"index": "eec3073e15e4e77c29b3c17ddc66a41c",
"comment": ""
},
{
"group": "test",
"interface": "Wireguard1",
"auto": true,
"reject": true,
"index": "4e6a4fc5fab8b15b55fa4c2a7e3ddbb2",
"comment": ""
}
]~ #

При Wireguard0 down трафик идет в провайдера.

Никогда не идет в Wireguard1.

Не реагирует на ping-check, если повесить ping-check на интерфейс Wireguard0 и будет status: fail, то маршрутизация по DNS не реагирует на этот статус.

Проверялось на KN-1810 прошивки 5.x (все версии не работает), 5.01.A. (не работает ни на одной из версий).

Приоритет маршрутов определяется порядком их ввода -- заявлено, но не функционирует.

Denis P · March 18

3 часа назад, hoaxisr сказал:

Заявленный функционал приоритета и fallback на второй интерфейс не работает при такой настройке:

~ # curl -s http://localhost:79/rci/show/rc/dns-proxy/route
[
{
"group": "test",
"interface": "Wireguard0",
"auto": true,
"index": "eec3073e15e4e77c29b3c17ddc66a41c",
"comment": ""
},
{
"group": "test",
"interface": "Wireguard1",
"auto": true,
"reject": true,
"index": "4e6a4fc5fab8b15b55fa4c2a7e3ddbb2",
"comment": ""
}
]~ #

При Wireguard0 down трафик идет в провайдера.

Никогда не идет в Wireguard1.

Не реагирует на ping-check, если повесить ping-check на интерфейс Wireguard0 и будет status: fail, то маршрутизация по DNS не реагирует на этот статус.

Проверялось на KN-1810 прошивки 5.x (все версии не работает), 5.01.A. (не работает ни на одной из версий).

Приоритет маршрутов определяется порядком их ввода -- заявлено, но не функционирует.

приоритеты работают, следуют порядку заданному в веб (учитывается порядок в конфиге, в вашем выводе тоже будет видно)

эксклюзивность тоже работает, на 5.1А6 это было окончательно исправлено

Edited March 18 by Denis P

hoaxisr · March 19

Спойлер

8 часов назад, Denis P сказал:

приоритеты работают, следуют порядку заданному в веб (учитывается порядок в конфиге, в вашем выводе тоже будет видно)

ТП ответила несколько иначе. Порядок в WEB конфигураторе может не отражать порядок в running config и нельзя на него ориентироваться.

Как написал выше это не так, порядку правила не следуют, уходят после down первого интерфейса не во второй интерфейс указанный для правила а спокойно идут в провайдера, делают это практически сразу, при возвращении первого интерфейса в состояние up для возврата работы правила требуется достаточно длительный промежуток времени (до минуты) чтобы они опять начали работать, но во второй интерфейс они не идут никогда

Делаем правило, 1 доменом - любой ip check (например 2ip.io)

Включаем правило на два интерфейса.

Выключаем первый интерфейс (административно, делаем down)

Переключение не происходит.

При выключении интерфейса я вижу ip через wan (. 207), а не ip интерфейса 2, заданного на правило. (Должен быть не ip на wan). Ни в какой из альф это не работает и нельзя использовать, это не чинилось.

Порядок правил играет роль, в каком порядке назначаются интерфейсы через dns-proxy команду тот и будет первым, вопросов нет. Но, опять же, на второй интерфейс никогда не начинает "перекидывать".

Edited March 19 by hoaxisr

liliput-liliout · March 19

Аналогичная проблема.

Создаем правило и назначаем интерфейсы:

Спойлер

		"object-group fqdn domain-list0",
		"    description ipcheck",
		"    include wtfmyip.com",

		"dns-proxy",
		"    rebind-protect auto",
		"    route object-group domain-list0 Wireguard2 auto",
		"    route object-group domain-list0 Wireguard0 auto reject",
		"    tls upstream 9.9.9.9",
		"    tls upstream 8.8.8.8",
		"    tls upstream 1.1.1.1",
		"!",

Проверяем:

Спойлер

{
	"group": [
		{
			"group-name": "domain-list0",
			"enabled": true,
			"ipv4-addresses-count": 1,
			"ipv6-addresses-count": 0,
			"fqdn-count": 1,
			"entry": [
				{
					"fqdn": "wtfmyip.com",
					"type": "config",
					"deadline4": 1953,
					"deadline6": 107,
					"fail-counter4": 0,
					"fail-counter6": 1,
					"last-external": 18,
					"last-list-changed": 19,
					"ipv4": [
						{
							"address": "178.248.200.195",
							"ttl": 1800,
							"last-updated": 18
						}
					],
					"ipv6": []
				}
			],
			"excluded-ipv4": [],
			"excluded-ipv6": [],
			"excluded-fqdns": [],
			"fqdn-count-runtime": 0
		}
	],
	"prompt": "(config)"
}

При обращении на маршрутизируемый домен видим IP первого интерфейса.

Отключаем первый интерфейс.

interface Wireguard2 down

Обращаемся к этому же домену.

Спойлер

{
	"group": [
		{
			"group-name": "domain-list0",
			"enabled": true,
			"ipv4-addresses-count": 1,
			"ipv6-addresses-count": 0,
			"fqdn-count": 1,
			"entry": [
				{
					"fqdn": "wtfmyip.com",
					"type": "config",
					"deadline4": 1696,
					"deadline6": 102,
					"fail-counter4": 0,
					"fail-counter6": 3,
					"last-external": 276,
					"last-list-changed": 276,
					"ipv4": [
						{
							"address": "178.248.200.195",
							"ttl": 1800,
							"last-updated": 276
						}
					],
					"ipv6": []
				}
			],
			"excluded-ipv4": [],
			"excluded-ipv6": [],
			"excluded-fqdns": [],
			"fqdn-count-runtime": 0
		}
	],
	"prompt": "(config)"
}

И парам-парам-пам. Не видим IP второго интерфейса. Видим IP провайдера.

Для чистоты эксперимента. Сбрасываем кеш ДНС. (ipconfig /flushdns) конечно. Но толку с этого 0.

Первый интерфейс все еще down, и ничего не происходит. Обращения через второй интерфейс нет.

Из вывода fqdn видно, что даже после чистки кеша, last-updated не меняется.

Edited March 19 by liliput-liliout

Denis P · March 19

4 часа назад, hoaxisr сказал:

Показать контент

ТП ответила несколько иначе. Порядок в WEB конфигураторе может не отражать порядок в running config и нельзя на него ориентироваться.

Как написал выше это не так, порядку правила не следуют, уходят после down первого интерфейса не во второй интерфейс указанный для правила а спокойно идут в провайдера, делают это практически сразу, при возвращении первого интерфейса в состояние up для возврата работы правила требуется достаточно длительный промежуток времени (до минуты) чтобы они опять начали работать, но во второй интерфейс они не идут никогда

Делаем правило, 1 доменом - любой ip check (например 2ip.io)

Включаем правило на два интерфейса.

Выключаем первый интерфейс (административно, делаем down)

Переключение не происходит.

При выключении интерфейса я вижу ip через wan (. 207), а не ip интерфейса 2, заданного на правило. (Должен быть не ip на wan). Ни в какой из альф это не работает и нельзя использовать, это не чинилось.

Порядок правил играет роль, в каком порядке назначаются интерфейсы через dns-proxy команду тот и будет первым, вопросов нет. Но, опять же, на второй интерфейс никогда не начинает "перекидывать".

Для чистоты эксперимента тесты проводились на ip адресах, указанных в списках, а не доменах. Чтобы избежать сюрпризов с кешем, маленьким ТТЛ и другими подводными камнями

liliput-liliout · March 19

1 час назад, Denis P сказал:

Для чистоты эксперимента тесты проводились на ip адресах, указанных в списках, а не доменах. Чтобы избежать сюрпризов с кешем, маленьким ТТЛ и другими подводными камнями

И как эксперимент вы провели?

Что если обращаться к IP того домена, что был получен в fqdn группе идет обращение через второе правило?

А в чем смысл этого эксперимента? Заявлен другой функционал.

Denis P · March 19

15 минут назад, liliput-liliout сказал:

И как эксперимент вы провели?

Что если обращаться к IP того домена, что был получен в fqdn группе идет обращение через второе правило?

А в чем смысл этого эксперимента? Заявлен другой функционал.

речь шла о приоритетах и "эксклюзивных маршрутах" в DNS маршрутах - они работают. Конкретно при указании fqdn есть небольшие шероховатости

Edited March 19 by Denis P

liliput-liliout · March 19

5 минут назад, Denis P сказал:

речь шла о приоритетах и "эксклюзивных маршрутах" в DNS маршрутах - они работают. Конкретно при указании fqdn есть небольшие шероховатости

"Небольшие шероховатости" это такой интересный эвфемизм описывающий полную неработоспособность функционала для доменных имен?

Ну ок. Report Team буду знать.

hoaxisr · March 19

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

речь шла о приоритетах и "эксклюзивных маршрутах" в DNS маршрутах - они работают. Конкретно при указании fqdn есть небольшие шероховатости

Ну если говорить о том, что функция работает, проверяя ее в других условиях, то мне кажется это некорректно.

🤔

Нигде не заявлено, что функцию приоритета нельзя использовать для доменных имен, я проверил именно так. Вы проверили что-то другое и ответственно заявили, все работает.

Но не все работает.

UPD. Надо проверить 5.0.8

Edited March 19 by hoaxisr

Denis P · March 19

6 минут назад, hoaxisr сказал:

Вы проверили что-то другое и ответственно заявили, все работает.

всё то же самое, пакеты маркируются точно таким же образом, как при указании fqdn так и при указании cidr.
Разница только лишь в том что само разрешение доменов в ip адреса происходит не так как многим хотелось бы (пока что?)
з.ы "ответственно" мне приписывать не стоит, всё написанное тут - субъективно

hoaxisr · March 19

6 минут назад, Denis P сказал:

всё то же самое, пакеты маркируются точно таким же образом, как при указании fqdn так и при указании cidr.
Разница только лишь в том что само разрешение доменов в ip адреса происходит не так как многим хотелось бы (пока что?)
з.ы "ответственно" мне приписывать не стоит, всё написанное тут - субъективно

У вас badge это как бы уже определённый статус. Нет?

Как оно происходит под капотом я не знаю, так же оно маркирует пакеты или нет. Заниматься ловлей пакетов и смотреть нет желания.

Функционал заявлен, в стабильной ветке несколько раз ананосирован. Но пока не работает как заявлено.

Для себя я хотел выяснить только одно, воспроизводится ли такое поведение (с доменами) у других людей или нет. Вижу, что воспроизводится. Значит это баг. ТП при этом заявляет, что все работает корректно.

Вижу что в 4.3.7 LTS и новой 5.0.8 есть изменения "сброс соединений". Буду проверять как там это работает.

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

hoaxisr · March 27

Так сказать для истории.

Приведенные изыскания, селфтесты, и прочую информацию отправил в техподдержку 21.03, сегодня получил ответ, что цитата:

"На неделе обсудили ситуацию с разработчиками, завели задачу на исправление поведения.

Будем ждать."

Так что поведение маршрутизации по DNS в части fallback на другие указанные интерфейсы при использовании доменов подтвердили как нерабочую, надеюсь исправления будут включены в какую-то из версий.

Edited March 27 by hoaxisr

Sign In

Маршрутизация по DNS - цепочка туннелей

Question

evsasha

13 answers to this question

Recommended Posts

evsasha

hoaxisr

Denis P

hoaxisr

liliput-liliout

Denis P

liliput-liliout

Denis P

liliput-liliout

hoaxisr

Denis P

hoaxisr

hoaxisr

Join the conversation

Recently Browsing 0 members

Browse

Activity

Store

My Details

Important Information