Видит ли MAX ваш VPN при Split Routing, если VPN не установлен на компьютере?
Эксперимент с десктопным клиентом MAX для Windows проводился 8 сентября 2026 года. Целью было не подтвердить заранее выбранную гипотезу, а проверить на практике, какие процессы запускает приложение, к каким ресурсам обращается и способен ли оно обнаружить VPN, настроенный не на компьютере, а на сетевом маршрутизаторе.
Главный вопрос звучал так: может ли MAX понять, что часть трафика Windows проходит через защищённый туннель, если на самом ПК нет VPN-клиента, виртуального адаптера и дополнительных маршрутов?
Схема эксперимента
Компьютер подключался к роутеру Keenetic обычным Ethernet-соединением. На Windows отсутствовали VPN-программы, виртуальные сетевые интерфейсы и маршруты, связанные с туннелем. Вся логика разделения трафика выполнялась на маршрутизаторе.
Схема выглядела следующим образом:
- Windows-ПК подключён к Keenetic по LAN;
- часть российских ресурсов открывается напрямую;
- остальные направления маршрутизатор отправляет через OpenConnect;
- туннель завершается на VPS в Европе;
- далее трафик выходит в интернет с удалённого сервера.
Иными словами, это классический Split tunneling VPN, но реализованный не на конечном устройстве, а на шлюзе. Поэтому в таблице маршрутов Windows не было явных признаков VPN, а приложение MAX не могло просто просканировать виртуальные адаптеры и сразу обнаружить туннель.
Подробное описание методики и результатов эксперимента доступно в материале о том, [как MAX взаимодействует с VPN при маршрутизации на роутере](https://habr.com/ru/articles/1080196/?utm_campaign=1080196&utm_source=habrahabr&utm_medium=rss).
Во время проверки требовалось выяснить:
- какие процессы запускает MAX Desktop;
- какие соединения создают MAX.exe и MAX-service.exe;
- какие параметры Windows читает приложение;
- обращается ли клиент к настройкам proxy и PAC;
- пытается ли он определить внешний IP;
- проходит ли его трафик через VPN, настроенный на Keenetic;
- есть ли признаки целенаправленного поиска VPN в системе.
Чем фиксировалась активность
До установки приложения были сохранены сетевые параметры Windows, список адаптеров, таблица маршрутов, контрольная сумма SHA-256 установочного MSI-файла и его Authenticode-подпись. Это позволило сравнить конфигурацию системы до и после установки.
Для наблюдения использовались следующие инструменты:
- Process Monitor - доступ к реестру и файлам, создание процессов, TCP-подключения;
- Wireshark - DNS-запросы, TLS-сессии, SNI и последовательность сетевого обмена;
- TCPView - открытые порты и связь соединений с конкретными PID;
- tcpdump на VPS - проверка пакетов на VPN-интерфейсе vpns0.
Такой набор инструментов позволял сопоставить действие приложения с конкретным сетевым потоком. Например, Wireshark показывал, куда направляется соединение, а tcpdump на сервере помогал понять, действительно ли оно прошло через OpenConnect-туннель.
Какие процессы запускает MAX
После установки появились два основных компонента: MAX.exe и MAX-service.exe. Основной процесс устанавливал HTTPS-соединение с внешними узлами, а служебный компонент работал отдельно и взаимодействовал с клиентом через loopback-интерфейс.
В одном из захватов MAX-service.exe прослушивал локальный порт 61415, а MAX.exe подключался к нему через 127.0.0.1. Такое поведение само по себе не указывает на наличие VPN: локальный сервис может использоваться для обновлений, фоновых функций, проверки состояния приложения или взаимодействия между компонентами.
При анализе важно было отличать сетевые действия самого мессенджера от активности операционной системы и сторонних процессов. Поэтому события Process Monitor сопоставлялись с PID, временем подключения и данными TCPView.
Какие данные читает приложение
MAX обращается к ряду стандартных системных параметров Windows. Среди них - стабильный идентификатор установки MachineGuid, имя компьютера, сетевое имя узла и собственные идентификаторы устройства. Подобные сведения часто применяются для привязки сессии, защиты от повторной регистрации и поддержки уведомлений.
Само чтение MachineGuid не доказывает слежку за VPN. Это системный параметр, который могут использовать самые разные приложения. Аналогично, получение ComputerName или Hostname ещё не означает попытку определить маршрут трафика.
Отдельное внимание привлекли настройки прокси и PAC. Их чтение может выглядеть подозрительно, однако эти параметры необходимы приложению для корректной работы в корпоративных сетях, где выход в интернет организован через прокси-сервер. Проверка proxy/PAC не равна проверке VPN: прокси и туннель работают на разных уровнях.
Также анализировалась активность MAX-service.exe, связанная с разрешениями и доступом к микрофону или камере. Наличие таких обращений объяснимо функциональностью мессенджера, но при оценке приватности важно учитывать не только сетевые подключения, но и локальные обращения к оборудованию.
Видит ли MAX VPN, настроенный на роутере
Ключевой результат эксперимента заключался в следующем: на компьютере не обнаруживалось локального VPN-клиента, отдельного адаптера или специального маршрута. При этом сетевой трафик, который по правилам Keenetic должен был идти через OpenConnect, действительно проходил через VPS.
Проверка на стороне сервера позволяла отделить обычные прямые соединения от потоков, отправленных в туннель. При сопоставлении времени, адресов и процессов выяснялось, какие подключения MAX попадали под правило маршрутизации Keenetic.
Таким образом, MAX мог использовать VPN-маршрут фактически, даже не имея доступа к VPN-клиенту на Windows. Но это не означает, что приложение видело сам туннель как объект системы. Оно отправляло запросы в обычный сетевой стек, а решение о дальнейшем маршруте принимал роутер.
Иными словами, вопрос "MAX и VPN" имеет два разных аспекта. Клиент может оказаться за VPN с точки зрения внешнего IP и сетевого пути, но при этом не обнаруживать на компьютере никаких признаков установленного VPN-приложения.
Пытался ли MAX определить обходной маршрут
Теоретически программа могла бы использовать несколько методов:
- проверять внешний IP через сторонние сервисы;
- сравнивать DNS-ответы;
- обращаться к узлам, доступным только через определённый маршрут;
- анализировать задержки и характеристики соединения;
- читать таблицу маршрутизации и сведения о сетевых адаптерах;
- искать установленные VPN-клиенты и службы.
Однако чтение сетевых параметров Windows и установление HTTPS-соединений ещё не означают намеренного поиска VPN. Для уверенного вывода потребовалась бы отдельная серия тестов с контролируемыми DNS-запросами, изменением внешнего IP, блокировкой диагностических адресов и сравнением поведения приложения в нескольких конфигурациях.
Именно поэтому корректнее говорить не о доказанном обнаружении VPN, а о наблюдаемом сетевом поведении. Эксперимент показал, что трафик MAX может проходить через VPN на уровне роутера, тогда как локальных признаков туннеля на Windows приложение не получает автоматически. Дополнительные детали о том, [что именно видит MAX в Windows при Split Routing](https://habr.com/ru/articles/1080196/?utm_campaign=1080196&utm_source=habrahabr&utm_medium=rss), зависят от конкретной версии клиента и конфигурации сети.
Что доказано, а что остаётся предположением
В ходе проверки удалось подтвердить несколько положений:
1. MAX Desktop запускает основной процесс и отдельный локальный сервис.
2. Приложение создаёт внешние HTTPS-соединения.
3. Клиент обращается к системным идентификаторам и сетевым настройкам Windows.
4. Трафик MAX может проходить через OpenConnect, если маршрутизацию выполняет Keenetic.
5. Отсутствие VPN-клиента на Windows не препятствует использованию VPN-маршрута.
6. Сам факт чтения proxy, PAC или MachineGuid не доказывает попытку обнаружить VPN.
При этом эксперимент не устанавливал полный перечень всех возможных проверок внутри приложения. Нельзя исключить, что разные версии MAX используют дополнительные сетевые методы или меняют поведение в зависимости от региона, учётной записи и серверной конфигурации.
Для более строгой проверки стоило бы повторить тест с несколькими VPN-провайдерами, разными DNS-серверами, отключённым IPv6, альтернативными правилами Split Routing и несколькими версиями клиента. Полезным было бы также сравнить результаты при прямом подключении, VPN-клиенте в Windows и туннеле на отдельном шлюзе.
Итог
Если VPN установлен непосредственно в Windows, приложение потенциально может увидеть виртуальный адаптер, службу или специальные маршруты. При настройке VPN на роутере ситуация иная: компьютер воспринимает Keenetic как обычный шлюз и не получает очевидной информации о внутреннем OpenConnect-туннеле.
Поэтому MAX способен оказаться за VPN и использовать его внешний маршрут, но это ещё не означает, что он видит VPN-клиент или знает, каким именно способом организован туннель. В рассматриваемой схеме ключевая информация о маршрутизации остаётся на стороне роутера и VPS, а Windows-приложению доступны главным образом стандартные системные параметры и результаты обычных сетевых подключений.
