Считается, что связка из изолированной виртуальной машины, тотального запрета UDP на хосте и принудительного заворачивания TCP-процессов через Proxifier в локальный SOCKS5-порт — это своего рода “непробиваемый бункер” для обеспечения хотя бы условной сетевой анонимности. Ведь в такой схеме гостевая OS физически “слепа”, так как она не знает реального IP хоста и не имеет каналов для прямой утечки пакетов?
Но «бункер» может и пасть. И причины будут неприятными.
Я совершенно случайно обратил внимание, что внутри одной из моих совершенно изолированных виртуальных машин, мессенджер Element и популярный чекер 2ip.ru (через браузеры) продолжали с легкостью определять реальный IP-адрес хостовой OS! При этом классические тесты на утечки через WebRTC или DNS в браузерах показывали идеальную чистоту, а в логах Proxifier не было ни одного прямого (Direct) соединения.
В этой статье я хотел бы рассказать, как именно происходила деанонимизация, и почему корень проблемы лежал за пределами моего “железа” или софта?
Постановка задачи и конфигурация «стенда».
Для тестирования использовалась жесткая схема изоляции, исключающая традиционные стандартные бреши:
-
Гостевая OS: Виртуальная машина в портативном VirtualBox, работающая строго в режиме “NAT” (для изоляции от реальной локальной сети хоста).
-
Firewall хоста: Правилами в нём полностью заблокирован весь исходящий UDP-трафик для любого экземпляра виртуальных машин, что исключало утечки по протоколам STUN/ICE (WebRTC) и классическому DNS (порт 53/UDP).
-
Перехват трафика: На хостовой системе всегда запущен Proxifier (в режиме сервиса), правила которого принудительно перехватывают процессы “VirtualBox.exe” и “VBoxHeadless.exe”. Весь их TCP-трафик перенаправляется на локальный порт SOCKS5.
-
Прокси-клиент: На хосте запущено приложение Happ. При этом встроенные режимы системы (TUN-режим или системный прокси) в нём выключены. Happ используется исключительно как своего рода “генератор локального SOCKS5-интерфейса” (порт 10808). Внутри Happ правила маршрутизации полностью отключены вручную (чекбокс «Использовать маршрутизацию» в положении Выкл) и выбран конкретный статичный сервер.
А теперь самое интересное! Там в чём же была аномалия и каковы были её причины?
-
При использовании моего личного VPS и “чистого” VLESS-сервера без сторонних правил, описанная выше схема работала просто идеально! Абсолютно все используемые мной чекеры и корпоративный мессенджер Element видели строго IP-адрес моего личного VPS.
-
Как только я переключал 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-центр провайдера подписки. Забегая вперёд, отмечу, что факт “своеобразной” серверной маршрутизации уже подтвержден администратором технической поддержки провайдера в переписке. Оказывается, что когда вы покупаете массовую подписку в подобных сервисах, зачастую владельцы инфраструктуры вынуждены решать две весьма противоречивые “бизнес-задачи”:
-
Экономия дорогого зарубежного трафика (ведь за транзит каждого гигабайта между дата-центрами Европы и России провайдер платит деньги или упирается в “не резиновый” лимит).
-
Обеспечение доступности локальных ресурсов (многие российские сервисы, банки и государственные сайты намертво блокируют входящие соединения из зарубежных дата-центров Cloudflare, Hetzner, DigitalOcean и т.д.).
Для оптимизации админы коммерческих сервисов часто прописывают правила маршрутизации (например, блок routing.rules в конфигурации ядра Xray/sing-box) прямо на своих удаленных серверах, “скармливая” эту “принудиловку” прямо через подписки.
И теперь сводим воедино все элементы этого “паззла”:
-
Пакет от Element или 2ip.ru в зашифрованном виде долетает через VLESS до сервера провайдера (например, в Германии). На этом этапе на стороне пользовательского хоста всё выглядит как идеальный прокси-туннель.
-
Удаленный сервер расшифровывает пакет и видит, что целевой IP-адрес назначения принадлежит российскому диапазону подсетей (например, дата-центрам Яндекс.Облака, Selectel или VK Cloud, где развернут корпоративный Matrix-сервер или чекер 2ip.ru).
-
Серверная автоматика подписочного провайдера “принимает решение” — не пускать этот трафик через свой внешний европейский IP.
-
Вместо этого сервер использует специфическую маршрутизацию (например, директиву “freedom” в связке с обратным проксированием или IPv6-туннелированием, которая осуществляет сквозной проброс пакета. В заголовки запроса транслируется или принудительно подмешивается исходный маркер сессии пользователя (например, через заголовок “X-Forwarded-For” или используются иные особенности маршрутизации транспортного уровня).
-
Целевой российский сервер (Element или 2ip.ru) принимает этот запрос, считывает данные из «сквозного» заголовка и выводит пользователю его реальный IP-адрес, честно рапортуя о “сливе” и деаноне 🙂
А поскольку собственный VPS — это «чистый лист» без коммерческих оптимизаций, его ядро просто обрабатывает 100% пакетов через себя, обеспечивая честную анонимность. Ну как честную? “Опустим” логирование на стороне хостера VPS. Условно-честную — так точнее! Тогда как подписочные коммерческие провайдеры зачастую жертвуют Вашей безопасностью ради экономии трафика и удобства рядовых пользователей, которым нужен лишь доступ к локальным сайтам без отключения VPN и им глубочайше наплевать “куда влетает и откуда вылетает”.
Ну и, конечно же, ещё и по той причине, чтобы на небольшом “парке” с таким трудом добываемых “связок” серверов для обхода “таких-то списков”, просто не легли бы разом все эти сервера от набранной клиентской базы страждущих и вожделеющих любителей «рилсов», котиков и прочих “видосиков” 🙂
Перефразируя одну известную истину, я для себя сделал очевидный вывод — “анонимность заканчивается там, где начинается коммерческий VPN/VLESS-провайдер”.
И даже если вы построите идеальный, изолированный «бункер» на стороне клиента, вы остаетесь абсолютно бессильны перед правилами маршрутизации, которые админы стороннего сервиса прописывают на своих серверах за вашей спиной…
ссылка на оригинал статьи https://habr.com/ru/articles/1056290/