Профиль маршрутизации для VPN и удаленного доступа: split tunneling, маршруты и DNS

Профиль маршрутизации для VPN: что направлять через туннель

Профиль маршрутизации VPN задает, какие IP-сети и адреса доступны через защищенный туннель, а какие продолжают использовать обычное подключение. При split tunneling через VPN направляют корпоративные подсети, внутренние DNS-серверы и административные сервисы. Домашняя сеть и публичный интернет при этом обслуживает локальный шлюз.

При полном туннеле клиент получает маршрут по умолчанию, например 0.0.0.0/0 для IPv4 и ::/0 для IPv6. Весь трафик проходит через VPN-шлюз. При раздельном туннелировании в профиле указывают конкретные префиксы, например 10.20.0.0/16, а маршрут по умолчанию остается у домашнего или мобильного подключения.

Маршрут отвечает за путь к IP-адресу. DNS отвечает за преобразование имени сервиса в IP-адрес. Поэтому доступ к git.corp.example требует согласованной настройки маршрута до сервера Git, корпоративного DNS, DNS-зоны и TCP-порта приложения. Формат профиля зависит от VPN-шлюза, сервера, операционной системы и клиентского приложения.

Что такое профиль маршрутизации VPN

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

Универсального файла с одинаковыми директивами для WireGuard, OpenVPN, IKEv2, RRAS и облачных VPN-шлюзов нет. Один клиент может получать список маршрутов через серверную политику, другой требует ручного добавления префиксов, третий использует отдельные параметры для DNS и маршрута по умолчанию.

Профиль не заменяет контроль доступа. Он указывает сетевой путь, но доступ к конкретному сервису дополнительно зависит от ACL, firewall, обратного маршрута и разрешенных портов.

Раздельное туннелирование VPN и полный туннель

Типовая схема split tunneling выглядит так: подсеть приложений 10.20.0.0/16, сеть мониторинга 10.30.40.0/24 и внутренний DNS 10.20.0.53 доступны через VPN. Домашняя сеть 192.168.1.0/24 идет через локальный роутер, например 192.168.1.1. Публичные сайты используют обычный интернет-канал.

Full tunnel выбирают, когда организация должна фильтровать весь трафик, применять единые правила безопасности или скрывать адрес пользователя за корпоративным шлюзом. Split tunneling подходит для удаленного доступа к ограниченному набору сервисов, когда нет требования направлять весь интернет через компанию.

Раздельный режим повышает требования к контролю конечного устройства. Компьютер одновременно подключен к недоверенной локальной сети и корпоративной инфраструктуре. Политика удаленного доступа должна учитывать firewall, состояние устройства, антивирусную защиту и правила доступа к сервисам.

Практические схемы для WireGuard и OpenVPN собраны в материале о маршрутизации нужного трафика через VPN.

Маршрутизация сетей и доступ к сервисам, не одно и то же

Маршрут работает с IP-адресом назначения. Если приложение обращается к имени, сначала происходит DNS-разрешение, затем система выбирает маршрут до полученного адреса, после чего устанавливает соединение с нужным портом.

Например, сервис git.corp.example может разрешаться в 10.20.30.15. Для его работы нужны:

• DNS-запись во внутренней зоне;
• маршрут до 10.20.30.0/24 через VPN;
• разрешение TCP-порта 443 на firewall;
• обратный маршрут от сервера к адресу VPN-клиента;
• корректная настройка самого Git-сервера.

Добавление маршрута до подсети не гарантирует открытие всех сервисов внутри нее. В одной сети могут находиться базы данных, панели управления и узлы мониторинга с разными ACL. Указывайте в матрице доступа и адрес, и порт, и назначение сервиса.

Маршрутизация по доменному имени требует специальной функции клиента или дополнительного механизма, например динамического обновления маршрутов по результатам DNS-запросов. Большинство обычных таблиц маршрутизации работает с IP-префиксами, поэтому FQDN нужно связать с устойчивыми адресами или контролировать изменение записей.

Как спроектировать профиль маршрутизации удаленного доступа

Настройку начинайте с перечня ресурсов, а не с добавления маршрутов в клиент. Сначала зафиксируйте сети, DNS-зоны, порты, роли пользователей и локальные сегменты. После этого будет понятно, какие префиксы включить в профиль и какие направления оставить вне VPN.

Инвентаризация корпоративных сетей и сервисов

Для каждого ресурса запишите фактический IP-адрес или FQDN. Проверьте, не меняется ли адрес через балансировщик, CDN или кластерный сервис. В список обычно попадают:

• сети приложений и API;
• файловые хранилища и NAS;
• системы мониторинга и журналирования;
• контроллеры домена, LDAP и внутренние DNS-серверы;
• Git-сервисы, CI/CD и registry;
• базы данных и очереди сообщений;
• административные интерфейсы серверов, сетевого оборудования и гипервизоров.

Проверьте IPv4 и IPv6 отдельно. Если сервис публикует AAAA-запись, клиент может выбрать IPv6-адрес и обойти настроенный IPv4-маршрут. Для каждого FQDN зафиксируйте ожидаемые A и AAAA записи.

Матрица трафика: через VPN, напрямую или запретить

Матрица трафика превращает профиль маршрутизации в проверяемую политику. Используйте три состояния: через VPN, напрямую через локальный шлюз и запретить. Запись «не указано» оставляет слишком много места для разных трактовок на клиентах.

В отдельной строке укажите локальные ресурсы пользователя: принтеры, домашние серверы, медиахранилища и устройства умного дома. Для них зафиксируйте ожидаемый интерфейс. Это поможет обнаружить ситуацию, когда VPN-клиент перехватил локальный маршрут.

Пересекающиеся адресные пространства

Одинаковые частные подсети в домашней и корпоративной сети создают конфликт. Например, пользователь подключен к домашней сети 10.20.0.0/24, а через VPN должен попасть в корпоративную сеть с таким же префиксом. Операционная система видит два одинаковых назначения, а приложение получает адрес, который может находиться в локальном сегменте.

Метрика не устраняет такой конфликт во всех сценариях. Локальный ARP, правила VPN-клиента, NAT и особенности шлюза могут привести к разным результатам. Проблема проявляется так:

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

Предпочтительный вариант, перенумеровать один из сегментов. Если это невозможно, применяют NAT на VPN-шлюзе, отдельный адресный пул, прокси-доступ или архитектуру с промежуточным bastion-хостом. Более специфичный маршрут помогает только при корректной адресации и наличии рабочего обратного пути.

Сводные маршруты и минимальный набор префиксов

Агрегированный маршрут уменьшает размер профиля. Если все необходимые сервисы находятся внутри 10.20.0.0/16, один префикс может заменить несколько сетей 10.20.10.0/24, 10.20.30.0/24 и 10.20.50.0/24.

Широкий маршрут применяйте только после проверки состава адресного пространства. Префикс 10.0.0.0/8 может захватить сети, которые не относятся к корпоративным сервисам, включая сегменты партнеров и локальные сети пользователей. Чем шире маршрут, тем сложнее объяснить и проверить фактический путь трафика.

Для привилегированных ролей используйте отдельные профили с узкими маршрутами. Администратору инфраструктуры может требоваться доступ к 10.99.0.0/24, а сотруднику финансового отдела достаточно 10.20.60.0/24. Маршруты связывайте с ACL и группами пользователей.

Как настроить split tunneling VPN на практике

Рабочий алгоритм состоит из четырех этапов: определить защищенные префиксы, передать их клиенту, проверить конечную таблицу маршрутизации и протестировать положительные и отрицательные сценарии. Команды и названия параметров сверяйте с документацией конкретного VPN-продукта.

Настройка маршрутов на VPN-шлюзе или сервере

Централизованная политика удобнее для корпоративной сети. Администратор задает список маршрутов на сервере, а клиент получает его при подключении. Изменение одного профиля сразу распространяется на группу пользователей, поэтому перед публикацией нужен пилотный тест.

На серверной стороне проверьте пять условий:

1. VPN-шлюз знает маршруты до внутренних подсетей.
2. Корпоративные маршрутизаторы знают обратный путь к пулу адресов VPN-клиентов.
3. ACL разрешают нужные сети и порты.
4. Маршрут по умолчанию не передается клиенту без отдельного требования.
5. DNS-серверы доступны через тот же туннель и отвечают на внутренние зоны.

Если используется Windows Server и служба RRAS, проверьте распределение маршрутов для конкретного типа VPN-подключения, адресный пул, политики доступа и обратные маршруты. Пошаговая настройка описана в руководстве по маршрутизации VPN-клиентов в Windows Server 2026.

В Azure VPN Gateway политика маршрутизации ограничена маршрутной таблицей. Простая смена туннельного протокола не заменяет список префиксов и не меняет его автоматически.

Настройка маршрутов в клиентском профиле

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

Для каждого профиля зафиксируйте:

• название и назначение профиля;
• поддерживаемые операционные системы и версии клиента;
• VPN-интерфейс и адресный пул;
• список IPv4- и IPv6-маршрутов;
• поведение маршрута по умолчанию;
• внутренние DNS-серверы и DNS suffix;
• дату выпуска и процедуру отката.

Не смешивайте full tunnel и split tunneling в одном неясно названном файле. Создайте отдельные профили, например corp-split-v3 и corp-full-v3. Так администратор сможет быстро определить политику по имени и вернуть предыдущую рабочую версию.

Условный пример профиля маршрутизации

Ниже приведена логическая модель, а не готовый файл для конкретного клиента. Она показывает ожидаемое поведение профиля:

PROFILE_NAME=corp-split-v1
VPN_ROUTES=10.20.0.0/16,10.30.40.0/24
INTERNAL_DNS=10.20.0.53
DNS_ZONES=corp.example,monitor.corp.example
LOCAL_NETWORK=192.168.1.0/24
DEFAULT_ROUTE_V4=LOCAL
DEFAULT_ROUTE_V6=POLICY_DEFINED

В этой схеме корпоративные сети 10.20.0.0/16 и 10.30.40.0/24 идут через VPN. Сеть 192.168.1.0/24 остается локальной. Маршрут 0.0.0.0/0 через VPN отсутствует. IPv6 нужно настроить отдельным правилом, иначе часть трафика может пойти по пути, который не отражен в IPv4-политике.

Замените условные адреса фактическими сетями инфраструктуры. Проверьте, что 10.20.0.53 действительно обслуживает корпоративную DNS-зону, а VPN-шлюз имеет обратный маршрут к адресу клиента.

Проверка split tunneling сразу после подключения

Проверяйте не факт подключения, а фактический путь трафика. Последовательность выглядит так:

1. Убедитесь, что VPN-клиент показывает успешное соединение.
2. Найдите новый VPN-интерфейс и его адрес.
3. Проверьте маршруты до всех корпоративных префиксов.
4. Проверьте маршрут по умолчанию и локальный шлюз.
5. Откройте локальное устройство, например 192.168.1.20.
6. Проверьте корпоративный сервис по IP и по имени.
7. Проверьте внешний IP и доступ к публичному ресурсу.
8. Проверьте отрицательный сценарий, доступ к сети, которая должна быть запрещена.

Для каждого теста запишите ожидаемый интерфейс, шлюз, адрес назначения и результат. Если корпоративный IP доступен, а имя нет, переходите к DNS. Если не работает и IP, проверяйте маршрут, ACL, firewall и обратный путь.

Таблица маршрутизации VPN: приоритеты и выбор маршрута

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

Наиболее специфичный маршрут имеет преимущество

Для адреса 10.20.30.15 маршрут 10.20.30.0/24 точнее, чем 10.20.0.0/16. Если оба маршрута активны, система обычно выбирает префикс с длиной /24. Для адреса 10.20.90.15 маршрут /24 уже не подходит, поэтому используется 10.20.0.0/16, если он присутствует.

Более специфичный маршрут может быть намеренным исключением. Например, весь диапазон 10.20.0.0/16 идет через корпоративный VPN, а подсеть 10.20.30.0/24 направлена через отдельный сетевой интерфейс для доступа к лабораторному стенду.

Проверяйте фактический маршрут до конкретного адреса, а не только наличие широкой сети. Это особенно важно при наличии нескольких VPN-клиентов, виртуальных машин, Docker-сетей и корпоративных агентов безопасности.

Метрика и конкурирующие маршруты

Метрика помогает выбрать путь, когда совпадают назначение и длина префикса. Ее трактовка зависит от операционной системы, драйвера и VPN-клиента. Одинаковое значение на Windows и Linux не дает гарантии одинакового выбора.

При конфликте ищите:

• два маршрута с одинаковым префиксом;
• старые записи после предыдущего VPN-сеанса;
• маршруты виртуальных адаптеров Docker, Hyper-V, VMware или VirtualBox;
• автоматически добавленные маршруты агента безопасности;
• неактивный или изменивший адрес шлюз;
• маршрут, который клиент удаляет после переподключения.

Снимите таблицу до подключения, сразу после подключения и после отключения VPN. Сравнение трех состояний показывает, какие записи добавил клиент и какие из них остались после завершения сеанса.

Маршрут по умолчанию в IPv4 и IPv6

Маршрут 0.0.0.0/0 совпадает с любым IPv4-адресом, если для него нет более точного префикса. Маршрут ::/0 выполняет такую же функцию для IPv6. Появление этих записей через VPN превращает split tunneling в full tunnel для соответствующего стека.

Проверьте оба варианта:

• публичный IPv4-адрес и путь к интернету;
• публичный IPv6-адрес, если он доступен в локальной сети;
• маршрут до локальной подсети;
• DNS-сервер, который используется при обращении к внешним именам;
• поведение при временном отключении VPN.

Политику IPv6 нужно зафиксировать заранее. Возможны три варианта: направлять корпоративный IPv6 через VPN, направлять весь IPv6 через VPN или отключать IPv6 на клиенте по требованиям безопасности. Оставлять этот вопрос без проверки опасно, поскольку IPv6-трафик может обойти ожидаемые IPv4-правила.

Как посмотреть таблицу маршрутизации на разных ОС

В Windows используйте PowerShell:

Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
route print

Для адресного теста полезна команда:

Test-NetConnection 10.20.30.15 -Port 443

В Linux проверьте таблицы и конкретный путь:

ip route
ip -6 route
ip route get 10.20.30.15

В macOS используйте:

netstat -rn
route -n get 10.20.30.15

Ищите четыре значения: сеть назначения, шлюз, интерфейс и метрику. Команда проверки конкретного адреса полезнее просмотра всей таблицы, поскольку сразу показывает путь, который система выбрала для нужного сервиса.

DNS при подключении к VPN: split DNS и типовые конфликты

Ситуация «сервис открывается по IP, но не по имени» почти всегда требует отдельной проверки DNS. Маршрут до сервера может быть исправен, а клиент обращается к публичному или домашнему резолверу, который не знает внутреннюю зону.

Почему сервис доступен по IP, но не по имени

Проверьте цепочку разрешения имени:

1. какой FQDN использует приложение;
2. какой DNS-сервер отвечает на запрос;
3. есть ли маршрут до этого DNS-сервера через VPN;
4. существует ли внутренняя запись A или AAAA;
5. применяется ли нужный search domain;
6. не перехватывает ли запрос локальный DNS-прокси или браузер.

На Windows выполните:

nslookup git.corp.example
nslookup git.corp.example 10.20.0.53

В Linux используйте:

dig git.corp.example
resolvectl status
resolvectl query git.corp.example

Сравните ответ системного резолвера с прямым запросом к корпоративному DNS. Если второй запрос возвращает внутренний адрес, а первый нет, проблема связана с выбором резолвера, DNS suffix или split DNS.

Корпоративный DNS через VPN

Внутренний DNS-сервер должен быть доступен через VPN-маршрут. Для сервера 10.20.0.53 требуется маршрут до его подсети, разрешение UDP и TCP-порта 53, а при необходимости доступ к DNS over TLS или другим корпоративным механизмам.

Профиль обычно передает:

• адреса внутренних DNS-серверов;
• корпоративный DNS suffix;
• зоны, которые должны разрешаться через VPN;
• порядок применения DNS-политик;
• правило поведения при недоступности VPN.

DNS-настройка без маршрута до резолвера не работает. Обратная ситуация тоже встречается: маршрут до DNS есть, но firewall разрешает только часть запросов или внутренний сервер не знает нужную зону.

Split DNS, утечки запросов и локальный резолвер

При полном переключении DNS все запросы идут к корпоративным серверам. Такой режим упрощает контроль, но может увеличить задержку для внешних имен. При split DNS внутренние зоны, например corp.example, отправляются через VPN, а публичные домены разрешаются локальным резолвером.

Проверьте конфликтующие компоненты:

• локальный DNS-прокси домашнего роутера;
• systemd-resolved и NetworkManager в Linux;
• службу DNS Client в Windows;
• собственный резолвер macOS;
• DoH в браузере;
• мобильные VPN-клиенты с отдельной DNS-политикой.

DoH может отправить запрос напрямую к внешнему провайдеру, минуя системные правила split DNS. Если внутренние имена должны оставаться внутри корпоративной инфраструктуры, проверьте настройки браузеров и управляющих политик.

Подробные сценарии выборочной маршрутизации DNS для WireGuard, OpenVPN и strongSwan описаны в руководстве по split tunneling и защите DNS.

Проверка DNS на клиенте

Проверяйте внутреннее и внешнее имя отдельно. Для внутреннего домена ожидайте ответ корпоративного DNS и адрес из защищенной сети. Для внешнего домена проверьте, идет ли запрос по согласованному локальному или корпоративному пути.

Зафиксируйте:

• сервер, который ответил;
• время ответа;
• полученные A и AAAA записи;
• search domain;
• результат при подключенном и отключенном VPN;
• маршрут до DNS-сервера.

Перезапуск VPN-клиента иногда очищает временное состояние, но не исправляет неправильную политику. Сначала снимите результаты команд, затем меняйте DNS-настройки и повторяйте тест.

Протокол VPN и клиентский профиль: совместимость перед внедрением

Транспортный протокол отвечает за установление и передачу данных. Политика маршрутизации определяет сети, которые клиент использует после подключения. Эти уровни связаны, но смена протокола сама по себе не исправляет неправильный маршрут.

IKEv2: UDP 500 и UDP 4500 в ограниченных сетях

IKEv2 использует UDP-порты 500 и 4500. В гостиничных, аэропортовых, кафе и гостевых сетях эти порты могут блокироваться или ограничиваться. В результате туннель не устанавливается, хотя профиль маршрутизации составлен правильно.

Если IKEv2 не подключается, сначала проверьте:

• доступность UDP 500 и 4500;
• журнал VPN-клиента;
• сертификаты и параметры аутентификации;
• работу NAT-T;
• наличие другого активного VPN-подключения.

Изменение метрики маршрутов до установления туннеля не поможет. У клиента еще нет рабочего VPN-интерфейса, через который можно направить трафик.

OpenVPN через TCP 443 и совместимость клиентов

OpenVPN может работать через TCP 443, что помогает подключаться из сетей, где UDP-трафик ограничен. Клиенты доступны для Windows, macOS, Linux, iOS и Android, но формат профиля, поддержка отдельных директив и способ применения маршрутов зависят от конкретной версии.

После перехода на OpenVPN проверьте:

• импорт профиля на каждой платформе;
• создание VPN-интерфейса;
• появление корпоративных маршрутов;
• сохранение локального маршрута по умолчанию;
• настройку внутренних DNS-зон;
• поведение IPv6;
• записи в журнале клиента.

Почему смена протокола требует обновления клиентского профиля

При смене SSTP, IKEv2 или OpenVPN меняются транспорт, параметры подключения и формат клиентской конфигурации. Выпустите новый профиль, импортируйте его на тестовых устройствах и повторите полный набор проверок маршрутов и DNS.

Для Azure VPN Gateway переход с SSTP на OpenVPN требует новой клиентской конфигурации и повторного развертывания на конечных устройствах. SSTP и OpenVPN могут иметь ограничения совместного использования на одном шлюзе, поэтому план миграции проверяйте по конкретной конфигурации Azure.

Новые шлюзы Azure VPN Gateway не могут включать SSTP с 31 марта 2026 года. Для существующих SSTP-подключений указана дата прекращения работы 31 марта 2027 года. Эти сроки относятся к Azure VPN Gateway и не задают поведение других VPN-платформ.

Особенности Azure VPN Gateway при миграции протокола

В Azure VPN Gateway маршрутная политика опирается на таблицу маршрутов. Замена SSTP на IKEv2 или OpenVPN не добавляет автоматически новые корпоративные сети и не удаляет старые записи. После миграции проверьте серверную таблицу, клиентский профиль, NSG, ACL и обратные маршруты.

IKEv2 может быть предпочтительным вариантом в сетях с доступным UDP. OpenVPN через TCP 443 пригодится при ограничениях UDP, но TCP поверх TCP способен ухудшать поведение при потерях и высокой задержке. Выбор делайте по результатам тестов в реальных сетях пользователей.

Постквантовое согласование ключей работает при поддержке сервером и клиентом. Для Access Server с OpenSSL 3.5 или новее группой по умолчанию может быть X25519MLKEM768, сочетание X25519 и ML-KEM. OpenVPN Connect v3 не поддерживает OpenSSL 3.5, поэтому совместимость клиента нужно проверить до выдачи профиля.

Диагностика нестабильного VPN: от туннеля к DNS

Ищите причину последовательно. Не меняйте маршрут, DNS, MTU и протокол одновременно, иначе исчезнет исходная точка сравнения. Удобный порядок: состояние туннеля, интерфейс, маршрут, порт сервиса, DNS, ACL и параметры приложения.

Проверка состояния VPN-соединения и интерфейса

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

В журнале ищите:

• успешную аутентификацию;
• выдачу адреса VPN-клиенту;
• получение маршрутов;
• получение DNS-параметров;
• ошибки добавления маршрута;
• переподключения и смену протокола.

Если VPN-интерфейс отсутствует, анализ таблицы маршрутизации преждевременен. Сначала исправьте транспорт, сертификаты, учетную запись или совместимость клиента.

Проверка маршрута до конкретного ресурса

Выберите один внутренний IP-адрес и проверьте путь до него. В Windows используйте Test-NetConnection, в Linux, ip route get, в macOS, route -n get. ICMP-проверка подходит только там, где ping разрешен политикой.

После выбора маршрута проверьте TCP-порт приложения. Например, успешный ping не подтверждает работу HTTPS, SMB или PostgreSQL. Тест должен соответствовать реальному сценарию пользователя.

Для анализа сложных случаев пригодится руководство по диагностике сетевой маршрутизации с traceroute, MTR и ip route.

Разбор симптомов по типовым сценариям

Когда проблема уже не в профиле маршрутизации

Профиль не исправит блокировку на серверном firewall, отсутствие обратного маршрута, пересечение адресных пространств или ошибку приложения. В отдельную группу входят MTU, фрагментация, тайм-ауты, перегрузка VPN-шлюза и ограничения транспорта.

Если маршрут выбран правильно, но TCP-порт не отвечает, проверьте:

• ACL на VPN-шлюзе и межсетевом экране;
• локальный firewall сервера;
• обратный маршрут к пулу VPN-адресов;
• прослушивание нужного порта;
• MTU и фрагментацию;
• лимиты сессий и пропускную способность шлюза;
• политику самого приложения.

Сетевые фильтры и политики устройства могут блокировать трафик после правильного выбора интерфейса. Диагностируйте каждый уровень отдельно.

Безопасность и эксплуатация профиля маршрутизации

Split tunneling уменьшает объем трафика через VPN-шлюз, но оставляет часть соединений вне корпоративного контроля. Профиль проектируйте вместе с политикой удаленного доступа, ACL, firewall и требованиями к конечному устройству.

Минимально необходимый набор маршрутов

Выдавайте пользователю только те сети, которые нужны его роли. Доступ ко всей сети 10.0.0.0/8 без технической причины расширяет область потенциального доступа и усложняет аудит.

Разделите профили по группам:

• сотрудники, только внутренние приложения;
• DevOps-инженеры, Git, registry, CI/CD и мониторинг;
• администраторы, отдельные серверные и сетевые сегменты;
• подрядчики, ограниченные сервисы через прокси или bastion-хост.

Маршрут связывайте с ACL. Наличие префикса в таблице не должно автоматически открывать все порты внутри сети.

Проверка локального доступа и утечек трафика

Для split tunneling составьте явный список трафика, который остается локальным. Проверьте внешний IP, путь к публичному сервису, DNS-запросы, IPv6 и доступ к домашним устройствам.

Проверка должна отвечать на четыре вопроса:

1. Идет ли корпоративный трафик через VPN-интерфейс?
2. Идет ли внешний IPv4-трафик через ожидаемый шлюз?
3. Не обходит ли IPv6 заданную политику?
4. Не отправляются ли внутренние DNS-запросы локальному или публичному резолверу?

Если локальный интернет разрешен, конечное устройство должно иметь собственные правила firewall. VPN-маршрут не защищает трафик, который намеренно остается вне туннеля.

Проверка, версионирование и откат

Изменения сначала проверяйте в непроизводственной среде. Создайте тестовую группу из представителей разных ролей и платформ, затем выпускайте профиль шире после успешной проверки.

Храните:

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

Для отдельного стенда можно использовать облачный VDS, где проверяются маршруты, DNS и firewall без риска затронуть рабочую сеть. Подходящую инфраструктуру для лаборатории предоставляет Timeweb Cloud.

Поддержка нескольких клиентских платформ

Один и тот же профиль может по-разному применяться на Windows, macOS, Linux, iOS и Android. Различаться могут метрики, обработка нескольких DNS-серверов, поддержка IPv6, split DNS и права на добавление маршрутов.

Для каждой платформы проверьте:

• появление VPN-интерфейса;
• маршруты до корпоративных сетей;
• маршрут по умолчанию;
• доступ к локальному сегменту;
• разрешение внутренних имен;
• работу DoH и локального DNS-прокси;
• журналы клиента;
• способ обновления и удаления старого профиля.

Практический чек-лист настройки маршрутизации VPN

1. Определите корпоративные сети, отдельные хосты, сервисы, DNS-зоны и порты.
2. Проверьте пересечения корпоративных подсетей с домашними и мобильными сетями пользователей.
3. Выберите full tunnel или split tunneling для каждой группы пользователей.
4. Зафиксируйте поведение IPv4, IPv6, маршрутов 0.0.0.0/0 и ::/0.
5. Настройте маршруты на VPN-сервере или в клиентском профиле.
6. Добавьте внутренние DNS-серверы, DNS suffix и правила split DNS.
7. Проверьте длину префиксов, метрики, конкурирующие маршруты и локальный шлюз.
8. Протестируйте корпоративные сервисы по IP, по имени и через нужный TCP-порт.
9. Проверьте локальные устройства, внешний интернет, IPv6 и отрицательные сценарии.
10. Сопоставьте результаты с ACL, firewall и журналами VPN-шлюза.
11. Сохраните рабочую версию профиля и подготовьте процедуру отката.

FAQ: частые вопросы о профиле маршрутизации VPN

Можно ли сохранить доступ к домашней сети при подключении к VPN?

Да, если профиль не перехватывает маршрут до домашней подсети и не устанавливает полный маршрут по умолчанию через VPN. Проверьте, что сеть пользователя, например 192.168.1.0/24, остается через локальный шлюз, а корпоративные префиксы идут через VPN. При одинаковых адресных пространствах потребуется перенумерация, NAT или изменение архитектуры доступа.

Почему после подключения VPN интернет стал медленнее?

Сначала проверьте появление маршрута 0.0.0.0/0 или ::/0 через VPN. Затем сравните внешний IP, DNS-сервер, задержку и пропускную способность с отключенным туннелем. Если full tunnel не используется, проверьте MTU, локальный firewall и состояние VPN-шлюза.

Почему ресурс открывается по IP, но не по доменному имени?

Проверьте внутренний DNS, маршрут до него, split DNS, search domain и локальный резолвер. Сравните обычный запрос с прямым запросом к корпоративному DNS. Если корпоративный сервер возвращает правильный адрес, исправляйте выбор DNS, а не маршрут до приложения.

Решит ли смена VPN-протокола проблему неправильного маршрута?

Нет. Протокол влияет на установление и транспорт соединения, а список маршрутов задается политикой VPN и клиентским профилем. Переход на IKEv2 или OpenVPN может устранить блокировку транспорта, но после смены нужно проверить и обновить профиль, маршруты и DNS.

Что делать, если домашняя и корпоративная сети используют одинаковую подсеть?

Сначала подтвердите конфликт по таблице маршрутизации и адресу целевого ресурса. Предпочтительный вариант, перенумеровать домашнюю или корпоративную сеть. Если это невозможно, используйте NAT на VPN-шлюзе, прокси, bastion-хост или отдельную схему доступа. Одна только смена метрики не гарантирует стабильный результат.

Итог: предсказуемая маршрутизация VPN без лишнего трафика

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

Результат подтверждается фактическими проверками: нужный IP выбирает VPN-интерфейс, локальное устройство доступно через домашний шлюз, внешний интернет использует согласованный путь, внутренние имена разрешаются через корпоративный DNS, а ACL и firewall пропускают только разрешенные порты.

Перед публикацией профиля проверьте Windows, Linux, macOS, iOS и Android отдельно. Храните версии конфигураций, тестируйте изменения в непроизводственной среде и держите готовый откат. Такой порядок снижает риск массового отказа удаленного доступа и помогает быстро найти причину, если VPN подключается, но сервис остается недоступным.