Конфликт между определением IP для KeenDNS и FQDN-маршрутизацией при использовании Wireguard

[himikof]

Добрый день, наблюдаю следующую картину:

• Есть обычный интерфейс от ISP с глобально маршрутизуемым IPv4.
• Есть несколько WG-туннелей (IP адреса которых не маршрутизуемы извне) используемых для доступа в Интернет.
• Хочется использовать FQDN-маршрутизацию, чтобы пускать некоторые (многие) сайты в обход туннелей.
• Также используется WG-сервер, через который подключаются мобильные клиенты, что сейчас требует KeenDNS в режиме Direct.

Как я понимаю, KeenDNS/ndns автоматически подхватывает IP-адрес с активного глобального интерфейса с наибольшим приоритетом. Если подняты туннели, это будет нерабочий адрес из туннеля, а не рабочий адрес от ISP. Как рекомендовалось здесь , я использовал альтернативную политику (таблицу маршрутизации) с приоритетом туннелей, чтобы оставить по умолчанию ISP-интерфейс с максимальным приоритетом и гарантировать именно его адрес в KeenDNS.

Но, как и написано в документации, FQDN-маршрутизация работает только при использовании политики по умолчанию, в которой у меня должен быть выше приоритет у туннелей, что в свою очередь ломает KeenDNS.

Я вижу 3 варианта исправить ситуацию:

1. Реализовать поддержку FQDN-маршрутизации для не-default политик. Я полагаю, что это может быть технически непросто.
2. Реализовать возможность явного выбора подмножества глобальных интерфейсов, адреса которых будут рассматриваться в качестве "внешнего IP" для KeenDNS/DynDNS. Меня лично устроило бы даже более специфическое решение с определением единственного такого интерфейса.
3. Автоматически исключить адреса Wireguard интерфейсов из кандидатов для "внешнего IP". Я лично не могу придумать сценарий, в котором они бы были полезны в таком качестве (в отличие от, скажем, PPTP, я не могу себе представить ISP, который бы использовал Wireguard для клиентской аутентификации).

Я пробовал также найти рабочую конфигурацию, в которой у Wireguard-интерфейсов туннелей снят флаг "ip global", что исправляет проблему с выбором адреса для KeenDNS, но мне не удалось направить в них корректно траффик по умолчанию.

Примечание: некоторые из туннелей используют RFC 1918 адреса, некоторые нет. Но они все не годятся в качестве "внешнего IP".

Описанное поведение сейчас вижу на 5.1 Alpha 4, но, кажется, оно было таким же и на 5.0.

 

[r13]

При fqdn маршрутизации не нужно поднимать приоритет тунелей. Верхним должен быть isp в политике по умолчанию

[himikof]

9 minutes ago, r13 said:

При fqdn маршрутизации не нужно поднимать приоритет тунелей. Верхним должен быть isp в политике по умолчанию

Можно чуть подробнее, как в такой конфигурации достичь требуемой маршрутизации? "Весь траффик идёт через туннель (если он активен), за исключением нескольких доменов, которые идут через ISP напрямую"

Я использую FQDN object-group, чтобы перечислить эти исключения, с правилом "dns-proxy route object-group" на интерфейс ISP с меньшим приоритетом.

[r13]

Можно в object-group включить подсеть по ip(0.0.0.0/0 яля  default route) и исключить требуемые домены

[Miles27]

Вопрос как всё-таки реализована строка в конфиге AllowedIPs = х.х.х.х/16 (не могу понять почему не работает маршрутизация не попавшая в список соединения Wg) если в приоритетах подключения первым стоит основной WG а вторым WAN интерфейс. 

Если прописать в соединении WG нужные подсети то Интернет в целом начинает тормозить и tracert c Пк проходит с потерями пакетов.

Если  разрешить весь трафик через созданный тоннель 0.0.0.0/0 то проблема уходит. (Наверно это связано с бета тестом прошивок и не всё так гладко)

Edited May 25 by Miles27