Считается, что связка из изолированной виртуальной машины, тотального запрета UDP на хосте и принудительного заворачивания TCP-процессов через Proxifier в локальный SOCKS5-порт — это своего рода “непробиваемый бункер” для обеспечения хотя бы условной сетевой анонимности. Ведь в такой схеме гостевая OS физически “слепа”, так как она не знает реального IP хоста и не имеет каналов для прямой утечки пакетов?

Но "бункер" может и пасть. И причины будут неприятными.

Я совершенно случайно обратил внимание, что внутри одной из моих совершенно изолированных виртуальных машин, мессенджер Element и популярный чекер 2ip.ru (через браузеры) продолжали с легкостью определять реальный IP-адрес хостовой OS! При этом классические тесты на утечки через WebRTC или DNS в браузерах показывали идеальную чистоту, а в логах Proxifier не было ни одного прямого (Direct) соединения.

В этой статье я хотел бы рассказать, как именно происходила деанонимизация, и почему корень проблемы лежал за пределами моего “железа” или софта?

Постановка задачи и конфигурация «стенда».

Для тестирования использовалась жесткая схема изоляции, исключающая традиционные стандартные бреши:

1. Гостевая OS: Виртуальная машина в портативном VirtualBox, работающая строго в режиме “NAT” (для изоляции от реальной локальной сети хоста).

2. Firewall хоста: Правилами в нём полностью заблокирован весь исходящий UDP-трафик для любого экземпляра виртуальных машин, что исключало утечки по протоколам STUN/ICE (WebRTC) и классическому DNS (порт 53/UDP).

3. Перехват трафика: На хостовой системе всегда запущен Proxifier (в режиме сервиса), правила которого принудительно перехватывают процессы “VirtualBox.exe” и “VBoxHeadless.exe”. Весь их TCP-трафик перенаправляется на локальный порт SOCKS5.

4. Прокси-клиент: На хосте запущено приложение Happ. При этом встроенные режимы системы (TUN-режим или системный прокси) в нём выключены. Happ используется исключительно как своего рода “генератор локального SOCKS5-интерфейса” (порт 10808). Внутри Happ правила маршрутизации полностью отключены вручную (чекбокс «Использовать маршрутизацию» в положении Выкл) и выбран конкретный статичный сервер.

А теперь самое интересное! Там в чём же была аномалия и каковы были её причины?

1. При использовании моего личного VPS и “чистого” VLESS-сервера без сторонних правил, описанная выше схема работала просто идеально! Абсолютно все используемые мной чекеры и корпоративный мессенджер Element видели строго IP-адрес моего личного VPS.

2. Как только я переключал Happ на коммерческую подписку от одного популярного на данный момент “провайдера” по обходу “таких-то списков”, чекер 2ip.ru и Element внутри виртуалки мгновенно начинали видеть реальный IP-адрес пользователя при описанных выше жесточайших настройках “изоляции” виртуальных машин. И в то же самое время множество других сервисов абсолютно четко продолжали показывать именно IP-адрес сервера из коммерческой подписки!

Первым делом подозрение пало на локальные утечки. Однако детальный разбор сетевого стека опроверг очевидную “классическую зацепку” - утечку через DNS. Дело в том, что на хосте используется dnscrypt-proxy, причем строго в режиме tcp, и целевые сайты просто обязаны были видеть лишь IP-адреса волонтерских DNS-серверов, но никак не реальный IP хостовой OS!

Дальше я стал подозревать локальный WebRTC. Но ведь флаги Chromium в Element и расширения в браузерах были настроены на блокировку локальных интерфейсов? Более того, при заблокированном UDP на хостовой OS (выше писал, что это было настроено в firewall), WebRTC физически не мог бы отправить пакеты для опроса STUN.

Дальше я стал грешить на VirtualBox, но соксификатор Proxifier, перехватывающий всего два процесса VirtualBox, через которые только лишь и работают мои виртуальные машины, подтвердил, что сетевой NAT-движок VirtualBox не порождал абсолютно никаких неучтенных процессов, и весь трафик из виртуальных машин шёл строго через соксифицированные процессы VirtualBox.exe и VBoxHeadless.exe.

Я начал впадать в прострацию, ведь мой условно-непробиваемый “анонимный сетевой контур” был “чист”?!
Proxifier честно забирал пакеты из виртуальных машин и без единой потери доставлял их в локальный socks5 сервер в Happ, а дальше “выстреливал” трафик через vless-сервера из коммерческой подписки.

Что же было не так?

А разгадка аномалии крылась в фундаментальном различии между приватным VPS и коммерческой подпиской. Это различие активировалось на этапе, когда зашифрованный трафик уже покинул мой ноутбук и прилетел в data-центр провайдера подписки. Забегая вперёд, отмечу, что факт “своеобразной” серверной маршрутизации уже подтвержден администратором технической поддержки провайдера в переписке. Оказывается, что когда вы покупаете массовую подписку в подобных сервисах, зачастую владельцы инфраструктуры вынуждены решать две весьма противоречивые “бизнес-задачи”:

1. Экономия дорогого зарубежного трафика (ведь за транзит каждого гигабайта между дата-центрами Европы и России провайдер платит деньги или упирается в “не резиновый” лимит).

2. Обеспечение доступности локальных ресурсов (многие российские сервисы, банки и государственные сайты намертво блокируют входящие соединения из зарубежных дата-центров Cloudflare, Hetzner, DigitalOcean и т.д.).

Для оптимизации админы коммерческих сервисов часто прописывают правила маршрутизации (например, блок routing.rules в конфигурации ядра Xray/sing-box) прямо на своих удаленных серверах, “скармливая” эту “принудиловку” прямо через подписки.

И теперь сводим воедино все элементы этого “паззла”:

1. Пакет от Element или 2ip.ru в зашифрованном виде долетает через VLESS до сервера провайдера (например, в Германии). На этом этапе на стороне пользовательского хоста всё выглядит как идеальный прокси-туннель.

2. Удаленный сервер расшифровывает пакет и видит, что целевой IP-адрес назначения принадлежит российскому диапазону подсетей (например, дата-центрам Яндекс.Облака, Selectel или VK Cloud, где развернут корпоративный Matrix-сервер или чекер 2ip.ru).

3. Серверная автоматика подписочного провайдера “принимает решение” - не пускать этот трафик через свой внешний европейский IP.

4. Вместо этого сервер использует специфическую маршрутизацию (например, директиву “freedom” в связке с обратным проксированием или IPv6-туннелированием, которая осуществляет сквозной проброс пакета. В заголовки запроса транслируется или принудительно подмешивается исходный маркер сессии пользователя (например, через заголовок “X-Forwarded-For” или используются иные особенности маршрутизации транспортного уровня).

5. Целевой российский сервер (Element или 2ip.ru) принимает этот запрос, считывает данные из «сквозного» заголовка и выводит пользователю его реальный IP-адрес, честно рапортуя о “сливе” и деаноне :-)

А поскольку собственный VPS — это «чистый лист» без коммерческих оптимизаций, его ядро просто обрабатывает 100% пакетов через себя, обеспечивая честную анонимность. Ну как честную? “Опустим” логирование на стороне хостера VPS. Условно-честную - так точнее! Тогда как подписочные коммерческие провайдеры зачастую жертвуют Вашей безопасностью ради экономии трафика и удобства рядовых пользователей, которым нужен лишь доступ к локальным сайтам без отключения VPN и им глубочайше наплевать “куда влетает и откуда вылетает”.

Ну и, конечно же, ещё и по той причине, чтобы на небольшом “парке” с таким трудом добываемых “связок” серверов для обхода “таких-то списков”, просто не легли бы разом все эти сервера от набранной клиентской базы страждущих и вожделеющих любителей "рилсов", котиков и прочих “видосиков” :-)

Перефразируя одну известную истину, я для себя сделал очевидный вывод - “анонимность заканчивается там, где начинается коммерческий VPN/VLESS-провайдер”.

И даже если вы построите идеальный, изолированный "бункер" на стороне клиента, вы остаетесь абсолютно бессильны перед правилами маршрутизации, которые админы стороннего сервиса прописывают на своих серверах за вашей спиной…