Раздельное туннелирование () — способ настройки виртуальной частной сети (VPN), при котором через туннель передаётся лишь часть трафика клиента. Остальные соединения используют маршрут через основной сетевой интерфейс. При полном туннелировании трафик по умолчанию направляется через VPN, хотя связь с самим VPN-сервером и некоторые служебные исключения остаются вне туннеля.
Трафик отбирают по сетевым адресам, доменным именам или приложениям. При split DNS выбор DNS-сервера зависит от запрашиваемого домена. Прямой выход в Интернет уменьшает нагрузку на корпоративный шлюз и сохраняет доступ к ресурсам локальной сети. Трафик не проходит через установленные за шлюзом средства фильтрации и мониторинга. Ошибка маршрутизации или подмена конфигурации может направить часть трафика в обход туннеля.
Принцип работы После установления VPN-соединения клиент создаёт виртуальный сетевой интерфейс. Клиент назначает интерфейсу адрес из внутренней сети и добавляет в таблицу маршруты через этот интерфейс. Пакеты, выбранные для передачи через VPN, инкапсулируются и отправляются VPN-шлюзу. Шлюз извлекает исходный пакет и пересылает его дальше во внутренней сети.
При раздельном туннелировании маршрут по умолчанию остаётся на основном интерфейсе, а при полном назначается виртуальному. В обоих случаях сохраняют отдельный маршрут к VPN-серверу, чтобы пакеты самого соединения не попадали в туннель повторно. Из нескольких подходящих записей выбирается маршрут с наиболее длинным префиксом. После отключения VPN клиент удаляет добавленные маршруты и восстанавливает исходную таблицу.
В IPsec трафик отбирается таблицей маршрутизации либо политикой безопасности, которая учитывает адреса, протокол и другие поля заголовка. Таблица маршрутизации и политика IPsec совместно определяют, будет ли пакет передан через туннель. VPN-шлюз и межсетевые экраны ограничивают доступ к сервисам, а средства аутентификации проверяют пользователя или устройство.
Варианты настройки Адресные правила задают сети и отдельные IP-адреса, которые должны проходить через туннель или, при полном туннелировании, исключаться из него.
Некоторые клиенты принимают вместо адреса полное доменное имя (FQDN). Клиент разрешает FQDN через DNS, создаёт маршруты к полученным IP-адресам и обновляет их при изменении ответа. Если несколько сайтов используют один IP-адрес, правило может затронуть соединения с другими сайтами на том же адресе. В документации Microsoft 365 отмечается, что маршрутизации только по FQDN недостаточно для всех соединений службы. Cisco Secure Client поддерживает совместное использование доменных и адресных правил.
Туннель также можно привязать к отдельному приложению. На мобильных устройствах VPN можно привязать к корпоративному приложению. Остальные приложения при этом работают через основное подключение. Шлюз разрешает этой программе доступ только к заданным сетям и службам.
DNS, IPv4 и IPv6 При split DNS запросы к внутренним доменам направляются корпоративному DNS-серверу через VPN, для остальных доменов используется DNS-сервер основного подключения. Такая схема применяется для частных зон и для доменов, которые внутри и вне организации имеют разные записи. После разрешения имени дальнейший путь пакетов определяется таблицей маршрутизации. Внутреннее доменное имя при этом может стать известно оператору внешнего DNS-сервера. Кроме того, полученный адрес может отсутствовать в таблице маршрутизации клиента. При этом корпоративный DNS-сервер не получает запросов пользователя к внешним доменам.
IPv4 и IPv6 используют разные таблицы маршрутов. Если VPN-клиент изменяет только маршруты IPv4, трафик IPv6 может пройти вне туннеля. В недоверенной сети злоумышленник может навязать клиенту маршрут IPv6 с помощью поддельного объявления маршрутизатора. RFC 7359 рекомендует настраивать маршрутизацию и фильтрацию и для IPv4, и для IPv6. Если VPN-клиент не передаёт IPv6 через туннель, документ допускает его временное отключение. В исследовании 14 коммерческих VPN-сервисов утечки IPv6 были обнаружены у большинства проверенных решений. Авторы той же работы показали атаку с подменой DNS, при которой трафик клиента перенаправлялся через узел атакующего.
Применение Раздельное туннелирование используют в системах удалённого доступа, где внутренние ресурсы нужны наряду с обычными интернет-службами. Локальный принтер или другое устройство домашней сети остаётся доступным без передачи пакетов через корпоративный VPN-шлюз. При полном туннелировании облачный трафик проходит через корпоративный шлюз и затем выходит в Интернет. Такой маршрут увеличивает нагрузку на корпоративный канал и задержку. Для Microsoft 365 рекомендуется прямая маршрутизация опубликованных диапазонов конечных точек категории «Оптимизация». Это снижает нагрузку на общий VPN-шлюз при массовой удалённой работе.
Во время пандемии COVID-19 Индианский университет обеспечил удалённый доступ примерно 130 тысячам сотрудников и студентов. Полное туннелирование потребовало бы дополнительных лицензий и большей пропускной способности. Оно также могло перегрузить VPN-инфраструктуру. Соединения с внутренними ресурсами шли через VPN, остальной трафик направлялся напрямую. Кроме того, университет разъяснял пользователям, в каких случаях подключение к VPN действительно требовалось.
Безопасность При раздельном туннелировании клиентское устройство остаётся подключённым к локальной или внешней сети и имеет маршруты к внутренним ресурсам. После компрометации оно может использоваться как промежуточный узел для атаки на сеть организации. Прямые соединения обходят корпоративные прокси-серверы, межсетевые экраны и системы мониторинга, если те размещены только за VPN-шлюзом. Шифрование отдельного соединения с помощью TLS защищает передаваемые в нём данные, но не распространяется на остальной трафик устройства.
Передача части трафика вне VPN сама по себе не является утечкой, если она задана политикой. Утечка возникает, если трафик, который должен идти через VPN, проходит в обход туннеля. К этому приводят ошибочные или изменённые маршруты, слишком широкие исключения, неполная настройка IPv6 и подмена DNS.
На USENIX Security 2023 исследователи представили две атаки, использовавшие служебные исключения для локальной сети и VPN-сервера. Злоумышленник манипулирует служебными исключениями через контролируемую точку доступа или через поддельный DNS-ответ. В обоих случаях часть соединений могла пройти в обход VPN. Исследователи провели 248 экспериментов с VPN-клиентами 67 провайдеров на Windows, macOS, iOS, Linux и Android. В выборку вошли и встроенные VPN-средства. В зависимости от атаки уязвимыми оказались 64,6 или 73,6 % клиентов. Атаки оставались возможны и при полном туннелировании, поскольку служебные маршруты сохранялись.
Для удалённого доступа по IPsec NIST SP 800-77 рекомендует отключать раздельное туннелирование. Отключение раздельного туннелирования не устраняет другие каналы связи, например второй сетевой интерфейс, и не защищает уже скомпрометированное устройство. NIST рекомендует централизованно управлять профилями VPN и проверять состояние клиентского устройства. Дополнительную защиту обеспечивают локальный межсетевой экран и фильтрация на VPN-шлюзе.
Для защиты можно ограничить адресные диапазоны, выведенные из туннеля, полностью запретить локальный трафик или разрешить только процессу VPN-клиента напрямую соединяться с VPN-сервером. Запрет локального трафика блокировал описанные атаки, но лишал пользователя доступа к устройствам своей сети. Ограничение исключённых диапазонов и привязка прямого соединения к процессу VPN-клиента сохраняли доступ к локальной сети, но не блокировали все способы обхода туннеля. Соответствие настроек политике проверяют по таблицам маршрутизации, журналам и захваченным пакетам. IPv4, IPv6 и DNS проверяют отдельно.
Примечания
Литература
Категория:VPN Категория:Маршрутизация Категория:Сетевая безопасность