Видит ли MAX ваш VPN при Split Routing, если VPN не установлен на компьютере?
Эксперимент проведён 8 сентября 2026 года на компьютере под управлением Windows. Его цель - не поиск способов обхода ограничений, а практическая проверка того, какие данные собирает MAX Desktop, какие сетевые соединения создаёт приложение и может ли оно обнаружить VPN, если туннель настроен не в Windows, а на роутере.
Главный вопрос звучал так: видит ли MAX VPN при split tunneling, если на компьютере нет VPN-клиента, виртуального сетевого адаптера и дополнительных маршрутов? В рассматриваемой схеме Windows подключена обычным Ethernet-кабелем к роутеру Keenetic. Сам маршрутизатор устанавливает OpenConnect-соединение с VPS в Европе и делит трафик: часть направляется напрямую, а выбранные назначения - через VPN-туннель.
Схема эксперимента
Топология выглядела следующим образом:
```text
ПК с Windows
│ Ethernet
▼
Keenetic - шлюз и Split Routing
├── прямой выход в Интернет
└── OpenConnect-туннель → VPS → Интернет
```
На компьютере не было VPN-программы, отдельного адаптера или маршрута, указывающего на удалённый сервер. Вся логика разделения трафика находилась на сетевом шлюзе. Именно поэтому этот сценарий позволяет понять, как работает split routing через VPN, когда конечное устройство не участвует в создании туннеля.
Для наблюдения использовались Process Monitor, Wireshark и TCPView в Windows. На VPS работал tcpdump, анализировавший пакеты на VPN-интерфейсе `vpns0`. До установки MAX были сохранены сведения о сетевых адаптерах, таблице маршрутов и основных параметрах TCP/IP. Кроме того, для установочного MSI-файла проверялись SHA-256 и цифровая подпись Authenticode.
Такой набор инструментов позволил сопоставить действия конкретных процессов с реальными сетевыми пакетами. Process Monitor фиксировал обращения к реестру, файлам и создание процессов. Wireshark показывал DNS-запросы, TLS-соединения и SNI. TCPView помогал связать открытые соединения с PID, а tcpdump на сервере подтверждал или опровергал прохождение потока через VPN.
Что запускает MAX Desktop
После установки в системе появились два основных компонента: `MAX.exe` и `MAX-service.exe`. Основной процесс устанавливал внешнее HTTPS-соединение, а сервис взаимодействовал с ним через loopback-интерфейс. В одном из захватов `MAX-service.exe` слушал локальный порт 61415, а клиент подключался к нему через `127.0.0.1`.
Такое разделение само по себе не означает наличие скрытого VPN или специальной сетевой проверки. Локальный сервис может использоваться для фоновых задач, обновлений, работы с системными разрешениями и обмена данными между привилегированным компонентом и пользовательским интерфейсом.
В ходе наблюдений MAX обращался к стандартным параметрам Windows, включая стабильный идентификатор установки `MachineGuid`, имя компьютера `ComputerName` и сетевое имя `Hostname`. Также приложение использовало собственные идентификаторы устройства. Подобные сведения могут применяться для привязки сессии, защиты аккаунта, диагностики и выявления повторных установок.
Отдельного внимания заслуживают параметры proxy и PAC. Сам факт чтения этих настроек ещё не говорит о том, что приложение пытается разоблачить VPN. Прокси-конфигурация нужна обычным сетевым приложениям: она определяет, каким образом устанавливать соединение, следует ли использовать корпоративный прокси и где находится сценарий автоматической настройки.
В журнале также фиксировались обращения сервисного компонента к возможностям, связанным с микрофоном и камерой. Однако запрос к системному ресурсу не равен фактической записи аудио или видео. Для достоверного вывода необходимо отдельно анализировать разрешения, открытие устройств и последующую передачу данных.
Проходит ли трафик MAX через VPN
Ключевая часть проверки заключалась в сравнении сетевого поведения MAX с маршрутами, настроенными на Keenetic. Если домен или IP-адрес попадал в правило Split Routing, соответствующий поток должен был появиться на интерфейсе `vpns0` на VPS. Остальные соединения должны были идти напрямую.
Windows при этом не показывала VPN-соединение: в списке адаптеров отсутствовал виртуальный интерфейс, а таблица маршрутизации не содержала признаков OpenConnect. Поэтому простое чтение сетевых параметров операционной системы не позволяло MAX увидеть сам факт существования удалённого туннеля.
Наблюдения показали, что соединения MAX действительно следовали правилам маршрутизации Keenetic. Трафик, попадавший под VPN-маршрут, фиксировался на VPS через OpenConnect. Остальные подключения уходили обычным путём. Иными словами, приложение не создавало собственный туннель, но его пакеты автоматически подчинялись решениям роутера.
Более подробно разобрать логику эксперимента и сопоставление данных Procmon, Wireshark и tcpdump можно в материале о проверке MAX Desktop при маршрутизации VPN через Keenetic.
Пытался ли MAX обнаружить VPN
Важное различие - между обнаружением VPN-клиента и определением фактического внешнего маршрута. Программа могла бы искать виртуальные адаптеры, читать таблицу маршрутов, проверять типичные имена служб, анализировать прокси или обращаться к внешнему сервису для определения публичного IP.
В рассматриваемой конфигурации очевидных признаков VPN в Windows не было. Поэтому MAX не мог обнаружить OpenConnect обычным перечислением интерфейсов или чтением стандартной таблицы маршрутов. Для этого пришлось бы самостоятельно проверять внешний IP, сравнивать географию и автономную систему адреса, тестировать дополнительные узлы либо использовать собственный сервер диагностики.
Однако один внешний IP не доказывает наличие VPN. Его может предоставлять оператор связи, корпоративный шлюз, NAT, прокси или другой маршрутизатор. Аналогично, европейский адрес сам по себе не подтверждает, что трафик проходит через конкретный VPS.
При необходимости пользователь может самостоятельно выяснить, как проверить утечку трафика мимо VPN: сравнить DNS-серверы, публичный IP, маршруты до тестовых узлов и захват пакетов на VPN-интерфейсе. Наиболее надёжным считается одновременное наблюдение на клиенте, роутере и сервере, поскольку один источник данных может давать неполную картину.
Что доказал эксперимент
Проверка позволяет сделать несколько аккуратных выводов:
- MAX Desktop запускает основной процесс и отдельный локальный сервис.
- Приложение обращается к системным идентификаторам и сетевым настройкам Windows.
- В системе фиксируются собственные идентификаторы устройства.
- Отдельное внимание уделяется proxy/PAC и базовым параметрам конфигурации.
- Трафик MAX может проходить через VPN, настроенный на Keenetic.
- Windows при этом не обязана видеть VPN-адаптер или виртуальное подключение.
- Сам факт прохождения пакетов через удалённый шлюз не означает, что приложение напрямую обнаружило VPN.
Есть и ограничения. Эксперимент отражает поведение конкретной версии клиента, конкретной конфигурации роутера, набора доменов и правил маршрутизации. Обновление MAX, изменение DNS, появление новых серверов или включение дополнительных механизмов телеметрии могут изменить результат.
Такая схема фактически представляет собой VPN без установки на компьютере через роутер. Она удобна тем, что сетевые правила централизованы и не требуют вмешательства в Windows. Но при этом контроль нужно осуществлять на самом шлюзе: именно там находятся маршруты, DNS-логика и правила разделения трафика.
Для практического применения важна корректная настройка split tunneling на роутере. Следует заранее определить, какие домены или подсети должны идти через туннель, проверить IPv4 и IPv6, исключить DNS-утечки и убедиться, что правила не конфликтуют между собой. После этого полезно протестировать несколько независимых соединений и подтвердить их прохождение через VPS с помощью tcpdump.
Итоговый ответ на главный вопрос таков: если VPN настроен только на роутере, MAX не получает очевидного признака VPN из Windows - виртуального адаптера, локального клиента или характерного маршрута. При этом приложение может видеть обычные сетевые параметры и те внешние характеристики соединения, которые доступны любому интернет-клиенту. Поэтому скрыть сам факт нестандартной маршрутизации полностью нельзя, но обнаружение VPN-клиента на компьютере и определение маршрута через сетевой шлюз - разные задачи.
