Связность между компьютерами в одной сети обычно обеспечивается использованием внутренних IP адресов, если мы говорим про взаимодействие внутри одного сервиса.
По поводу звонков согласен, но обычно 24/7 люди не звонят. Докапываться будут ли - не знаю, но это вполне возможно, особенно если это станет массовым явлением.
офф-топ
Сопоставить как?
Спросить у другого ведомства, которое знает связь “номер телефона” → паспорт → ISP
То есть:
И потом:
Отсылка к ранее обсуждаемой идее железной привязке прокси к только заблокированным userspace приложениям (которые по идее не могут являться шпионами).
К чему это?
К тому что IP обнаружен (через межведомственные связи), и потом идет анализ всех логов ISP на этого юзера.
И ещё:
Отсылка на идею “ру сервисы → direct; ip checkers → туннель”. Хоть тут и IP (если вы разделили) не узнают напрямую, IP ISP → логи всё равно будут доступны.
Зачем всё это? Зачем эти отсылки?
Подводка к:
Так как мы обсуждали full-tunneling vs split-tunneling идею, так?
Если вы не поняли конкретный фрагмент текста – могли бы вежливо попросить объяснить, а не начинать вот это всё… Я бы с удовольствием всё объяснил.
Я не просил вас резюмировать плюсы и минусы Full-Tunneling VS Split-Tunneling .
>Так как мы обсуждали full-tunneling vs split-tunneling идею, так?
нет, не так.
Я еще раз повторяю - я не хочу спорить с chatgpt, потому что это бессмысленное занятие в принципе - его не переспорить, только засирать ветку флудом. Для начала научитесь писать тексты сами.
офф-топ
Я не только на вашу цитату ответил. Там потом ещё на следующую цитату был ответ:
Такие сервисы зачастую не используют единственный IP, а множество IP в одном AS (и то не факт).
C вами – нет. Со многими прочими участниками обсуждения – да. Поэтому я и решил отрезюмировать всё рассуждение, использовав все аргументы обоих сторон. Моё резюме было для всех, а не для вас персонально.
Всё, тема закрыта. Научитесь разговаривать с людьми
Я вот не пойму в чём прикол искать sni через этот сканер. Вот чекнул я свою подсеть и там такие же додики как я сидят на самых рандомных сни, даже на яндекс и макс есть несколько человек. Это же не реальные домены, а фейки таких же отчаянных террористов-обходчиков блокировок.
Я вот прочитал первое сообщение темы несколько раз. Пытал ии, и все равно не догоняю. Мы пускаем весь трафик всех приложений в туннель. Там идёт маршрутизация. Правильно ли я понимаю, что все российские запросы будут идти через warp? Тогда если условное приложение пятёрочки делает актив пробинг до чекера амазон, как в этом случае обработается запрос? Он справедливо отдаст ip vps и скормит пятёрочке. Там уже как бог пошлёт… А если мы делаем per app, тогда прмложение пятёрочки каким образом узнает о существовании каких либо входных и выходных адресов если ей разрешено ходить только direct? Из соседней темы про макс это приложение будет показывать только что поднят туннель. Или эта схема придумана из-за невозможности сделать per app на ios у топикстартера?
Знаете в чём прикол Reality? В том что оно маскируется под reverse-proxy. Несовпадение DNS, и смысла “хостинг → сервис” – норма.
Клиент не проксирует запросы к реальному backend. А вот цензор – да.
Защита от пассивного наблюдения, без ключей – просто reverse-proxy к сайту, с ключами – скрытый канал. Нормальное поведение браузера.
Напоминаю, reverse-proxy не запрещены. И цензор не может по эвристике “ну… это… типа… странно… зачем тут два идентичных SNI…” судить ничего и более того, вручную ничего не делает. Самое главное – защита от пассивного и активного пробинга (автоматического).
Не российские, а именно неизвестные.
Через тот же WARP.
Это вы подразумеваете, что запросы на честном слове не утекут мимо “per-app”, а на деле это не полностью закрывает уязвимость и вот шпионы как раз туда будут и бить, в обход этого. Ошибетесь, это вопрос времени.
Из-за того что клиенты должны быть тупыми, и они все содержат шпионы, и люди криво закрывают утечки, причем устройства и версии Android у всех разные со своими уязвимостями и дырами. Клиентские устройства не предназначены для того чтобы знать о враждебности сети. И благо Apple заставляет вас делать нормальную инфраструктуру, не давая возможности наивным создавать дыры в безопасности.
А вот шлюз – умным. Централизованный контроль над политиками сервисов и перенос точки наблюдения (на сервер, а не дырявые устройства и ISP/ОПСОСов)
Вам что важнее, один раз нормально сделать, включить VPN 24/7 и наслаждаться свободным интернетом, причем ваш iOS будет доволен – всё работает прозрачно и без костылей ИЛИ сидеть настраивать каждое устройства и надеяться что все-все дыры лично вы со своими знаниями их закрыли? Это я молчу ещё про то что домашний IP не стоит сливать шпионам из-за образующейся координации и синхронизации шпионских-модулей на крупных сервисах + ТСПУ.
О каких уязвимостях идёт речь? Подробнее пожалуйста
Да я уже сто раз везде про это написал. Придется опять сюда дублировать несколько уязвимостей которые лично я нашёл (и-то просто не слишком глубоко в это вникая и исследуя):
- CustomTabsIntent – создание процесса используя дефолтный в системе движок браузера с UID, отличающимся от вызывающего процесса. Это, например, может использоваться для открытия окна аутентификации – не будет странным, и используется много где, не так ли?
- Знаете “Open in browser” кнопки? MITM редирект на сервер шпиона, затем перенаправление на туда где юзер хотел. Уже используется, например, в YouTube когда вы кликаете по рандомным ссылкам, сначала на сервера YouTube, потом туда куда хотел юзер.
Сработает, если дефолтный браузер под VPN (типичный сценарий).
На iOS:
Туннель VPN при Shortcuts автоматизации поднимается после того, как приложение может успеть сделать запросы через предыдущий интерфейс сети.
Для этого не нужна координация с ТСПУ. И вообще таких дыр много, я не исследователь безопасности ОС, но понимаю, что все клиенты – потенциально дырявые.
Если будет координация и синхронизации с ТСПУ – чем это грозит писал выше.
Можно сделать 2 браузера. По умолчанию будет идти в директ. Можно во второй профиль сунуть все российские приложения и там будет болтаться свой хром. Как с помощью варпа заходить на банковские приложения? Антифрод еще не банит за такое?
Вы все всё время предлагаете ловить тараканов по одному. Делайте со своими дырявыми устройствами всё что хотите. Ну не хочется сделать элегантно и правильно – сидите с этими всеми неудобствами и уязвимостями, в ввиду своих узких знаний (вообще речь про всех) наивно надейтесь на то что вы умнее цензоров (которые собаку на этом съели).
На любую известную уязвимость найдется фикс. Но на незвестную (лично вам) – только после того как ваш туннель уже съел РКН. И вы будете в эти кошки мышки играть вплодь до рута Android. И под каждое подключенное к туннелю устройства – свои собственные костыли и неизвестные (опять же вам с вашими знаниями) дыры.
А я буду просто нормально пользоваться устройствами, которые делают одну вещь хорошо – userspace изоляция, а не изоляция сети. И удаленным центральным шлюзом (или локальным – например OpenWRT роутер) маршрутизации, который на 100% создан для того чтобы и решать все эти утечки.
У меня нормально работают и госуслуги, и Сбербанк. Всё через WARP. Если вдруг заставят вас ослабить свою схему, например, чтобы вы наивно стали пускать в DIRECT – не делайте этого, это их хитрая манипуляция. Политики сервиса решаются на самом шлюзе маршрутизации вторым хопом, и не через домашний IP с того куда в туннель идут запросы.
вообще можно предлагаемую в теме схему чуть усложнить и добавить вместо варпа выходную ноду-резидентский прокси. Например, поставить в квартире у друзей-знакомых banana pi подключенный реверсом к вашему серверу. Можно даже несколько поставить в разных местах и выбирать их рандомно, получится сорт оф персональный тор, и все выходные ноды с резидентскими адресами - не триггерят банки.
Абсолютно правильно. Политикой сервисов занимается сетевой шлюз маршрутизации для выбора второго хопа (upstream), но до первого хопа неизвестные запросы должны доходить гарантированно.
Я уже думал над этим, только вот надо какой-то протокол, позволяющий двунаправленно инициализировать запросы (endpoint в sing-box – который и inbound и outbound, чтобы VPS хаб мог проксировать через них). На данный момент поддерживаются WireGuard и TailScale (организующий мэш поверх WG), пробивающий NAT (но с подключением к VPS не нужно).
Создать такой свой личный ботнет, через который VPS хаб мог бы для части сервисов (запрещащий WARP) проксировать запросы. Но не вместо WARP, а для части сервисов уж лучше, схема как раз это позволяет и подразумевает.
Часть → Tor
Часть → рез. прокси
Остальное → WARP
Я хз насчет синг-бокса, но xray-core умеет в реверс подключение на vless конфигах. Режим Portal/Bridge. То есть клиент с banana pi за провайдерским натом цепляется к серверу как клиент, а потом сервер может гнать через него трафик в любую сторону.
Получается Ru кидать в реверс обратно в Россию на свой сервак, избранное в впс, остальное в warp. Только опять надо строить туннель до дома , чтобы не палить свой ip.
Вы рано или поздно отхватите бан от ркн за 100% трафик на один ip, это вопрос времени : )
Ну, это ваши домыслы. Посмотрим. Без координации двух точек наблюдения, то что используемый туннель – именно exit outproxy.
Факт.
Может хотя бы N нод прикрутить и по ним трафик с клиентов размазывать, а там дальше уже как угодно с них ходить куда надо и как надо 
В общем вопрос важный, но все заворачивать на один сервак лично я стремаюсь.
Надо подумать над компромиссными архитектурами.
Откуда факт? С чего вы взяли, что туннель – outproxy, а не что-то другое?
В Китае делают балансировку трафика, но смотря для скольки человек. Если 2-3 – одной хватит.
Всё не обязательно, bittorrent -> direct. Какие-то белые списки (если вы уверены в них) – можно тоже в direct (с ПК).
В общем, у меня рассчитано на узкий круг лиц, а не на 100 человек. Надо больше – делайте балансировку трафика как в Китае.
100% + IP – вообще мало о чём говорит. Если со второй точки наблюдения подтвердится что это именно туннель – тогда да, outproxy tunnel обнаружен. Одной мало.
Факт что это мои домыслы