Почему один и тот же? Это как раз лес, уверен люди сотни гигабайт трафика генерируют к различным ресурсам, причем в одних и тех же местах.
Тип сайта и его содержимое они не смотрят. Это тяжело обнаружить.
Не будут они различать офис это или не офис, одни и те же провайдера идут и там и там.
Помимо него куча других пользователей будет генерировать с того же белого IP куча трафика к другим сервисам, и по-больше моего туннеля.
Может быть, но это не масштабируется. Каждого так вылавливать – с ума сойти. Даже алгоритмами анализировать логи, тоже сложно. Во-первых нужно однозначно идентифицировать абонентов, во-вторых NAT IP может меняться, в-третьих если не коодинировать атаку с использованием второй точки наблюдения не получится однозначно идентифицировать связку SRC → DST, которую ломает банальная смена NAT IP, требует долгой временной корреляции и координации второго наблюдателя.
Короче – им проще в шпионы, чем в ненадежный анализ на одной точке наблюдения.
Современный Tor сейчас очень шустрый, например TikTok хорошо с ним пашет. Но я вам не взамен схеме предлагаю использовать, а лишь средство для исправления технической неисправности на шлюзе.
Как раз-таки и будет лес, спасибо другим интернет пользователем, вы у провайдера не единственные.
Для прозрачной маршрутизации на конечных устройствах. Например iOS. Включил VPN 24/7 – работает.
А у меня на Android ByEbyEDpI , Split-Tunneling по белым приложениям , изолированные рабочие профили , FakeIP-FakeDNS , dnsproxy через DoH , и т.д и т.п!!1!
Какой раз говорю, конечные устройства должны быть тупыми, не заниматься транспортом для самих себя. Умным должен быть роутер. В моей схеме вместо карманного OpenWRT роутера вы используете удаленный шлюз маршрутизации.
Кстати, вот она бонусом и идет. И прозрачная маршрутизация на тостере, и анонимность тостера.
В моей схеме так и делается. Напоминаю, для полной деанонимизации входного IP туннеля требуется хотя бы две точки наблюдения из трёх:
- ISP
- Хостер
- Cloudflare / Сервисы
Будет кореллировать SRC → DST. Проезет в ваши правила маршрутизации, например через запросы к серверу, хост/IP которого вы не переписали.
Кореллировать как?
Логи провайдера, в те же временные окна видеть подключения к шпиону и туннелю, ML не нужен.
Как получат доступ к двум точкам наблюдения? Выдумки!
- Первая точка – ISP:
- Вторая точка – конечные сервисы.
К слову, новость они эту продавили, уверен, задним числом, на некоторых уже были шпионы, а сейчас будут у всех.
Вот вам и точки наблюдения.
Самое главное – он универсальный. iOS спокойно работает. Все сервисы работают. Переживать за утечки – не нужно.
Но ведь корреляция и т.д??
Без компрометации хотя бы двух точек наблюдения, из трёх что я перечислил – нормально не выйдет или будет куча ложных срабатываний.
Моя схема как раз минимизирует эту возможность. Пусканием шпионов в direct вы лишь её ослабляете. Причем схему ослабляете сильнее, чем призрачные объемы трафика, которые в уме палятся, а на деле – тот ещё геморрой.
Пока-что просто только в уме. Проще будет, если вы в direct что-то будете пускать. Тогда намного проще. Шпион идет через direct – тогда всё, точно спалитесь. Шпион не идет через direct – всё достаточно хорошо.
Поэтому всё неизвестное, включая рф сервисы – идут через Warp. С ним открываются даже госуслуги. Главное не забудьте про прозрачное форсирование Yandex-DNS для ру-сервисов.
Cloudflare считается резидентским, создан быть резидентским. Поэтому даже Кинопоиск не пускает с ASN ДЦ, а с Warp – пускает.
То есть вас заставили ослабить свою схему просто из-за…
- Во-первых пока лично не сталкивался с ограничением доступа с WARP.
- Во-вторых, шлите такие сервисы лесом. Вон в соседней теме бойкот на уровне DNS предлагают. Просто добавьте такой сервис в блок и забудьте о нем.
В общем, идти нужно дальше, а не сдавать назад.