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