himikof

Можно чуть подробнее, как в такой конфигурации достичь требуемой маршрутизации? "Весь траффик идёт через туннель (если он активен), за исключением нескольких доменов, которые идут через ISP напрямую" Я использую FQDN object-group, чтобы перечислить эти исключения, с правилом "dns-proxy route object-group" на интерфейс ISP с меньшим приоритетом.

Добрый день, наблюдаю следующую картину: Есть обычный интерфейс от ISP с глобально маршрутизуемым IPv4. Есть несколько WG-туннелей (IP адреса которых не маршрутизуемы извне) используемых для доступа в Интернет. Хочется использовать FQDN-маршрутизацию, чтобы пускать некоторые (многие) сайты в обход туннелей. Также используется WG-сервер, через который подключаются мобильные клиенты, что сейчас требует KeenDNS в режиме Direct. Как я понимаю, KeenDNS/ndns автоматически подхватывает IP-адрес с активного глобального интерфейса с наибольшим приоритетом. Если подняты туннели, это будет нерабочий адрес из туннеля, а не рабочий адрес от ISP. Как рекомендовалось здесь , я использовал альтернативную политику (таблицу маршрутизации) с приоритетом туннелей, чтобы оставить по умолчанию ISP-интерфейс с максимальным приоритетом и гарантировать именно его адрес в KeenDNS. Но, как и написано в документации, FQDN-маршрутизация работает только при использовании политики по умолчанию, в которой у меня должен быть выше приоритет у туннелей, что в свою очередь ломает KeenDNS. Я вижу 3 варианта исправить ситуацию: Реализовать поддержку FQDN-маршрутизации для не-default политик. Я полагаю, что это может быть технически непросто. Реализовать возможность явного выбора подмножества глобальных интерфейсов, адреса которых будут рассматриваться в качестве "внешнего IP" для KeenDNS/DynDNS. Меня лично устроило бы даже более специфическое решение с определением единственного такого интерфейса. Автоматически исключить адреса Wireguard интерфейсов из кандидатов для "внешнего IP". Я лично не могу придумать сценарий, в котором они бы были полезны в таком качестве (в отличие от, скажем, PPTP, я не могу себе представить ISP, который бы использовал Wireguard для клиентской аутентификации). Я пробовал также найти рабочую конфигурацию, в которой у Wireguard-интерфейсов туннелей снят флаг "ip global", что исправляет проблему с выбором адреса для KeenDNS, но мне не удалось направить в них корректно траффик по умолчанию. Примечание: некоторые из туннелей используют RFC 1918 адреса, некоторые нет. Но они все не годятся в качестве "внешнего IP". Описанное поведение сейчас вижу на 5.1 Alpha 4, но, кажется, оно было таким же и на 5.0.