VPN не пускает трафик? Разбираем маршрутизацию, метрики и конфликты по косточкам

Бывало такое, что подключились к VPN, а интернет будто ушел в отпуск без предупреждения? Или часть внутренних ресурсов работает, а другая часть упрямо молчит, как будто вы для нее призрак. Мы там были. Мы знаем эту боль. Маршрутизация через VPN — тонкая материя. Чуть не так настроил метрику маршрута или шлюз по умолчанию, и трафик побежал не туда. Где-то пропал обратный маршрут. Где-то DNS посмотрел не в ту сторону. А где-то MTU решил сыграть злую шутку и обрезал пакеты, как кулинар на мастер-классе. Но паниковать не будем. Спокойно, последовательно, с чеком в руках — разберем все по шагам.

В 2026 году VPN — это уже не просто «поднял туннель и забыл». Мы живем в эпоху Zero Trust, SASE, ZTNA и тонны гибридных сценариев: облака, филиалы, удаленка, мобильные сети, и все это вместе. На столе одновременно лежат WireGuard, IKEv2/IPsec, SSL-VPN поверх QUIC и даже туннели поверх прокси и HTTP/3. И да, у вас часто одновременно включены DoH, корпоративные DNS через split-horizon, IPv6-only сегменты с NAT64/DNS64 и ещё парочка политик, которые бьются за право первой ночи над вашим трафиком. Обидно? Зато интересно.

Эта статья — практический гид. Никакой сухой теории ради теории. Мы разберем конкретные конфликты маршрутов, поймем, как работают метрики и приоритеты на Windows, Linux и macOS, посмотрим, где рушатся шлюзы и почему трафик становится «односторонним», настроим split tunneling так, чтобы не болела голова, и научимся делать стабильную диагностику. Будут живые кейсы, полезные команды, чек-листы и подсказки по автоматизации. А в конце — FAQ, который стоит сохранить в закладки. Поехали?

Как работает маршрутизация в VPN и где чаще всего ломается логика

Таблица маршрутов: главный сценарист вашего трафика

Когда мы подключаем VPN, в систему попадают новые маршруты. У каждого маршрута есть сеть назначения, маска (или префикс), следующий прыжок (шлюз), интерфейс и метрика. Правило приоритета простое: сначала совпадение по самому длинному префиксу, затем сравнение метрик. Чем короче путь и ниже метрика, тем охотнее система выберет этот маршрут. И да, иногда клиент VPN может добавлять «широкие» маршруты (например, 0.0.0.0/0) и тем самым перетягивать на себя весь трафик. И если при этом не настроены исключения, интернет исчезает, как в фокусе. Звучит банально, но именно с этого и стоит начинать разбор.

Еще один нюанс — порядок интерфейсов и автоматические метрики. На Windows и macOS система любит «соображать за нас», выставляя auto-metric на основе скорости интерфейса. Подключили VPN поверх Wi-Fi, а рядом есть Ethernet? Могут возникнуть сюрпризы. В Linux своя история: при наличии policy-based routing (PBR) и нескольких таблиц маршрутов вы можете видеть один маршрут в основной таблице и совсем другой в политике, которая перехватывает нужный трафик. Результат — разные пути для разных пакетов, хотя на первый взгляд «все на месте».

Типичные конфликты: пересечение подсетей, дубли и черные дыры

Классика жанра — пересекающиеся RFC1918 сети: у нас внутри компании 10.0.0.0/8, а у сотрудника дома роутер выдал ему 10.0.0.0/24. Или, что ещё веселее, внутри VPN используются несколько перекрывающихся подсетей, «подсосанных» BGP-агрегацией. В итоге маршрут к нужной подсети может перекрываться более общим объявлением, и вы получите выбор не в пользу требуемого пути. Видите 10.20.0.0/16 и 10.20.5.0/24, но метрика для /16 ниже? Тогда трафик уйдет не туда, и начнется охота на «черные дыры».

Другая частая проблема — дублирование маршрутов одним и тем же клиентом VPN: например, OpenVPN может «притянуть» и 0.0.0.0/1, и 128.0.0.0/1 (так реализуют full tunnel), а параллельно кто-то уже прописал дефолт. Система выберет один, но контроль обратного трафика может потеряться. Третий сценарий — маршруты на внутренние ресурсы добавлены, а обратного маршрута на сервере нет. Пакет улетел внутрь, а ответ ушел «окольной тропой» к провайдеру, где его благополучно отбросили. Получается асимметрия: с клиента пинги есть, а с сервера — тишина.

Клиент и сервер VPN: кто и когда рулит маршрутами

Разные клиенты ведут себя по-разному. WireGuard опирается на AllowedIPs: это и фильтр, и маршрутизатор. Добавили 0.0.0.0/0 — получили полный туннель; оставили узкие префиксы — split. OpenVPN часто использует опции redirect-gateway def1, route-nopull, а также push-строки от сервера для добавления нужных путей. В IKEv2/IPsec используются селекторы трафика и политики, а при взаимодействии с BGP вы можете динамически объявлять префиксы. Сервер, в свою очередь, может навязать клиенту те или иные маршруты, а может делегировать это дело локальной машине.

В больших инфраструктурах серверы VPN взаимодействуют с SD-WAN, PBR и firewall-политиками. Маршруты к сегментам приходят через BGP или статически, а клиентам раздаются только нужные участки. Важно понимать, кто «главный» в конкретной топологии: клиент, который решает сам, куда слать трафик, или сервер/контроллер, который диктует правила. От этого зависит, где искать корень проблемы. Иногда проще поменять поведение клиента (например, отключить auto-metric и задать явные параметры), чем пытаться «ломать» политику сервера.

Базовая диагностика: что проверить в первую очередь

Сетевые пробы: ping, traceroute, MTR и проверка DNS

Начинайте с простого. Пинги по IP к внутреннему ресурсу: если идут — значит базовая связность есть. Пинг по имени — проверяет DNS. Если по IP проходит, а по имени нет — ищем проблему в резолвере, split-horizon или порядке DNS-серверов. Traceroute или tracepath (в Linux) покажет, через какой интерфейс и куда фактически уходит трафик. MTR пригодится для длинных трасс и нестабильных маршрутов: одновременно видите задержки и потери.

Проверьте, куда уходит интернет-трафик. Попробуйте traceroute до 8.8.8.8 или другого публичного адреса. Если после подключения VPN маршрут ломается и первый хоп — это адрес внутри туннеля, логично: у вас full tunnel. Но если полного туннеля нет, а интернет все равно «пропал», возможно, вы столкнулись с DNS-проблемой или MTU. Простая проверка: загрузите маленькую, потом побольше страницу. Стабильно зависает на «тяжелых» ресурсах? Запоминаем: может быть MTU или блокировка PMTUD.

Таблицы маршрутов: Windows, Linux, macOS — ищем несостыковки

На Windows используйте route print и Get-NetRoute, а при необходимости — Get-NetIPInterface, чтобы увидеть метрики интерфейсов. Сравните, кто владеет 0.0.0.0/0, какие есть более специфичные маршруты и какие метрики выставлены для VPN-интерфейса и локальной сети. Иногда достаточно отключить автоматическую метрику и руками поставить приоритет, чтобы трафик «встал в колею». Проверяйте также таблицы для IPv6: route print -6 и Get-NetRoute -AddressFamily IPv6.

В Linux смотрим ip route show, ip -6 route, а если есть подозрение на PBR — ip rule list и содержимое нескольких таблиц (ip route show table 100 и т. п.). Обратите внимание на приоритеты правил и mark-политики. Иногда приложение ставит fwmark, и трафик уходит не по тому пути. На macOS используйте netstat -rn, route -n get <адрес>, а также networksetup -listallnetworkservices и scutil --dns, чтобы понять порядок резолверов и текущий приоритет интерфейсов. Часто проблема в том, что интерфейс VPN добавлен, но «приоритет сервиса» не обновился, и система упрямо выбрала Wi-Fi.

Захват пакетов: Wireshark, tcpdump и системные инструменты

Когда таблица маршрутов не дает явного ответа, включаем сниффер. На Linux: tcpdump -i wg0 host нужный_адрес или tcpdump -i any port 53 для DNS. Смотрите, куда реально летит трафик, есть ли ответы, и как меняется TTL по дороге. На Windows в 2026 все чаще используют pktmon и классический Проводник событий, но Wireshark по-прежнему король: фильтруйте по интерфейсу VPN и адресу назначения. Если видите SYN, но нет SYN-ACK, проверьте обратный маршрут и firewall.

Еще один совет — проверьте PMTUD: включите df-bit и попробуйте крупные пакеты. Если застревают на середине трассы, возможно, где-то блокируют ICMP Fragmentation Needed. Диагностика DNS-путаницы важна отдельно: scutil --dns на macOS покажет, какие домены привязаны к какому резолверу, а в Linux resolvectl status даст понимание, какой сервер действительно используется. Иногда достаточно подшаманить порядок резолверов или добавить условный форвардинг для внутренних доменов, чтобы магия случилась.

Метрики и приоритеты: как они работают на Windows, Linux и macOS

Windows: auto-metric, InterfaceMetric и RouteMetric

В Windows автоприоритет часто щедрый, но не всегда умный. Интерфейс с большей скоростью может получить меньшую метрику, и система «решит», что он важнее. У VPN-интерфейса скорость виртуальная, метрика — странная. Поэтому практикуется отключение автоматической метрики для VPN-интерфейса и явная установка InterfaceMetric (например, 5 или 15, в зависимости от дизайна). Далее контролируем RouteMetric для конкретных маршрутов: чем меньше число, тем выше вероятность, что именно этот маршрут возьмут.

Проверяйте через Get-NetIPInterface и Set-NetIPInterface -InterfaceMetric. Для маршрутов — New-NetRoute или Set-NetRoute с RouteMetric. Если клиент VPN пушит дефолт, но вам нужен split, используйте политики клиента: например, route-nopull в OpenVPN и явные route add для подсетей. В Always On VPN и современных клиентах корпораций можно настроить включающие/исключающие правила, чтобы не ломать интернет и доставлять только нужные префиксы через туннель.

Linux: приоритеты, policy-based routing и несколько таблиц

В Linux метрика в ip route — лишь часть истории. При наличии ip rule у вас появится несколько таблиц маршрутизации, и порядок правил (priority) определит, какая таблица обработает пакет. Это мощно и опасно: можно сделать хитрые правила (по источнику, по fwmark, по TOS), но легко перестараться и отправить приложение в «изолированный мир». Если клиент VPN добавляет таблицу и правило с высоким приоритетом, весь трафик может уйти в туннель, даже если основной дефолт должен вести в интернет.

Практический рецепт: ip rule list, затем ip route show table main и другие таблицы, которые упоминаются. Проверьте, что правила не конфликтуют и что таблица VPN содержит обратные пути. Для IPv6 аналогично: ip -6 rule. Если работаете с WireGuard, обратите внимание, что AllowedIPs не только фильтруют, но и устанавливают маршруты. Разбейте AllowedIPs на точные префиксы, если нужен split. В iptables/nftables используйте метки и таблицы, но документируйте порядок — иначе через месяц никто не вспомнит, почему браузер ходит через один путь, а curl через другой.

macOS: порядок сервисов, ifscope и приоритеты резолвера

На macOS маршрут зависит от service order: какие сетевые службы выше, те и выигрывают. Это настраивается через интерфейс или networksetup. Плюс маршруты могут быть привязаны к ifscope, когда система явно выбирает интерфейс для конкретного назначения. Для диагностики route -n get <адрес> показывает, какой интерфейс и gateway выбраны. Если VPN должен быть «главным» для определенных подсетей, поднимите его выше в порядке и задайте точные маршруты.

DNS на macOS заслуживает отдельного внимания: scutil --dns показывает split-сценарии, где внутренние домены резолвятся через корпоративный DNS, а остальное — через публичный. Если порядок нарушен, получите загадочные ошибки: по IP доступ есть, по имени — нет. Лечится настройкой поисковых доменов, переупорядочиванием резолверов и четким определением, какой интерфейс отвечает за какой домен. В 2026 многие клиенты корпоративного VPN для macOS научились автоматически прописывать пер-доменные правила, но проверять руками все равно полезно.

Шлюзы, NAT и асимметричная маршрутизация

Шлюз по умолчанию: захват дефолта и kill switch

Когда VPN перехватывает 0.0.0.0/0, это ожидаемо для full tunnel. Но бывают «креативные» реализации: вместо одного дефолта клиент добавляет 0.0.0.0/1 и 128.0.0.0/1, обрезая мир на две половины и направляя обе через туннель. Ловко и совместимо. Риск появляется, когда локальный дефолт не отключен и выбирается то один, то другой маршрут в зависимости от метрики. Результат — хаотичный интернет. В таких случаях лучше явно задать приоритеты или включить kill switch, который блокирует выходной трафик вне VPN. Но помните: kill switch может стать причиной «пропажи интернета», если туннель упал.

Двойные шлюзы и multi-WAN добавляют перчинки: если у вас два провайдера и один VPN, обратный путь может возвращаться через «не тот» выход. На маршрутизаторе это решается policy routing и метками, на хосте — аккуратной конфигурацией метрик и симметрией. Главное — обеспечить, чтобы с какой стороны пакет вошел, туда же он и вышел. Иначе stateful firewall резонно отбросит «чужие» ответы. В логах вы увидите странные записи и недоумение: «почему же работает пинг, а приложение нет?»

NAT-T, hairpin и симметрия возврата

IPsec поверх NAT (NAT-T) давно стал нормой. Но если у клиента за спиной carrier-grade NAT, а на сервере стоит строгий firewall, иногда требуется дополнительная «поддержка жизни» с обеих сторон: поддержание keepalive, правильная фиксация исходящих портов и щадящие таймауты. Hairpin NAT (когда ходим на внутренний сервис по внешнему адресу) часто ломается в связке с VPN: клиент идет в туннель, сервер отвечает наружу, и обратный путь теряется. Рецепт — локальные записи DNS для внутренних доменов и отказ от hairpin там, где он не нужен.

ECMP и балансировка по нескольким линкам могут давать асимметрию: разные пакеты одного потока идут разными путями. Внутренние firewall-ы иногда не любят такую «жизнь на грани» и режут соединение. Если VPN-трафик идет через нескольких провайдеров, включите stickiness по источнику или 5-tuple, и обязательно проверьте, что обратные маршруты в ту же сторону. Симметрия — залог здоровья TCP, особенно если в пути есть инспекция.

Односторонний трафик: rp_filter, обратные маршруты и межсетевые экраны

В Linux rp_filter по умолчанию может отбросить пакеты, если предполагаемый обратный маршрут не совпадает с фактическим. При сложных PBR это бывает больно: запрос ушел по таблице 100 через VPN, а ответ планируется по main в интернет — ядро режет. Решение — настроить rp_filter в loose-режиме или выстроить симметрию. На хостах Windows и macOS тоже есть механизмы защиты от spoofing, и firewall может сбрасывать подозрительные потоки, если видит «несостыковку» пути.

Проверяйте межсетевые экраны и инспекцию приложений: SSL-VPN, прокси поверх 443, DPI — все это может вмешиваться в трафик и неожиданно резать нестандартные фрагменты. Иногда достаточно на время выключить «умную» инспекцию и проверить, исчезла ли проблема. Если исчезла — значит, надо корректно описать исключения для VPN-трафика, а затем вернуть инспекцию с более точными правилами.

Split tunneling vs Full tunnel: как выбрать и настроить без боли

Когда split tunneling — ваш лучший друг

Split tunneling экономит пропускную способность, снижает задержки к публичным сервисам и разгружает концентраторы VPN. В 2026 это особенно важно: видеоконференции, CDN, SaaS — все хотят местный «breakout». Простой пример: через VPN идут только адреса 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 и внутренние домены, а остальной интернет — напрямую. Пользователи рады, администраторы — тоже, если правильно настроены маршруты и DNS. Риск? Контроль над внешним трафиком слабее, нужно думать о DLP и уметь фильтровать локально.

Правильный split — это точные префиксы и корректный DNS. Настройте условный форвардинг доменов, чтобы внутренние имена не «гуляли» по публичным резолверам. В WireGuard — аккуратно выпишите AllowedIPs. В OpenVPN — отключите redirect-gateway и пушьте точные маршруты. В IKEv2 — корректно определите селекторы и списки включений. Подумайте о исключениях для сайтов банков, госуслуг и требовательных сервисов, если по корпоративной политике они должны идти через туннель или наоборот — всегда локально.

Когда full tunnel — это правильно и безопасно

Full tunnel нужен там, где compliance и безопасность важнее скорости: критичные данные, жесткие регуляции, строгие контуры. Вы перехватываете весь трафик через VPN, включаете фильтрацию и инспекцию на периметре, получаете централизованный контроль. Это дорожка без сюрпризов, если мощности хватает и MTU настроен правильно. Зато не будет DNS-утечек и конфликтов с локальными политиками. В 2026 многие SSL-VPN уже идут поверх QUIC и держат достойную скорость даже при full tunnel.

Минусы — рост нагрузки на концентраторы и потенциальный рост задержек. Компромиссный подход — «умный full»: весь трафик идет в туннель, но на стороне шлюза включен local breakout для категорий вроде видео и CDN. Или SASE-архитектура: клиенты тянутся к ближайшей точке присутствия, и там же применяются политики. Важно заранее планировать емкость и держать наготове метрики: если туннель «забит», пользователи почувствуют это очень быстро.

Шаблоны дизайна: include и exclude списки, DNS split и PAC

Четко определите включающие и исключающие списки. Include-списки удобны для split: вы заранее знаете, какие сети идут через VPN. Exclude — для full, когда вырезаете «шумные» категории. Для DNS используйте split-horizon: внутренние домены резолвятся корпоративным DNS, остальное — публичными серверами, желательно с DoH/DoQ, если политика разрешает. Отдельный трюк — PAC-файлы для прокси, чтобы веб-приложения шли нужным путем даже при смешанных сценариях.

Документируйте эти решения в виде плейбуков: «если нужно добавить новый SaaS — правила такие; если появилось новое VPC — добавляем такой префикс и проверяем обратный маршрут». Сэкономите часы в будущем. И да, добавьте тесты: небольшой набор curl, dig и traceroute, который прогоняется автоматически после изменения конфигурации — это та самая страховка, которая окупится в первую же аварию.

Практические кейсы: домашние роутеры, облака и удаленка

RFC1918-конфликты: когда у всех 10.0.0.0/8 и никто не виноват

Сотрудник подключается из дома, у него локальная сеть 10.0.0.0/24. Внутри компании используется 10.0.0.0/8. В таблице маршрутов есть и специфичный 10.10.20.0/24 через VPN, и общий 10.0.0.0/8 через локальный шлюз. Если метрика общему маршруту ниже — победит он, и пакеты уйдут мимо туннеля. Диагностика простая: route print или ip route, затем пинги по внутренним IP. Лечение: либо поднять метрику локального маршрута, либо ввести более специфичные префиксы в VPN, либо, как крайность, использовать NAT на концах, чтобы избегать пересечений.

Долгосрочно лучше отказаться от «колхозного» 10.0.0.0/8 в пользу аккуратной адресации и сегментации. В 2026 многие переезжают на четко выделенные блоки и документируют их в едином хранилище. Если миграция небыстрая, используйте policy routing и SNAT на шлюзе: трафик к «проблемным» подсетям принудительно через VPN, остальное — локально. И не забывайте про обратные маршруты: серверы должны знать, как отвечать клиентам, которые приходят с нестандартных адресов.

Облака: AWS, Azure, GCP — P2S, BGP и маршруты между VPC

Классический головняк — разная адресация в нескольких облаках. Между VPC/VNet есть пиринги, транзитные хабы, firewall-ы, и в эту красоту вы добавляете P2S VPN для сотрудников. Если маршруты не аккуратно анонсированы, часть подсетей будет «невидима» с клиента. Решение — централизованный контроль маршрутов: используйте BGP там, где возможно, или статический экспорт префиксов из облака в VPN-концентраторы с четкими фильтрами. И да, следите за приоритетами на клиенте: если клиент получил дефолт через VPN, убедитесь, что обратный путь из облака тоже идет через этот же концентратор.

Еще один кейс — пересекающиеся CIDR между облаками. Тут либо переадресация со временем, либо временный NAT. В критичных сценариях включите трассировку на каждом прыжке: от клиента до VPC и назад. MTR до внутреннего IP в облаке, затем tcpdump на интерфейсе туннеля и на облачном firewall, чтобы поймать потерю. Когда у вас есть полная картина, решение приходит само: скорректировать анонсы, изменить метрику или починить обратный маршрут.

Мобильные и «IPv6-only» сети: NAT64, DNS64 и CGNAT

Мобильные провайдеры часто дают только IPv6 и прокладывают NAT64/DNS64, чтобы «выходить» в мир IPv4. Подключение к VPN поверх такого стека работает, но есть нюансы. Если ваш VPN не заботится о IPv6, трафик может пойти в обход туннеля по v6, а часть сервисов начнет вести себя странно. Решение — полноценная поддержка IPv6 в VPN: добавьте префиксы, проверьте маршруты и включите фильтры. И, конечно, настройте DNS так, чтобы внутренние IPv4-ресурсы резолвились корректно даже при наличии DNS64.

CGNAT за спиной клиента ломает некоторые туннели, если у них агрессивные таймауты и нет keepalive. В WireGuard поставьте PersistentKeepalive, в IKEv2 гляньте на DPDP/DPD и lifetimes. Если VPN умеет QUIC поверх 443 — попробуйте, часто он проходит лучше. А если приложение работает по имени, но не по IP, проверьте split DNS: возможен неверный ответ резолвера вне VPN, хотя через корпоративный DNS все ок. Тонкость, но встречается часто.

Инструменты 2026: observability, телеметрия и новые фишки

eBPF и потоковая телеметрия: видим трафик целиком

В 2026 eBPF стал мейнстримом не только в кластерах, но и на рабочих станциях. С его помощью можно видеть, какой процесс создал сокет, какой маршрут выбран, и где пакет потерялся. Инструменты вроде Cilium Hubble для серверов и легкие агенты на хостах помогают ловить сложные случаи PBR и асимметрии. Чем это полезно нам? Мы наконец-то видим, что именно браузер повел трафик через VPN, а утилита обновления — прямо в интернет, потому что fwmark и таблица 200 перехватили поток.

На Windows развивается pktmon и интеграция с сетевыми журналами. На macOS появились более удобные профили пер-приложений, а на Linux bpftrace-скрипты помогают быстро подсветить «кто куда». Добавьте к этому централизованные дашборды: задержки в туннеле, MTU-ошибки, доля трафика через split/full, топ доменов. Когда визуализация есть, разговоры «у меня не работает» быстро превращаются в конкретику: «вчера в 11:42 у 30% клиентов упал PMTUD на линке к Дальнему Востоку».

Синтетические тесты и health checks: не ждем, пока загорится

Ставьте синтетические пробы: пинг до ключевых подсетей, HTTPS до внутренних порталов, DNS-запросы к нужным зонам, и все это — из разных точек и под разными политиками. Пускай тесты крутятся раз в минуту и бьют тревогу при первых же аномалиях. На клиенте — легкий агент, у которого есть список хостов и назначения. На стороне концентраторов — health check API, где видно состояние туннелей, время пересоздания и ошибки аутентификации. Грамотно настроенные алерты экономят нервы и время.

Дополнительно введите «канареечные» маршруты: несколько тестовых клиентов получают конфигурацию раньше остальных. Если что-то сломается — пострадают не все. Это стандартная практика из DevOps, и в сетях она работает не хуже. Добавьте журнал изменений, подпишите, кто и когда обновлял списки префиксов, и сделайте откат в один клик. Прозрачность — это не роскошь, это метод защиты от человеческого фактора.

Умная помощь и подсказки: от LLM до советников в клиентах VPN

Не все любят «ИИ во всем», но в реальной жизни он помогает. Консольный помощник, который на основе вывода ip route и traceroute подсказывает, где конфликт метрик — спасение в три часа ночи. Локально, без внешних вызовов. К примеру, помощник смотрит: у вас есть 10.20.0.0/16 и 10.20.5.0/24, у /16 метрика ниже — значит, стоит поднять метрику или добавить более специфичный маршрут. Или: видим, что DNS-резолвер для internal.corp направлен на публичный сервер — стоит прописать условный форвардинг на корпоративный.

Многие клиенты VPN в 2026 уже умеют встроенные проверки: автоматическая диагностика MTU, тест DNS leakage, валидация split-списков перед применением. Если клиент ругается — слушайте его. Эти проверки часто ловят то, что мы бы обнаружили только на проде, после жалоб. И да, включайте подробные логи. Когда лог молчит, мы все гадаем. Когда лог говорит, у нас появляются факты.

Безопасность, производительность и тонкая настройка

MTU, MSS clamping и черные дыры PMTUD

Слишком большой MTU в туннеле — верный путь к странным подвисаниям. Страница открывается наполовину, а потом — стоп. Решение — правильно подобрать MTU и включить MSS clamping для TCP. На Linux это правило в nftables/iptables: уменьшить MSS до безопасного значения (например, 1360-1380 для большинства UDP-туннелей). Проверьте PMTUD: если ICMP блокируют по пути, «умный» механизм не сработает. Иногда помогает жесткая фиксация MSS, иногда — включение ICMP на межсетевых экранах. Делайте A/B-тесты: до и после. Разница обычно очевидна.

В сетях с QUIC и HTTP/3 поверх 443 MTU-чувствительность другая, но проблема никуда не делась. Когда туннель работает поверх UDP, утрата фрагментов и блокировка больших дейтаграмм приведут к деградации. Простая эвристика — начать с консервативного MTU и поднимать его по мере необходимости, а не наоборот. И обязательно фиксируйте настройки в плейбуке, чтобы завтра не «забыть, какое число сработало».

DNS: split-horizon, DoH/DoQ и порядок резолверов

DNS может как сделать день, так и испортить неделю. Если внутренние домены идут к публичным резолверам — получите NXDOMAIN или, что хуже, неверные ответы. Используйте split-horizon: корпоративные зоны — через корпоративные резолверы, остальное — через публичные, желательно с DoH/DoQ при необходимости. На Windows проверьте порядок интерфейсных DNS, на macOS — scutil --dns, на Linux — resolvectl. Если VPN-клиент может «приписать» домены к нужным резолверам — включайте эту опцию.

Борьба с DNS leakage в 2026 стала стандартом. Многие клиенты умеют проверять, куда реально ушел запрос. Периодически запускайте тесты: запросы к внутренним зонам должны идти через туннель, публичные — как задумано политикой. И не забывайте о кешах: иногда они скрывают проблему. Чистка кеша и повтор запроса — простой и полезный шаг.

IPv6-first, ULA и «счастливые глаза» Happy Eyeballs

IPv6 больше не «гость на празднике», он хозяин. Если ваш VPN игнорирует v6, вы получите «обход» политики и непредсказуемое поведение. Добавьте маршруты для ULA-префиксов и глобальных IPv6-сетей, убедитесь, что фильтры разрешают нужные порты и протоколы. Проверьте Happy Eyeballs: приложения выбирают v4 или v6 по задержке. Если v6 идет вне туннеля, а v4 — в туннель, будет разнобой. Решение — единая стратегия: либо оба стека через VPN, либо четкий split с контролем DNS и маршрутов.

В IPv6 мир нет NAT в привычном виде, а значит, проблемы с асимметрией виднее. Настраивайте обратные маршруты тщательно. И помните, что крупные MTU в v6 — плюсы, но только если PMTUD жив и здоров. В противном случае вы снова вернетесь к симптомам «страница грузится и зависает». Не дайте этому случиться, держите контрольный список под рукой.

Чек-листы, плейбуки и автоматизация

Чек-лист «не паникуем»: быстрые шаги за 10 минут

Первое: проверяем связь по IP и по имени. Второе: traceroute до внутреннего и внешнего адреса. Третье: смотрим таблицу маршрутов и метрики интерфейсов. Четвертое: проверяем DNS-резолверы и split. Пятое: смотрим MTU и пробуем уменьшить MSS. Шестое: ловим пакеты на интерфейсе VPN и локальном. Седьмое: проверяем обратный маршрут с сервера. Восьмое: временно отключаем «умную» инспекцию и проверяем поведение. Девятое: сверяем конфигурацию клиента и сервера VPN. Десятое: документируем найденное и фиксируем.

Этот чек-лист кажется простым, но он экономит часы. Делайте его по порядку, не прыгайте. Иногда решение на пункте два, а иногда — на пункте девять. Главное — не терять нить и записывать результаты. Через месяц вы будете благодарить себя прошлого за эти записи, поверьте.

Плейбуки для Windows, Linux и macOS

Windows: отключаем auto-metric на VPN-интерфейсе, задаем InterfaceMetric вручную, проверяем RouteMetric для конфликтных подсетей. Диагностика через route print и PowerShell. DNS — приоритет интерфейса и правильный резолвер для внутренних доменов. Linux: смотрим ip rule и таблицы, упорядочиваем приоритеты, настраиваем fwmark, если нужно. WireGuard — аккуратно с AllowedIPs. Настройка MSS clamping и проверка PMTUD. macOS: порядок сервисов networksetup, scutil --dns для резолвера, route -n get для выбора интерфейса. Везде — логи клиентов VPN и сниффер.

Не забывайте о шаблонах изменений: YAML-файлы с перечнем подсетей, метрик, DNS-доменов и правил. Храните в Git, делайте ревью, проверяйте на канарейках. При проблеме откат — один коммит. Это уже стандарт практики, и он прекрасно работает для сетей. Автоматизация не заменит мозги, но освободит их для задач, где они действительно нужны.

GitOps для маршрутов: проверяем и применяем безопасно

Инфраструктура как код добралась и до маршрутизации. Пусть список префиксов и исключений хранится в репозитории. Открываете Pull Request — автоматически запускаются синтетические тесты в тестовой среде, а затем — в канареечной группе. Если все ок, изменения раскатываются на всех клиентов или на серверы VPN. Если нет — откат и разбор. Никаких «забыли обновить у Пети, а у Маши все работает». Прозрачно и повторяемо.

Добавьте статические проверки: валидатор CIDR, запрет пересекающихся префиксов без явного флага, проверка, что новые маршруты не «съедят» интернет пользователю. И конечно, журнал «кто утвердил». Так вы превращаете хаос в управляемый процесс. А пользователи перестают быть бета-тестерами изменений в проде.

FAQ: короткие ответы на частые вопросы

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

Чаще всего клиент VPN перехватил маршрут по умолчанию (full tunnel), а обратный путь к интернету не настроен или заблокирован kill switch. Проверьте таблицу маршрутов: есть ли 0.0.0.0/0, 0.0.0.0/1 и 128.0.0.0/1, какие у них метрики. Прогоните traceroute до публичного IP: если первый хоп — адрес в туннеле, то интернет должен идти через VPN. Если не идет — смотрите DNS (возможно, резолвер указывает на внутренние серверы, которые извне недоступны), либо MTU (крупные пакеты застревают). Быстрый тест: уменьшите MSS, временно поставьте публичный DNS, проверьте, не активирован ли строгий kill switch, и восстановите симметрию маршрутов.

Как исправить конфликт одинаковых подсетей у клиента и в компании?

Три пути: 1) переадресация в компании (надежно, но долго), 2) временный NAT для конфликтующей подсети на границе VPN (быстро, но добавляет сложность), 3) policy-based routing с явными маршрутами к нужным префиксам и поднятой метрикой у «общего» маршрута на клиенте. Начните с диагностики: route print или ip route, убедитесь, какой маршрут побеждает. Добавьте более специфичные префиксы в конфигурации VPN, чтобы «переиграть» общий. Проверьте обратный маршрут на серверах и фильтры firewall. И занесите конфликт в реестр адресов — чтобы потом устранить навсегда, а не лечить симптомы каждый месяц.

Что выбрать: split tunneling или full tunnel?

Если приоритет — безопасность и контроль, берите full tunnel. Если приоритет — производительность и экономия трафика, особенно для публичных сервисов, берите split. Компромисс — full с локальным breakout на шлюзе или SASE-подход, где ближайшая точка применяет политики и выпускает трафик в интернет. Не забывайте про DNS и MTU: в split-сценариях их неправильно настроенный порядок вызовет «невидимость» внутренних сервисов или утечки. В идеале — пилот на канарейках, замер метрик, и только после этого массовый переход. Слепой выбор по вкусу почти всегда заканчивается переработкой.

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

Пинг — это ICMP, а сайты — TCP/UDP поверх HTTP(S). Если ICMP проходит, но TCP зависает, проверьте MTU и MSS: вероятно, большие сегменты режутся по пути, а PMTUD не работает из-за блокировки ICMP Fragmentation Needed. Еще вариант — DNS: по IP заходит, по имени нет? Тогда проверьте, через какой резолвер идут домены и не уходит ли запрос мимо VPN. Третий вариант — firewall или инспекция SSL, которая не пускает трафик, отличающийся от ожиданий (например, QUIC). Включите сниффер: если видите SYN без SYN-ACK — ищем обратный маршрут и фильтры на сервере.

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

На Windows отключите автоматическую метрику и выставьте InterfaceMetric для VPN-интерфейса, затем задайте RouteMetric для ключевых маршрутов. Проверьте через Get-NetRoute и route print. В Linux смотрите не только ip route, но и ip rule: приоритет правил может отправить трафик в другую таблицу. Для macOS — настройте порядок сервисов networksetup, проверьте route -n get для конкретного адреса. Во всех системах правило одно: меньшая метрика и более длинный префикс выигрывают. Документируйте параметры, чтобы избежать «магии» в будущем и знать, что у кого настроено.

Как диагностировать проблемы только на IPv6?

Сначала убедитесь, что VPN поддерживает IPv6 и есть соответствующие маршруты (например, ULA и глобальные префиксы). Запустите ping6/tracepath6 к внутреннему v6-адресу, проверьте ip -6 route или route print -6. Посмотрите DNS: AAAA-записи для внутренних доменов должны резолвиться через корпоративный резолвер. Проверьте MTU: в v6 PMTUD критически важен, и блокировка ICMPv6 ломает соединения. Если приложение по v6 идет мимо VPN из-за Happy Eyeballs, настроьте политику так, чтобы оба стека вели себя согласованно: либо оба через туннель, либо IPv6 отключен для конкретных маршрутов. Логи клиента VPN и сниффер дадут финальный ответ.