А что если скрепные сервисы просто будут отсекать вообще весь датацентровый трафик? Условно с тех же серверов рувдс/вдсина/яша/вк и т.д? Конечно в обычных условияъ решение выглядит как просто отсекать такие сервисы и пускать напрямую, но в условии вайтлистов такое уже не прокатит
Тотже сбер/тинек они как не были в вайтлистах так их и нет
Вообще на телефоне возможно присрать какое то решение по типу
Мобилка → вайтлистовый VPN → домашний роутер с белым IP → скрепные сервисы
(я хочу рассмотреть именно платный вайтлистовый VPN, ибо все аккаунты в яше/вк уже в бане за крутки айпишников)
Да, решение описано в статье:
я правильно понимаю, что в этой схеме можно попробовать локально маршрутизацию настроить, чтобы geoip, geodb ru отправлять через домашний ip?
если всякие шпионские скамы и проведут трафик через VLESS, то задетектят outbound IP и никаких проблем это не вызовет, так?
меня просто напрягает то, что такая схема лечит утечку ip на стороне клиента, но на ТСПУ трафик будет выглядеть будто пользователь ходит на один inbound IP, ведь так?
Задумка в том что вся маршрутизация происходит на сервере. Ничего кроме bittorrent отправлять с домашнего IP почти не имеет смысла.
Лучше неизвестное через Warp, а так да. Главное
чтобы входной IP был другой.
Так и должно быть. Подключение к удаленному шлюзу маршрутизации.
warp здесь слабое звено
как выяснилось, с него вешаются многие русские сайты
непонятно связано ли это с AMS точкой входа
но так или иначе они забанят IP известных VPN, и warp будет первым
им уже приказали это сделать с 15-APR
вероятно лягут mail.ru, vk , yandex, ozon , avito и тд
если их пускать напрямую, а все остальное - через хитросплетения, то жук сработает
насчёт сигн-боха хз, но для v2rayng вот тут есть хороший пресет в json, самолично его воткнул давно, работает норм, ру сайты дейсвительно идут в директ (если выбран второй режим RU-2)
Разве не проще просто асболютно весь трафик впски завернуть в варп? =) пусть банят клаудфлейр сколько угодно, они это уже делают
Можно еще конечно сделать варп→своё→варп
Если я правильно понял, у WARP есть два серьезных минуса:
-
Если пихать в WARP абсолютно весь трафик, то получим повышенное время отклика во всех приложениях. Для какого-нибудь Сбера не критично, но для геймеров очень даже. Да и в целом это мало кому понравится, что все в интернете с дополнительной задержкой открываться станет, пускай даже задержка эта и не супер-огромная, но - она есть и это не может не раздражать.
-
Если пихать в WARP трафик выборочно, то придется буквально жить на сервере, постоянно добавляя в него какие-то правила, типа “вот этот сайт напрямую, а вот этот через WARP”.
Ну пока варп в россии понеобъяснимой причине функционирует можно трафик пускать в браузере через локальное прокси, ну а игры и т.д через варп если не рабтают
Согласен, может создать отдельную статью здесь для очень детального пошагового объяснения, причем с объяснениями как схему расширять, допустим изменять маршрутизацию с добавлением новых списков?
Могу арендовать новый временный VPS на Ubuntu (там всё равно почасовая оплата), и записать все команды и нюансы, которые я проделал чтобы добиться полного продакшн состояния. Чтобы таким образом гарантировать воспроизведенность хотя бы минимально на одном хостинге.
Как допустим тогда я бы сюда попал? Не все люди, которых интересует тема, которые могли бы развивать сообщество на энтузиазме уже известны модераторам здесь. Это не расширяется, потенциально закрытый пузырь без развития.
Добавлю, ещё проблема в том, что их инструкция потенциально не расширяема самостоятельно, то есть в любой инструкции должен быть железный фундамент и поле для бесконечных модификаций, причем типичных. Допустим новые geosite geoip списки добавить, их находить, изменить порядок правил. А протокол как изменять им знать не обязательно.
Согласен, обычно когда я сам к чему-то дошел, то я могу написать краткую справку инструкцию для себя же, все шаги которые я сделал с нуля.
На то и был рассчёт, что статью должны раскритиковать, чтобы проверить насколько моя задумка хороша. (Не само оформление, а именно полная идея такой схемы маршрутизации).
Первый блин всегда комом, так всегда было, есть, и будет.
Отвечу с радостью, особенно критика, потому что лучше раскритикованная схема, с указанием всех её слабостей, чем типа “идеальная” но на самом деле плохая. У нас нет права на ошибку, в любой момент наши сервера может обнаружить РКН, поэтому лучше обсудить вообще все уязвимости, чтобы переделать схему, если нужно.
Всё неизвестное – да. На данный момент Госуслуги и прочие коммерческие сервисы открываются с ним. Если вдруг перестанут – шлите такие сервисы лесом, это их проблемы.
Всё известное (минимально) – DIRECT (на сервере). Игровые порты + конкретные домены/списки. И какие-нибудь Apple CIDR / Telegram CIDR, что считаются доверенными.
WARP не подходит для realtime вещей из за ping jitter. Он хорошо работает с вебсайтами из за CDN.
Почему бы тогда на компьютере не пускать игровой трафик в DIRECT?
Поломали связность, не на всех ASN проходит наружу трафик для конкретных CDN (по моим наблюдениям, например на каком-то хопе ASN Ростелекома не шел трафик к Cloudflare CDN).
В DIRECT с компьютера пускать только bittorrent (для максимизации bandwidth и юр. риски).
Warp не предназначен и не оптимизирован под игры. Для вебсайтов – очень даже.
В Xray-core есть sendThrough параметр в Outbounds, поэтому можно без singbox (лично мне разработчик xray не нравится чуть меньше, чем разработчик singbox)
Я причём уже не раз говорил про это, даже с DME/LED некоторые сайты не открываются. Я бы вместо отдельного RU VPS (при отсутствии белых списков) или WARP просто отправил бы весь RU сегмент на домашний IP (и его бы сделал входной точкой). А все IP чекеры можно тоже в другой outbound, есть соответствующий geosite.
По-хорошему можно ещё реализовать XHTTP + разделение up/downstream.
Ладно допустим что триггеров корреляции по временным окнам (в конкретном ТСПУ адрес которого вы сами и слили) не существует и не будет существовать. Уже допущение.
А IP чекеры, которые не в geosite, выдадут ваш выходной IP. И дай бох он не совпадет с входным, тогда как максимум забанят лишь выходной.
Что тогда предлагается взамен WARP? Некоторые сайты с ним не открываются.
Некоторые сайты и с IP датацентра не открываются, а не пускать с WARP – вредительство. Ну как минимум не отступать, размывать SRC IP или промежуточные узлы, дальше и дальше, но не назад.
Что значит “размывать SRC IP”?
Поменять внутренний NAT IP, использовать другую сеть (например не Ethernet, а сотовую связь).
Их можно вместе с другим не-RU трафиком отправить зарубеж (как вы предлагали, через Tor), тогда проблем не будет.
Ну и эти списки существуют отчасти, чтобы другие пополняли его в том числе.
Вы не поняли, нужно использовать домашний белый (не в смысле белых списков на моб. интернете, а в смысле статического) сервер в качестве входного узла, тогда и надобности в WARP или в других махинациях для спуфинга резидентского адреса не будет.
То есть я правильно понимаю, что всё закрытие уязвимости держится только на том лишь хрупком предположении, что адрес IP чекера войдет в список?
Контр-пример: любой, абсолютно любой сервис, подконтрольный шпиону, может содержать в теле своего ответа IP, в любых API ответах, в любом зашированным за TLS-pinning ws канале / TCP потоке. Он не будет называться “IP checker”, любой сервис может вернуть IP.
Понял, то есть другими словами – резидентский прокси. Да, это будет работать, неудобно конечно, появляется новая точка обслуживания. И не все ISP дают белые IP, так что схема не универсальна.
Лично я пока не нашел сервисов, которые не открываются с Warp, всякий Yandex / Госуслуги / ВК – работают, что там ещё русскому человеку надо? Но да, могут прикрыть. Главное назад не сдавайте, всё-таки корреляция потоков, их пост-обработка и анализ – не шутка. Я бы серьезно на месте РКН так и делал, это намного дешевле, не требует real-time. Да что там, ML не требуется, лишь алгоритмы.
Правильно ли понимаю, что тут предлагается следующее:
Отправлять абсолютно весь трафик(кроме торрентов) с домашнего роутера в один постоянный VPN туннель до российского VPS сервера и далее уже на этом сервере заниматься маршрутизацией (что то отправлять через второй айпи VPS, что-то отправлять в warp, что-то на другой иностранный сервер\tor и т.д)?
Если так, то мне этот метод кажется еще более “палевным”. Если пользователь(роутер) постоянно подключен только к одному ip(и больше никуда) и гоняет там сотни ГБ трафика, то это с 99% шансом VPN. Причем, отследить и заблокировать такое может сам провайдер, ему для этого даже доступ к ТСПУ не потребуется. На данный момент такая схема может и работает, но если начнется полноценная массовая охота на VPN, хотя тут скорее “когда”, а не “если”, то подобные туннели первыми в блок отлетят.
Да и VPS на котором лежит вся маршрутизация буквально являет единой точкой отказа. Случись что с сервером, банально сбой у хостера или ракета прилетит по ДЦ и всё. Что делать в таком случае? Наслаждаться чебурнетом или жить вообще без интернета пока сервер не восстановится? От крупных сбоев никто не застрахован, даже всякие AWS\CF порой падают и лежат часами.
Совершенно верно.
А если я специально сгенерирую столько ГБ трафика куда-то, чтобы спровоцировать его блок?
А если сто пользователей внутри NAT пользуются одним и тем же сервисом, почему бы и нет?
Такой шлюз всё равно не предназначен для сотни людей из-за отсутствия ненужной здесь балансировки трафика.
Пока-что говорить “о палевности” не имеет смысла пока не с чем сравнивать.
Переключиться на Tor, ждать восстановления. webtunnel мосты через свого почто-бота запросить. Это настолько маленький шанс, что смысла париться об этом нет.
Я бы хотел услышать что бы вы предложили. Что-то в DIRECT пускать? Можно, часть доверенных сервисов со смартфона, например системные службы Apple. Да и Bittorrent ещё, разумеется.
Нет, пока утверждения о “палевности” не могут никак подтвердиться. А вот о шпионах – уже известно. И они более реальные, чем какие-то призрачные объемы трафика измерять. К одному IP может идти по разным причинам, всех вы не знаете, и не факт, вообще не факт, что это туннель, а не интенсивная работа API сервиса.
Здесь схема как минимум рабочая и никого за объемы трафика ещё не банили. Давайте решать проблемы по мере их поступления. Сейчас актуальная проблема – шпионы, а не операторы ISP.
Что-то уж слишком тяжело верится в ситуацию, где условные 20\50\100 пользователей будут сидеть и использовать только один единственный сервис, учитывая, что речь идет про домашний интернет, а не офис. Сейчас почти в любом софте (винда, драйвера видеокарты, браузер, игровые лаунчеры) есть куча модулей для телеметрии. Так что, даже если там сидит сто пользователей, которые используют какой-то конкретный сервис и генерируют на него сотни ГБ трафика, то эти же самые пользователи должны генерировать еще целую кучу трафика ко всяким этим сервисам телеметрии, а помимо этого еще и кучу остального трафика к другим сервисам. А если там есть только один постоянный туннель до одного конкретного сервера, то выглядеть это будет крайне подозрительно.
Может для серфинга в интернете оно и сгодится, но использовать тор для звонков/просмотра ютуба или стримов/игр явно не вариант.
Ну да, если хочешь спрятать дерево, то спрячь его в лесу. Зачем создавать крайне подозрительную активность с одним огромным туннелем на пустом месте, если многие блокировки впринципе обходятся zapret`ом, а вот остальное уже можно и в впн пустить. Гнать вообще весь трафик в туннель есть смысл только если вы хотите максимальной анонимности в сети, но толку прятать свой домашний ip от вк\госуслуг\яндекса\озона? Там и так куча данных на вас скопилась за годы пользования сервисами, независимо от того используете вы впн сейчас или нет.
А если вам надо защитить свой впн сервер от МАХа и подобных шпионов, то проще просто весь трафик с сервера в warp пускать, или арендовать второй сервак где-нибудь у aws\ovh\hetzner и пускать через него. Ну получит МАХ айпишник aws и что дальше он с ним делать будет? Амазон в РФ все равно давно заблочен.
В идеале, конечно, еще и свой домен с заглушкой сделать и реверс прокси через nginx\caddy заодно, чтоб впн не светился как новогодняя елка, а подключения к такому серверу выглядели более “легитимными“.
Я и не спорю с тем, что такой метод может быть рабочим на данный момент. Просто это выглядит, как попытка спрятать ёлку посреди пустыни. Проблема в том, что если РКН всерьез возьмется за массовые блокировки приватных VPN, то отслеживать и “вырубать“ такие ёлки будет крайне просто.
Кстати, пару дней назад видел новость, что Selectel ограничил доступ к госуслугам со своих серверов. Дальше такое могут раскать на большее количество сервисов и хостеров.
Да и сами сервисы могут начать проверять принадлежность ip клиента к asn хостера и блочить доступ. В таком случае, без директа с легитимного домашнего ip вообще не обойтись.
Почему один и тот же? Это как раз лес, уверен люди сотни гигабайт трафика генерируют к различным ресурсам, причем в одних и тех же местах.
Тип сайта и его содержимое они не смотрят. Это тяжело обнаружить.
Не будут они различать офис это или не офис, одни и те же провайдера идут и там и там.
Помимо него куча других пользователей будет генерировать с того же белого 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 предлагают. Просто добавьте такой сервис в блок и забудьте о нем.
В общем, идти нужно дальше, а не сдавать назад.
В вашей схеме, если все эти десятки пользвателей находятся за вашим домашним роутером, то весь трафик этих пользователей будет объединятся в один “большой“ туннель и идти к одному конкретному vps серверу.
Если же речь о том, что провайдер может объединять за NAT весь подъезд в доме и выдавать им одинаковый внешний ip, то тут тоже есть проблемка.
Может быть для условного кинопоиска вы и будете выглядеть как один пользователь с одним айпи, только вот для провайдера вы все все равно будете разными пользователями. Как минимум внутренний айпи за NAT прекрасно справится с тем, чтоб идентифицировать каждого. Да и пакет яровой не так просто был придуман. Все провайдеры обязаны хранить всю метадату по каждой сессии каждого конкретного пользователя 3 года.
В том и дело, что тут нет какого-то сложного ненадежного анализа или ML. Провайдер, да и РКН через ТСПУ может без проблем отследить очень простую схему: если пользователь Х на протяжения месяца держит один единственный постоянный коннект к одному конкретному ip адресу, и прокачивает по нему сотни ГБ трафика, то это ВПН с шансом в 99%.
В этом есть удобство, но в этом же есть и костыль. Если РКН внезапно введет новые ограничения, или банк перестанет пускать пользователей с ASN ДЦ, а доступа к серверу по ssh у вас в данный момент нет, то вы окажетесь в ситуации с неработающим банком и без возможности это оперативно исправить.
Очень интересно откуда у вас анонимность берется в данной схеме? О того, что вы зайдете в свои госуслуги(в которых есть все данные о вас) не с домашнего айпи, а с адреса датацентра анонимности у вас больше не станет. Наоборот, это можно будет использовать для деанонимизации вас и вашего сервера.
Анальный зонд у вашего провайдера уже давно стоит, так же как и хостера, если сервер в РФ. Про шпионов в МАХах сами знаете.
Вот. Сами ведь говорите, что у провайдера все логи есть. Отследить что именно Вася Пупкин из квартиры №10 держит постоянный и единственный туннель, через который идут сотни ГБ, не составит труда.
Каким образом? Если мне через ВПН нужно пустить только телеграм и chatgpt, то я и пущу там только эти два сервиса, а не весь интернет. Если шпион начнет слать запросы к чекерам айпи, все эти запросы полетят напрямую через мой домашний айпи, а не через впн.
Ошибаетесь, cf warp использует ip адреса, принадлежащие датацентрам cf, и никогда не являлся резидентским. Вот прямо сейчас чекнул ip варпа, через который у меня идет трафик на сервере, он принадлежит ASN13335 и определяется как cdn/hosting. И если сегодня банки и кинопоиск не блокируют доступ через warp\asn dc, нет никаких гарантий, что завтра не начнут.
Еще раз. Я не спорю с тем, что ваша схема на данный момент может быть рабочей и даже отчасти удобной. Но на мой взгляд, ваша схема с одним единственным большим туннелем, через который идет вообще весь трафик выглядит буквально как если вы выйдете на городскую площадь с огромной табличкой «я использую впн сервер расположенный по адресу х.х.х.х».