Маршрутизация через VPN: как направить нужный трафик в туннель

Как направить нужный трафик через VPN

Чтобы отправить через VPN только выбранные сети, хосты или сервисы, настройте split tunneling. Этот режим добавляет в таблицу маршрутизации отдельные записи для нужных направлений, а маршрут по умолчанию оставляет без изменений. В результате трафик к корпоративной подсети идет в туннель, а остальной интернет работает напрямую. Проверьте результат командой ip route get или traceroute.

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

Full tunnel и split tunneling VPN

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

Плюсы split tunneling: контроль пути, меньшая задержка для обычного интернета, доступ к локальным устройствам. Риски: возможные DNS-утечки, сложность диагностики, необходимость поддерживать актуальные маршруты при изменении адресов.

Что именно можно направить в туннель

Маршрутизация работает на уровне IP. Можно направить в VPN:

• целую подсеть, например 10.20.0.0/16;
• один хост по IPv4 (/32) или IPv6 (/128);
• набор адресов сервиса, если известны все IP.

Маршрутизация по названию приложения или домену требует дополнительных механизмов: policy routing, firewall marks, прокси или маршрутизатора с поддержкой правил по доменам. Например, для отправки только трафика Telegram через VPN нужен policy-based routing на основе меток пакетов.

Как система выбирает маршрут

При отправке пакета система просматривает таблицу маршрутизации и выбирает запись с наиболее специфичным префиксом (longest prefix match). Например, маршрут 10.20.5.10/32 имеет приоритет над 10.20.0.0/16, а тот - над маршрутом по умолчанию 0.0.0.0/0. Метрика используется только при равной длине префикса. Если VPN-клиент добавляет маршрут по умолчанию, он перехватывает весь трафик, даже если вы планировали split tunneling.

Маршрут по умолчанию и специфичный маршрут

Рассмотрим пример: локальная сеть 192.168.1.0/24, VPN-подсеть 10.20.0.0/16. Если добавить маршрут 10.20.0.0/16 через VPN-интерфейс, а маршрут по умолчанию оставить на локальном шлюзе, то трафик к 10.20.x.x пойдет в туннель, а остальной - напрямую. Ошибка в маске, например указание 10.0.0.0/8, направит в VPN лишние адреса. Всегда проверяйте фактическую таблицу маршрутизации после подключения.

Локальная сеть, шлюз и VPN-интерфейс

После подключения VPN можно потерять доступ к роутеру, NAS или другим локальным ресурсам. Причина - маршрут по умолчанию через VPN или пересечение подсетей. Проверьте, что маршрут к локальной подсети (например, 192.168.1.0/24) более специфичен, чем VPN-маршрут, и что адрес физического шлюза доступен. Если локальная и удаленная сети используют одинаковые подсети, например обе 192.168.1.0/24, система выберет локальный интерфейс, и доступ к удаленной сети не будет работать. В таком случае нужно изменить адресный план одной из сторон или использовать NAT на стороне VPN.

Настройка маршрутизации WireGuard

В WireGuard маршрутизация клиента управляется параметром AllowedIPs в секции [Peer]. Этот параметр одновременно определяет, какие адреса разрешены для данного пира, и какие маршруты добавляются в таблицу. Для split tunneling укажите только нужные подсети или хосты.

WireGuard split tunneling через AllowedIPs

Пример конфигурации клиента для доступа только к подсети 10.20.0.0/16:

[Interface]
PrivateKey = ...
Address = 10.8.0.2/32

[Peer]
PublicKey = ...
Endpoint = vpn.example.com:51820
AllowedIPs = 10.20.0.0/16

Для одного хоста используйте /32: AllowedIPs = 10.20.5.10/32. Для нескольких направлений перечислите их через запятую: AllowedIPs = 10.20.0.0/16, 10.30.0.0/16. Добавление 0.0.0.0/0 превращает конфигурацию в full tunnel. Для IPv6 используйте ::/0 или конкретные префиксы, например fd00::/8.

Маршруты WireGuard на сервере

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

• IP-адреса туннеля на обоих концах;
• AllowedIPs пира на сервере должен включать адрес клиента;
• включен IP forwarding: sysctl net.ipv4.ip_forward=1;
• правила firewall разрешают форвардинг;
• если трафик должен выходить в интернет, настроен NAT (например, MASQUERADE в iptables).

Доступ к внутренней подсети требует, чтобы сервер имел маршрут к этой подсети и чтобы удаленные хосты имели обратный маршрут к туннельному адресу клиента.

Настройка маршрутизации OpenVPN

OpenVPN использует другую модель: маршруты могут задаваться сервером через директиву push или локально в конфигурации клиента через route. Для split tunneling обычно добавляют конкретные маршруты, не трогая маршрут по умолчанию.

OpenVPN split tunneling через route

Пример добавления маршрута к подсети 10.20.0.0/16 в конфигурации клиента:

route 10.20.0.0 255.255.0.0

По умолчанию шлюзом будет VPN-интерфейс. Можно указать явно: route 10.20.0.0 255.255.0.0 10.8.0.1. Для IPv6 используйте route-ipv6. Если сервер пушит маршруты, клиент может отключить их директивой route-nopull и задать свои.

Почему redirect-gateway меняет поведение трафика

Директива redirect-gateway в конфигурации сервера или клиента перенаправляет весь интернет-трафик через VPN, создавая full tunnel. Если вы хотите split tunneling, убедитесь, что эта директива отсутствует. Проверьте логи подключения: при получении push-сообщения с redirect-gateway клиент изменит маршрут по умолчанию. Для отмены на клиенте можно использовать route-nopull и добавить свои маршруты.

DNS при маршрутизации через VPN

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

Внутренние домены и DNS-сервер в туннеле

Для доступа к корпоративным сервисам по именам нужно, чтобы запросы к внутренним доменам отправлялись на DNS-сервер через VPN. Это реализуется через split DNS: например, в systemd-resolved можно задать домен и DNS-сервер для него. Убедитесь, что маршрут до DNS-сервера существует и порт 53 (UDP/TCP) доступен через туннель. Если используется DNS-over-TLS или HTTPS, проверьте соответствующие порты и сертификаты.

DNS-утечки при split tunneling

Проверьте, какие DNS-серверы фактически используются: nslookup example.com или dig покажут адрес сервера. Если запросы уходят на локальный DNS провайдера, а не на VPN-сервер, это утечка. Причины: несколько интерфейсов, параллельные запросы IPv4/IPv6, кэш. Для предотвращения утечек можно настроить firewall, блокирующий DNS-запросы вне VPN, или использовать DNS-клиент с политикой. Не полагайтесь только на параметр VPN.

Конфликты маршрутов и типовые ошибки

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

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

Если локальная и удаленная сети используют одинаковые адреса, например 192.168.1.0/24, система выберет локальный интерфейс из-за более короткого пути. Простое добавление маршрута не поможет, так как локальная сеть уже имеет маршрут с той же длиной префикса. Решения: изменить адресный план одной из сетей, использовать NAT на стороне VPN, применить policy routing или проксирование конкретного сервиса.

Маршрут установлен, но соединения нет

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

• состояние VPN-туннеля (handshake в WireGuard, статус в OpenVPN);
• маршрут до назначения: ip route get 10.20.5.10;
• доступность шлюза VPN: ping туннельного адреса;
• правила firewall на клиенте и сервере;
• форвардинг на сервере;
• обратный маршрут: удаленный хост должен знать, как вернуть пакет клиенту;
• MTU: при проблемах с большими пакетами проверьте фрагментацию.

Успешный ping не гарантирует работу TCP или HTTPS: проверяйте конкретный порт, например nc -zv 10.20.5.10 443.

IPv6, MTU и фрагментация

Если IPv4 работает, а часть сайтов или приложений зависает, проверьте IPv6-маршруты. Возможно, IPv6-трафик идет напрямую, а не через VPN. Убедитесь, что политика для IPv4 и IPv6 согласована. Проблемы с MTU вызывают зависание крупных передач: проверьте PMTU discovery и при необходимости уменьшите MTU на туннельном интерфейсе. Отключение IPv6 - временная диагностическая мера, а не решение.

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

Для подтверждения фактического пути пакета используйте команды уровня ОС. Ниже - чек-лист для Linux, Windows и маршрутизаторов.

Проверка таблицы маршрутизации

На Linux: ip route show и ip route get 10.20.5.10. На Windows: route print и tracert. Проверьте отдельно адрес VPN-сервера, удаленной подсети, локального ресурса и публичного адреса. Убедитесь, что для каждого направления выбран ожидаемый интерфейс.

Проверка DNS и трассировки

Сравните результаты dig example.com и traceroute 10.20.5.10. Если домен разрешается в неверный IP, проблема в DNS. Если IP правильный, но трассировка не доходит, проблема в маршрутизации или firewall. Проверьте TCP-порт: nc -zv 10.20.5.10 443.

Захват пакетов и логи VPN

Используйте tcpdump -i any host 10.20.5.10 или Wireshark, чтобы увидеть исходящий интерфейс и ответы. В логах WireGuard проверьте handshake и ошибки, в OpenVPN - сообщения о маршрутах. При публикации захватов удаляйте ключи, токены и чувствительные адреса.

Готовые схемы маршрутизации для типовых задач

Приведенные сценарии помогут выбрать минимально сложную конфигурацию.

Доступ к корпоративной подсети через VPN

Требуется доступ к подсети 10.20.0.0/16. Настройте split tunneling: добавьте маршрут к этой подсети через VPN, настройте внутренний DNS для корпоративных доменов. Публичный интернет остается на локальном шлюзе. Убедитесь, что сервер VPN имеет обратный маршрут к клиенту и правила доступа.

Только один сервер или сервис через VPN

Например, доступ к Git-серверу 10.20.5.10. Добавьте маршрут /32: AllowedIPs = 10.20.5.10/32 в WireGuard или route 10.20.5.10 255.255.255.255 в OpenVPN. Если сервис за CDN с меняющимися IP, используйте policy routing по домену или прокси.

Локальная сеть вне VPN, удаленная сеть внутри

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

Итоговый чек-лист настройки

1. Выберите режим: full tunnel или split tunnel.
2. Определите точные сети и хосты для туннелирования.
3. Добавьте маршруты в правильной системе (клиент или сервер).
4. Проверьте отсутствие пересечения подсетей.
5. Убедитесь, что сервер выполняет forwarding и имеет обратные маршруты.
6. Настройте DNS согласно политике.
7. Проверьте IPv4 и IPv6.
8. Подтвердите результаты таблицей маршрутов, трассировкой и захватом пакетов.

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