Перейти к содержанию

Вопрос

Опубликовано

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

  • Есть обычный интерфейс от 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.

 

Рекомендуемые сообщения

  • 0
Опубликовано

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

  • 0
Опубликовано
9 minutes ago, r13 said:

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

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

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

  • 0
Опубликовано

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

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.