Хостеры обычно выделяют ип из той же подсети, а ркн блочит сразу всю подсеть.
А что если твой входной ип в той же подсети, как у кого-то выходной и он в бан улетает.
Есть проблемка, – общедоступные сети. Непонятно кто какой там пользователь. Да, метаданные хранятся, но не везде можно реально идентифицировать и привязать конкретную сессию к конкретному человеку.
То есть внутренний NAT IP (CGNAT провайдера) может меняться, размывая связку SRC → DST.
Разбираться в этом, конечно, сложнее.
Думаю, не всегда, конкретный WAN – да, но не пользователя как сущность.
Помимо всяких VPN, есть:
- Игры (большой объем трафика, постоянный коннект)
- Стриминг (огромный объем трафика, тоже могут на один IP)
- Торренты (на один IP спокойно)
- Синхранизация диска (на один IP, огромный трафик)
- Корпоративные туннели или к домашнему серверу – сама технология туннелирования не запрещена.
Все они могут идти на один IP.
Факт “много трафика, постоянный коннект к одному IP” – сам по себе мало что дает без реального анализа. Но это всё точечные ручные проверки.
Обычно с WARP тогда пускает. А по умолчанию в схеме через него туннелируется. Да, WARP egress через ДЦ, но это опять же, используется именно резидентами (должен по идее).
У меня в схеме окольный путь подключения через SSH-over-Tor с SSH-onion сервисом.
Ну и можно просто выключить VPN (один раз слить IP – не проблема), чтобы зайти в банк или зайти с мобильной сети.
Ой да, перепутал, я имел ввиду приватность, а не анонимность. Хотя WARP имеет свой anonimity set, против расследования это мало поможет, но для сервисов – уже какая-то анонимность, без учёта fingerprinting’а.
Всё просто – вы сливаете адрес ТСПУ – идет корреляция логов сервиса со внутренним IP NAT (CGNAT провайдера) и в то же временное окно видим к какому ещё IP идут запросы (в туннель). Да, если один большой параллельный туннель – его просто быстрее увидят, но размер такого туннеля не играет роли, это может лишь немного увеличить количество итераций для корреляции, но его всё равно обнаружить не составит труда.
Почему бы тогда не уменьшить размер туннеля?
Потому что это всё равно не спасет от корреляции.
И как тогда защититься от этого?
Не сливать в direct адрес ТСПУ, чтобы корелляционные атаки не имели смысла.
Кстати это может происходить и не в real-time а пост-анализом логов, простыми алгоритмами, не ML. Тут мощностя даже не нужны.
Тогда исчезнет вся магия удаленной маршрутизации и идея “клиенты должны быть тупыми”.
Warp подразумевают установки на клиентские устройства. Да, egress через ДЦ, но он используется резидентами тоже.
То есть его буквально создали именно с целью, чтобы резиденты им пользовались, а не ДЦ. Это ни какая-то там внутренняя оверлей сеть для серверов.
Тогда бойкот. Это блок не на стороне РКН, а сервисов. Нет желания на то чтобы ещё и с сервисами бороться. С РКН ещё ладно, честный враг, но с сервисами – это предательство.
Угу, я просто оптимизирую идею “настраивать маршрутизацию по SSH, а не на каждом устройстве отдельно”.
Раз подключения к одному IP – проблема – можно размывать по разным IP тогда, делая балансировку. Просто сегодня это оверкилл, завтра – видно будет, но я на это бы не ставил ставку. Я ставлю ставку на анализ.
RU-чекеры увидят домашний IP-адрес, а иностранные - IP-адрес эндпоинта Tor. Домашние адреса не будут блокировать (если белых списков нет), в крайнем случае можно через другой прокси гнать RU-трафик.
Я уверен, что будут прикрывать, тем более учитывая то, что WARP блокируют, и то, что это продукт американской компании.
То есть у Вас 80% интернета будет идти через Tor? Спорное решение, однако.
Ведь все эти 80% – потенциальные чекеры.
Если только условные geosite:category-ip-geo-detect блокируются или куда-то в апстрим идут, а остальной интернет напрямую – тогда вот тот самый интернет, что идет напрямую – это и будут IP чекеры в том числе.
В моей схеме хоть и всё равно неизвестный трафик идет через WARP, но я не считаю это панацеей от обнаружения входного IP, т.к это single point of failure.
Его итак блокируют, хотя и раньше я просто с помощью Zapret, наверное фейков, чинил.
А если сервисы начнут – тогда бойкот. Мы оптимизируем борьбу с РКН, а с сервисами бороться ещё – неблагодарное дело. И уступки им делать, ослабляя схему, я не намерен, и вам не советую. Как минимум перестать ими постоянно пользоваться, запускать лишь в полностью изолированном окружении с изолированной сетью.
Tor, WARP, VLESS, хоть другой российский VPS с zapret и XBox DNS - неважно, главное, чтобы иностранные ресурсы были доступны.
Их и имел в виду.
Понял, в целом это почти равносильно второму белому IP в интерфейсе сети.
Только вот я не понимаю смысл этого действия?
Почему бы 99% интернета не видело бы один и тот же ру-warp IP? Зачем сливать direct для ру сервисов? Просто из-за того что ру-сервисы могут заблокировать обслуживание для WARP пользователей?
Если вы про резидентский прокси – это хорошо. Если про свой адрес ТСПУ – уже плохо, т.к можно анализировать логи и всё равно выявить туннель, сколь угодно большим или малым он бы не был.
В моей схеме нет логического подразделения интернет vs ру-сервисы, кроме как DNS-костыль для них, на первом хопе. Как минимум любой трафик до первого хопа должен дойти. А вот уже дальше – свои костыли и хитросплетения для зловредных сервисов.
Конечное устройство, например тостер, не должно знать что какой-то там сервис перестал обслуживать с warp и надо какую-то костыльную логику маршрутизации подключать. Всё должно быть прозрачно на уровне сервера (удаленного шлюза маршрутизации) – все костыли там, а не на клиентах.
Мне кажется, что это уже не вопрос существа (заблокируют или не заблокируют), а вопрос времени. Всё движется в эту сторону, а причин для использования WARP обычными пользователями нет (т. к. он заблокирован), и ещё он принадлежит американской компании, которая в том числе внедряет технологии, мешающие РКН осуществлять свою деятельность (ECH, тот же WARP, к примеру).
Можно свой поднять, если нужно - отдельный от вашего реального домашнего.
В общедоступных сетях (вайфай в метро или кафе) обычно используется авторизация по номеру телефона. Зная номер телефона ничего не мешает идентифицировать пользователя.
Игры не гоняют сотни ГБ трафика на один единственный сервер. Для стриминга обычно используются популярные CDN. Торренты имеют специфичный протокол и десятки подключений, а не vless gRPC к одной точке. Ничего не мешает РКН, заставить компании проходить “лицензирование” для корпоративных туннелей и использовать отечественные методы шифрования, что будет заметно выделять их на фоне остальных впн туннелей.
Он и так знает ваш адрес, ему для этого никакие шпионы не нужны.
У современно юзера могут быть десятки, сотни, а то и тысячи одновременный подключений к разным сервисам. Пытатся искать там корреляции - тоже самое, что искать иголку в стоге сена. Я же вам и пытаюсь донести мысль, что гнать в туннель надо не все подряд, а только избранные доверенные сервисы, которые нужны конкретно вам, а все остальное пускать в директ. Чтобы ваш прокси трафик размывался среди всего остального “легитимного” трафика, а не выглядел как ёлка посреди пустыни. Удачи им в такой ситуации найти корреляции, если у меня весь трафик, кроме ютуба с телегой идет в директ, а доступа к логам телеги\ютуба у РКН явно нет.
А еще warp принадлежит американской компании и заблокирован в РФ. Обычному российскому пользователю нет никакого смысла использовать такой сервис, так же как и ip принадлжедащий ДЦ, кроме как для обхода блокировок.
Хочется посмотреть, как люди будут бойкотировать какой-нибудь банк, где у них ипотека на 10-15 лет. Или приложение магазина, в который они каждый день ходят за продуктами.
Разве у китайцев не стандартная практика пускать местный трафик напрямую? Я очень сомневаюсь что за GFW не додумались воспользоваться своими сервисами для выявления обходов.
Нам нужно что? Подтвердить доступность заблокированных сервисов.
Как? Шпион к ним пробует подключаться.
Доступно = туннель есть.
Как отключить ложные срабатывания? Подтвердить факт, что с конкретного ТСПУ каким-то образом есть возможность подключения к условному Телеграм / WhatsApp / YouTube.
А с ДЦ? Там уже эвристика не сработает, это нормально для всяких ботов на VPS иметь связность с интернетом.
Что ж теперь мелочиться, давайте наверняка уж. GET Запрос к какому-то чекеру отправим.
У меня ведь только заблокированное в туннеле!
Шпион отправит фейк SNI, шпион развернет Reality сервер с “заблокированным” SNI, которым вы наверняка пользуетесь. И IP чекер вернет IP туннеля, пусть и выходного. Ничего, зная реальный домашний адрес, который вы сами сливаете, нехитро будет взять вас на карандаш и анализировать, например, все ASN на какие IP регулярно идут подключения.
Ладно, пойду мастерить мобильный OpenWRT роутер, мой тостер не сумеет развернуть FakeIP.. Ещё и каскадную схему делать, ведь я слил им свои же логи провайдера…
В таком случае, что мешает заворачивать свой трафик в такой “белый” протокол шифрования?
Всякие уникальные отпечатки, ключи, сертификаты…
Которые тут же будут продаваться.
Государство у нас не монолитное. Бюрократия…
Фейк SNI к избранным сервисам – и готово. Шпион в туннеле.
И вот тут начинается гемор: изолирование программ, сети… Устранение утечек, на который Android не оптимизирован, а iOS и прочие конечные устройства – тем более.
Ну ладно, придется тогда мобильный OpenWRT роутер собрать всё-таки, и таскать его в рюкзаке с собой везде…
Я хочу сказать, что пускать в директ шпиона – хуже, чем просто аномалия в энтропии трафика.
То есть для нормальной реализации безопасного доступа шпионам в direct нужен мобильный OpenWRT роутер, позволяющий высокий уровень контроля для firewall сети.
Что, если не WARP?
Резидентский прокси, например свой ботнет мобильный устройств, подключенный к одному серверу, для отправки запросов в DIRECT с мобильной сети. Центральный сервер просто проксирует свои запросы через часть устройств, которые отвечают на сотовом inbound интерфейсе сети, через
{
"type": "urltest",
"tag": "auto",
"outbounds": [
"proxy-a",
"proxy-b",
"proxy-c"
],
"url": "",
"interval": "",
"tolerance": 0,
"idle_timeout": "",
"interrupt_exist_connections": false
}
На каждом устройстве в inbounds.inbound.bind_interface использовать интерфейс сотовой сети.
Пингуя, кто отвечает. Всё реализуется на движке sing-box.
Я попытался представить, как это сделать “универсально“ и для всех - и поправьте меня:
- Допустим - у простых людей стоит xray\sing-box\etc в которых есть условное правило geoip:youtube и geosite:youtube + DOH
- “Злодей” - пытается отправить запрос на “шпионский ip s.p.y.1“ с sni youtube.com
- Теперь вопрос: - каким образом и по какому правилу этот запрос долетит до ip s.p.y.1? Запрос сначала будем проанализирован на sni имя → будет резолв через внутренний недоступный шпиону DoH\DoT\etc →будет вернут совершено иной корректный ip g.0.0.1 - и всё - на этом конец попытки.
Или я что-то где-то упустил?
Ну допустим, узнают они, что есть какой-то там туннель и что дальше? Подменят sni и кинут запрос к чекеру айпи? Так что нам мешает перехватывать подмену sni на сервере и блокировать подобные запросы? Да даже если что-то там и проскочит, выходный ip все равно будет за warp/aws/hetzner. Банить его будут? Так он и так давно в бане.
Выслежить по корреляции? Так сами же говорите, что гос-во у нас не мололитное. У МАХа нет доступа к логам вашего провайдера, так же как и у провайдера нет доступа к логам МАХа. А искать корреляции без логов бесполезно, у юзера могут быть сотни или тысячи одновременно активных подключений, удачи разобрать что там с чем связано.
Лицензированние таких протоколов на серверах только для юр.лиц, а не физиков.
Найти и заблокировать “аномалию“ в разы проще, чем вычислять айпи впн сервера через шпиона. Особенно, если этот самый айпи закрыт за каскадом впн\варпом.
Ну т.е будем конструировать велосипед, который вообще ни на какую массовость не претендует? Тогда уж можно и свой самописный протокол впн написать, чего уж мелочится.
Далеко заходить не будем, пол интернета за CDN, резолв вернет точно такой же IP.
Они на ТСПУ миллиарды денег тратят, заблокировать не могут, а вы собираетесь это у себя на сервере сделать))
В общем, пусть блокируют аномалию, посмотрим, были ли Вы правы. Своими силами всё равно сейчас доказать ничего не получится. Я тут им кучу идей накидал, уверен сотрудники РКН это читают, посмотрим, реализуют ли они этих шпионов как я предложил. Логи провайдеров у них есть, логи сервисов, они тоже заставят получать. Две точки наблюдения.
Тогда зачем эта схема вся, если пока ничего не доказано?
Всё равно, удаленный шлюз маршрутизации – это про удобство. Основное же зерно статьи в минимальном разделении входного / выходного IP.
- Во-первых не весь трафик получается маршрутизировать через WARP.
- Во-вторых, упадет WARP, вдруг понадобится куда-то в другой апстрим маршрутизовать, а он оказался скомпромитирован…
- В-третьих ошибетесь… им один раз джекпот сорвать, ваш IP узнать, вам вечно по тонкому льду идти.
- В-четвертых, Cloudflare может быть скомпромитирован, на них вроде как стоят ТСПУ (поправьте если не так), которые с радостью сожрут ваш IP целиком и полностью.
WARP / прочий апстрим – дополнительный слой защиты, а не панацея. То есть будет как минимум два.
Две точки наблюдения вместо одной.
Так в некоторых регионах БС на мобильной сети так и реализованы, нет разве? Смотрят на соответствие sni и ip, если sni vk.com а ip ведет на сервер в германии, то сбрасывается подключение.
Даже если нет и даже если откатят инициативу, уверен, втихаря сайты всё равно будут сливать. Рунет в любом случае теперь зашкварен. Как минимум идеологически.
Теперь любой православный сайт “стучит” на пользователя
Зайдя на него мы получаем в итоге блок по ip/cidr и много чего лучше
С какой точки не возьми, все равно потребуется свое, родное..
Но там будет как обычно 2.5 дровосека .
Впрочем повышая ставки РКН все равно получит победу и в итоге 90% рунета будет под колпаком ..
Не нравится задержка, ну сидите в чебурнете.
А, не, я имел ввиду детект фейка, например с помощью TCP reassembling. Но это не претендует на массовость, не так-ли. А моя схема – претендует, как минимум потому что решает 100% сегодняшних проблем.
Сливают они пока-что только WARP в схеме. А так да, IP датацентра они сливали и до этого ещё. Мой так сначала душили, потом заблокировали.
Эволюция щита и меча. Мы всегда на шаг впереди. Но да, всё меньше и меньше народу сможет пробиваться в интернет, согласен.
Здесь схема как раз в том, чтобы не весь трафик пускать в WARP, и не весь в DIRECT. В Direct только доверенное, там где важна задержка.
Люди просто умудряются костыльными путями решать проблему, которая решается элегантно – удаленной маршрутизацией. Всякие байки про объем трафика – пока просто байки, посмотрим. Здесь просто фундаментальные утечки устранены (которые требуют координации двух точек), а не одна точка наблюдения и сидеть сортировать объем трафика, которая по совершенно разным причинам может казаться “аномалией”.
{
"log": {
"level": "info",
"timestamp": false
},
"dns": {
"servers": [
{
"tag": "dns-remote",
"type": "https",
"server": "8.8.8.8",
"detour": "proxy"
},
{
"tag": "dns-direct",
"type": "udp",
"server": "8.8.8.8"
}
],
"rules": [
{
"domain_suffix": [".ru", ".university"],
"server": "dns-direct"
},
{
"rule_set": [
"geoip-ru",
"geosite-ru"
],
"server": "dns-direct"
}
],
"final": "dns-remote",
"independent_cache": true
},
"inbounds": [
{
"type": "tun",
"tag": "tun-in",
"mtu": 9000,
"address": ["172.19.0.1/28"],
"auto_route": true,
"strict_route": true,
"endpoint_independent_nat": true,
"stack": "gvisor",
"sniff": true
}
],
"outbounds": [
{
"type": "selector",
"tag": "proxy",
"outbounds": [
"hysteria2",
"vless"
],
"default": "hysteria2",
"interrupt_exist_connections": true
},
{
"type": "vless",
"tag": "vless",
"server": "ip",
"server_port": 443,
"uuid": "uuid",
"tls": {
"enabled": true,
"server_name": "sni",
"utls": {
"enabled": true,
"fingerprint": "chrome"
},
"reality": {
"enabled": true,
"public_key": "public_key",
"short_id": "short_id"
}
},
"packet_encoding": "xudp"
},
{
"type": "hysteria2",
"tag": "hysteria2",
"server": "ip",
"server_port": 443,
"password": "password",
"tls": {
"enabled": true,
"server_name": "sni"
}
},
{
"type": "direct",
"tag": "direct"
}
],
"route": {
"rules": [
{
"port": 53,
"action": "hijack-dns"
},
{
"domain_suffix": [".ru", ".university"],
"outbound": "direct"
},
{
"rule_set": [
"geoip-ru",
"geosite-ru"
],
"outbound": "direct"
}
],
"rule_set": [
{
"type": "remote",
"tag": "geoip-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/hiddify/hiddify-geo/rule-set/country/geoip-ru.srs",
"update_interval": "120h0m0s",
"download_detour": "proxy"
},
{
"type": "remote",
"tag": "geosite-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/hiddify/hiddify-geo/rule-set/country/geosite-ru.srs",
"update_interval": "120h0m0s",
"download_detour": "proxy"
}
],
"final": "proxy",
"auto_detect_interface": true,
"default_domain_resolver": "dns-direct"
}
}
Я правильно понимаю, ты предлагаешь что-то вроде такого только плюс warp на дедике подключать (кроме там ютуба или еще чего то трафикозатратного)?
Ну и плюс десинк входящего айпи с выходящим
Tl;dr чтобы вам не пришлось. Есть некие опасения - местами обоснованные, местами скорее гипотезы. Сводятся они к тому, что “российские приложения и сайты могут начать палить VPN различными способами”. Есть известные методы обхода этих опасений (split tunneling/app etc). Но автору они не нравятся в силу ряда важных причин, т.е. “не АРХИТЕКТУРА”, он предлагает нечто своё. Как так вышло, что в схеме с_архитектурой есть явные и очевидные с ходу (а не гипотетические) проблемы, например, один РУ сервер, куда и идёт практически весь трафик (!), на протяжении темы остаётся неясным. И то, что у кого-то когда-то подобным образом отлетал сервер - это, конечно, “байки”.
Без обид, но пока всё это напоминает чела, который носился с портабле тором и предлагал всем качать через него торренты и смотреть ютуб. Ну, может, на немного другом уровне.