Раздельное туннелирование VPN: зачем делить трафик, если можно пустить все через туннель

Раздельное туннелирование, или split tunneling, решает проблему, которую многие пользователи VPN замечают только после первой поломки. Полный VPN заставляет весь трафик идти через удаленный сервер. Через тот же туннель внезапно идут рабочая CRM, YouTube, банк, обновления Windows, локальный принтер, игры, телеметрия приложений и запросы к домашнему NAS. Такая схема выглядит безопаснее в рекламе, но в реальной сети часто дает лишнюю задержку, капчи, сломанные локальные устройства и странные ошибки банковских приложений.

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

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

Как split tunneling работает внутри системы

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

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

default via 192.168.1.1 dev wlan0
 10.20.0.0/16 dev wg0
 172.16.5.0/24 dev wg0

В WireGuard ключевой параметр называется AllowedIPs. В бытовых гайдах его часто называют просто списком маршрутов, но такое объяснение неполное. WireGuard использует allowed IPs как cryptokey routing table. При отправке список помогает выбрать пира для назначения, при приеме список работает как фильтр: пакет от конкретного пира принимается только с разрешенным IP-источником.

[Interface]
 Address = 10.7.0.2/32
 PrivateKey = CLIENT_PRIVATE_KEY
 DNS = 10.7.0.1
 
 [Peer]
 PublicKey = SERVER_PUBLIC_KEY
 Endpoint = vpn.example.net:51820
 AllowedIPs = 10.20.0.0/16, 172.16.5.0/24
 PersistentKeepalive = 25

Если в WireGuard указать AllowedIPs = 0.0.0.0/0, ::/0, клиент попытается отправить весь IPv4 и IPv6 трафик через туннель. Если указать только 10.20.0.0/16, через туннель пойдет только этот диапазон. На Linux утилита wg-quick обычно сама добавляет маршруты из AllowedIPs. На других платформах поведение зависит от клиента, поэтому проверка таблицы маршрутов остается обязательной.

OpenVPN работает через push-маршруты и директивы клиента. Сервер может включить full tunnel, когда весь трафик клиента идет через VPN, или split tunnel, когда клиент получает только отдельные приватные подсети. В ручной конфигурации клиент может отказаться от маршрутов сервера через route-nopull и добавить только нужные сети.

client
 dev tun
 proto udp
 remote vpn.example.net 1194
 route-nopull
 route 10.20.0.0 255.255.0.0
 route 172.16.5.0 255.255.255.0

Windows тоже умеет раздельное туннелирование в штатном VPN-профиле. Через PowerShell включают split tunneling, а затем добавляют маршруты для нужных подсетей. Важная деталь: один флажок split tunneling не знает, где находится ваша интрасеть. Без маршрутов к рабочим сетям клиент просто перестанет гонять весь интернет через VPN, но не научится сам находить внутренние адреса.

Set-VpnConnection -Name "Work VPN" -SplitTunneling $true
 Add-VpnConnectionRoute -ConnectionName "Work VPN" -DestinationPrefix "10.20.0.0/16"

На Android split tunneling часто работает по приложениям. Разработчик VPN-клиента может создать allowed list, и тогда только выбранные приложения получат доступ к VPN. Или создать disallowed list, и тогда выбранные приложения пойдут мимо туннеля. Эти два режима нельзя смешивать в одной конфигурации. Для пользователя такой режим удобен, но не идеален: приложение может использовать системные push-службы, встроенный WebView, CDN, стороннюю аналитику и фоновые процессы.

На iOS картина строже. Обычный пользователь iPhone не получает свободный системный список «какие приложения гнать через VPN». Полноценный per-app VPN живет в корпоративном контуре: MDM, managed apps, AppLayerVPN, политики администратора. Для личного iPhone сторонний VPN обычно дает полный туннель, on-demand правила или отдельные исключения внутри клиента, но не такой же прозрачный контроль, как на Android или настольной системе.

Где функция реально помогает

Главный сценарий для бизнеса прост. Сотруднику нужен доступ к GitLab, Jira, RDP, SSH, внутренней базе или панели мониторинга. Нет смысла тащить через корпоративный VPN потоковое видео, личный браузинг, обновления ОС и звонки. Такой мусор забивает шлюз, повышает задержку и создает лишние журналы на стороне компании. Split tunneling снижает нагрузку и оставляет VPN для тех ресурсов, ради которых туннель вообще подняли.

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

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

На роутере split tunneling дает еще более грубый, но полезный контроль. Рабочий ноутбук можно отправить через WireGuard, телевизор и игровую консоль оставить напрямую, IoT-устройства не трогать, а гостевую сеть отделить отдельными правилами. Попытка гнать весь дом через один VPN часто заканчивается плохим пингом, проблемами с локальным обнаружением устройств и жалобами семьи на «сломанный интернет».

Где split tunneling ломает безопасность

Раздельное туннелирование не равно «почти полный VPN». Функция защищает только тот трафик, который попал в туннель. Все остальное идет напрямую и остается видимым в рамках обычной модели сети. Провайдер, владелец Wi-Fi или корпоративный прокси могут видеть метаданные прямых соединений. Если пользователь случайно оставил браузер вне VPN, сайт увидит обычный внешний IP.

Самая частая поломка связана с DNS. Приложение может идти через VPN, а DNS-запросы могут уходить на роутер провайдера. В результате HTTPS продолжит шифровать содержимое, но домены окажутся в чужих журналах. Для корпоративной сети проблема неприятнее: внутренние имена вроде gitlab.corp.local могут не резолвиться или резолвиться через неправильный сервер.

Нормальная корпоративная схема использует split DNS. Запросы к внутренней зоне идут на корпоративный DNS через туннель, публичные домены идут на обычный резолвер или доверенный публичный DNS. Такая схема требует аккуратной настройки search domains, DNS suffixes и правил клиента. Галочка «split tunnel» сама такую архитектуру не проектирует.

Вторая типичная проблема связана с одинаковыми подсетями. Домашний роутер часто использует 192.168.1.0/24. Офисная сеть тоже может использовать 192.168.1.0/24. Система выберет маршрут по длине префикса и метрике, а пользователь увидит хаос: то открывается домашний принтер, то офисный сервер, то ничего. Корпоративным сетям лучше не жить в популярных домашних диапазонах.

Третий риск важен для компаний. Если VPN добавляет маршрут к внутренней сети на весь ноутбук, любая программа на ноутбуке может попытаться достучаться до внутренних адресов. Вредоносному процессу не нужен отдельный VPN-клиент, если маршрут уже есть в системе. Поэтому split tunneling надо дополнять MFA, EDR, ACL, сегментацией, проверкой устройства и правилами доступа к конкретным сервисам. Маршрут не заменяет Zero Trust.

Четвертая ошибка связана с доменными правилами. Администратор хочет сказать «этот сайт через VPN, все остальное напрямую», но сайт живет за CDN, меняет IP, использует IPv6, тянет ресурсы с соседних доменов и вызывает API в облаке. Маршрутизация ОС работает по IP, а не по маркетинговому названию сервиса. Доменные правила удобны в корпоративных клиентах с собственным агентом, но ручная настройка быстро превращается в список, который никто не поддерживает.

Пятая ошибка касается kill switch. Kill switch полезен, когда туннель падает. Но при split tunneling часть трафика специально идет напрямую. Плохой kill switch либо рубит слишком много, либо оставляет утечки. Хорошая политика должна различать трафик, который обязан идти только через VPN, и трафик, которому разрешен прямой выход.

Как проверить настройку без самообмана

Проверять split tunneling надо по трем направлениям: внешний IP, маршруты и DNS. Интерфейс VPN-клиента может показывать красивый статус «защищено», но реальный путь пакетов виден только в системе.

# Windows
 Get-VpnConnection -Name "Work VPN"
 route print
 nslookup gitlab.corp.local
 tracert 10.20.15.10
 tracert 8.8.8.8
 
 # Linux
 ip route
 resolvectl status
 ip route get 10.20.15.10
 ip route get 8.8.8.8
 traceroute 10.20.15.10

Для WireGuard проверьте счетчики и маршруты. Если внутренний адрес открывается, а счетчики не растут, трафик идет не туда или проверяется не тот интерфейс.

wg show
 ip -br address
 ip route get 10.20.15.10

Для Android используйте два браузера. Один добавьте в список приложений, которые идут через VPN. Второй оставьте вне списка. Откройте страницу проверки IP в обоих браузерах. Адреса должны различаться, если один браузер идет через туннель, а второй напрямую. Затем проверьте банк, карты и локальные сервисы, которые должны обходить VPN.

Для Windows проверьте не только SplitTunneling, но и маршруты к конкретным подсетям. Частая ошибка выглядит так: пользователь включил split tunneling, но не добавил маршрут к офисной сети. В результате интернет идет напрямую, а корпоративные ресурсы не открываются.

Для роутера проверка сложнее. Сначала проверьте устройство, которое должно идти через VPN, затем устройство, которое должно идти напрямую. После этого проверьте локальные адреса: роутер, NAS, принтер, медиасервер. Если локальная сеть исчезла, VPN-клиент мог включить блокировку LAN, добавить слишком широкий маршрут или поднять firewall-правило с высоким приоритетом.

Мифы и честный вывод

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

Миф второй: split tunneling всегда дырявит защиту. На самом деле функцию дырявит плохая политика. Если через VPN идут только рабочие подсети, а личное видео идет напрямую, корпоративная инфраструктура получает меньше мусора и меньше нагрузки. Риск появляется, когда внутренние маршруты доступны всем процессам, DNS настроен кое-как, а пользователь не понимает, что ушло мимо туннеля.

Миф третий: per-app VPN всегда проще маршрутов. На смартфоне такой подход удобен. На рабочих станциях и серверах IP-префиксы часто надежнее, потому что администратор видит конкретные сети, таблицы маршрутизации и приоритеты. Приложение может менять домены и процессы, а подсеть остается понятной единицей контроля.

Миф четвертый: доменное раздельное туннелирование решает все. Для современных сервисов домен редко равен одному адресу. CDN, IPv6, DoH, push-службы и сторонние API ломают простую картину. Если нужна надежность, стройте правила вокруг IP-префиксов, корпоративного агента или управляемой платформы, а не вокруг случайного списка доменов из браузера.

Хороший split tunneling начинается с карты трафика. Нужно прямо ответить, какие приложения и подсети должны идти через VPN, какие должны идти напрямую, какие DNS-серверы отвечают за внутренние зоны и кто получит доступ к внутренним маршрутам. Без таких ответов раздельное туннелирование превращается в красивую галочку, которая дает пользователю скорость, а администратору новые слепые зоны.

Для личного ноутбука разумная схема проста: рабочие или чувствительные приложения через VPN, банк и локальная сеть напрямую, DNS под контролем. Для компании схема строже: только нужные корпоративные сети через туннель, доступ по пользователю и устройству, журналы, EDR, MFA и сегментация. Split tunneling недооценивают потому, что функция выглядит скучно. Но именно скучная маршрутизация часто решает больше реальных проблем, чем очередной «самый быстрый VPN-протокол» в рекламном баннере.