Сохраните частные маршруты и откажитесь от перенаправления: разделённый туннель OpenVPN
Туннелю только для частных сетей нужны два правила: частные префиксы идут через него, обычный просмотр сохраняет свой локальный путь. Удаление маршрута по умолчанию — не политика.
Туннель поднимается, приложение загружается, и затем всё остальное на ноутбуке начинает вести себя странно. Это обычная форма политики только для частных сетей, реализованной удалением одной строки. Удаление протолкнутого маршрута по умолчанию действительно меняет, куда идёт трафик, но не говорит, куда трафик должен идти вместо этого, и совершенно не затрагивает разрешение имён. Политике нужны две положительные половины, прежде чем её можно будет проверить.
Удаление перенаправления — лишь половина изменения
Перенаправление всего туннеля и политика только для частных сетей различаются тем, что они утверждают о мире. Перенаправление претендует на каждое назначение, тогда как частная политика претендует на список и оставляет остальное в покое. Удаление претензии без написания списка даёт клиента, который не достигает ничего за пределами локальной сети, и это выглядит как сбой маршрутизации, а не как пробел в политике. Напишите список до того, как уберёте претензию, и тогда порядок этих двух шагов перестанет иметь значение.
Обе половины — требования, а не значения по умолчанию. Частные префиксы должны входить в туннель, а обычные назначения должны сохранить путь, который у них был до подключения.
Если организация требует полный туннель, ничего из этого не применяется. Дизайн только для частных сетей относится к развёртываниям, где раздельная маршрутизация одобрена.
pull-filter — это совпадение, а не переключатель
Директива pull-filter удаляет протолкнутые параметры, имена которых совпадают с префиксом, и это всё, что она делает. Игнорирование перенаправления оставляет каждый другой протолкнутый параметр на месте, что обычно и требуется: маршруты, настройки DNS и значение шлюза маршрута всё равно приходят. Она также не может удалить директиву, записанную в локальном профиле, потому что фильтрация применяется к тому, что проталкивает сервер.
Сопротивляйтесь соблазну игнорировать каждый параметр, начинающийся с route. Этот шаблон отбрасывает и частные маршруты, нужные соединению, и может потерять информацию о шлюзе, от которой зависит туннель.
route-nopull — более широкое решение, чем кажется. Оно не даёт клиенту принимать протолкнутые маршруты и параметры в стиле DHCP как группу, а это иная политика, чем отфильтровать один параметр.
Напишите список маршрутов от приложения наружу
Начните с того, что пользователь действительно открывает, затем добавьте поддерживающие части. Приложение по адресу 10.60.20.15 подразумевает свою подсеть 10.60.0.0/16, а частное имя подразумевает распознаватель, который на него отвечает. Поэтому пользователю, запросившему одно приложение, нужны два назначения и одно решение по DNS. Всё за пределами этого списка по построению вне области охвата, и именно это делает политику проверяемой.
На сотрудничающем сервере они становятся двумя протолкнутыми маршрутами, и ни один из них не является перенаправлением. Сохраните топологию туннеля и значения шлюза маршрута, которые предоставляет существующая служба.
Когда эта политика нужна только части пользователей, применяйте её для каждого клиента или группы. Менять маршрутизацию всем, чтобы исправить требование одной команды, — это путь, которым разделённый туннель превращается в простой.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
Пусть DNS идёт тем же путём
Маршрут к распознавателю — не политика распознавателя. На клиенте systemd-resolved смысловой результат — это домен маршрутизации для частного пространства имён, указывающий на внутренний распознаватель, и именно это заставляет только эти имена использовать его. Клиенту Windows нужен вместо этого собственный механизм политики пространств имён. Строка DNS-сервера в профиле сама по себе не устанавливает ни то, ни другое.
Проверяйте, что выбрала операционная система, а не что запросил профиль. В Linux resolvectl status показывает домен и сервер для каждого соединения; в Windows таблица политики пространств имён является эквивалентным доказательством.
Держите распознаватель доступным через туннель, иначе политика указывает на адрес, который нельзя опросить. Адрес распознавателя, до которого туннель не достаёт, превращает работающую политику в тайм-аут.
Проверьте обе половины при переподключении
Переподключите клиента после изменения и проверьте действующий маршрут к частному и к публичному адресу. Затем разрешите частное имя и публичное имя и убедитесь, что каждое использовало предназначенный распознаватель. Загрузка публичного сайта доказывает только вторую половину, и обычно именно эта половина работает случайно.
Запишите готовую политику одним предложением: эти префиксы и имена используют это соединение, всё остальное следует локальному пути. Затем держите её в профиле, а не чините настройки адаптера после каждого входа.