а что тогда? воркэраунд нашли?
В общем, шпион не сможет воспользоваться Reality с fake-SNI со своим IP адресом (использовать reverse-proxy).
Почему? sing-box на сервере использует свой DNS для sniffing + routing по SNI, не полагаясь на dst_ip который выслал клиент (потенциально со своим шпионским IP).
Предположение о том, что шпион может гарантированно попасть к своему IP, просто обманув routing rules – судя по всему, было неверным.
Это всё равно было полезным разобрать, чтобы понимать как на самом деле устроена маршрутизация в sing-box.
ну xray тоже, видимо, именно по этому при проверке dns видны адреса той страны, где впска стоит. Правда стоит тогда не забыть в routeOnly поставить false
у вас на сервере стоит sing-box?
Отличное наблюдение, тогда вопрос можно считать закрытым.
Да, мне нравится симметричное единообразие конфигураций, у sing-box намного гибче и архитектурно сильнее реализован DNS.
Поэтому и предпочитаю sing-box вообще везде, он поддерживает 1 в 1 большинство протоколов Xray. И понятная документация в одном месте, изучив полностью которую можно реализовать почти всё что угодно. Правила декларативные и удобно читаемые (DSL). Потребляет меньше памяти.
sing-box сильнее ложится как центральный хаб маршрутизации.
У меня был раньше Xray, но я с него переехал, слишком много silent failure логики и исторического мусора.
А sing-box вообще не запустится, пока всё не будет идеально настроено. Там автор с железной рукой, требует чтобы всё было правильно.
Я правильно понял, что в данной схеме используется лишь один ru vps?
Да, всё верно. Рассчитано примерно на 2-3 пользователя. Если надо больше – делайте балансировку трафика на разные IP как Китае.
Но сейчас, с одного лишь ru vps можно добиться 90% покрытия всей сети интернета. Пробиться к практически любым сервисам (используя лишь WARP + Tor как выбор второго хопа).
на сколько я знаю, на большинствах ру хостингах варп не регистрируется, а если подсунуть готовый конфиг, никуда не может подконнектиться. Я заморочился и установил awg 1.5. Получилось запустить, а у вас как?
В случае с прокси на чистом sing-box все ок. Но вот если запустить через Трон на win и сделать
curl -kv -x "socks5://127.0.0.1:1080" https://youtube.com --connect-to youtube.com::2ip.me
То соединение проходит, правда не на ип-чекер, а на ютуб (редирект). Т.е. ip сервера не сливается, но доступность ютуба - да
Какой раз говорю, конечные устройства должны быть тупыми, не заниматься транспортом для самих себя.
На мой взгляд, конечным устройствам следовало бы быть умными. Выходным узлам при этом лучше оставаться тупым расходным материалом: купил, поднял докер, ушел, и больше времени на его настройку не тратишь — все равно этот айпи забанят не сегодня-завтра. Именно клиент должен иметь сложные правила, перебирая все выходные узлы по одному (кажется это URLTest в sing-box). Изменение правил — а оно в текущих или будущих реалиях будет происходить ежедневно — не требует коннекта к серверу по палевному SSH, ради которого еще и Tor тащить.
Приложения-шпионы лучше запускать в network namespaces, с чистой таблицей роутов (ip rule && ip route show table all), ведущей напрямую к провайдеру, и с дефолтным провайдерским DNS. Это решает кучу проблем: ru-сервисы пропустят трафик с российских домашних IP, а шпионы будут считать, что работают на чистом интернете без VPN. Хотя не уверен, можно ли это сделать на андроиде. Главная цель здесь – иметь per-application-правила. gethostbyname("ntc.party"), выполненный доверенным приложением, и тот же запрос, выполненный максом — это две разные истории, и ответ им нужен разный. То же касается и всей остальной сетевой активности двух категорий приложений: доверенных и недоверенных. На роутере (а тем более на удаленном сервере) такие правила не пропишешь, так как он не видит, какое приложение отправляет пакеты.
Доступность ютуба и прочих ресурсов ты вообще никак не скроешь.
выходным узлам при этом лучше оставаться тупым расходным материалом: купил, поднял докер, ушел, и больше времени на его настройку не тратишь — все равно этот айпи забанят не сегодня-завтра.
Вот с этим тейком я согласен, даже если ты заморочишься и сделаешь идеальную непробиваемую схему, все равно с тобой на хостинге будут соседи, которые “запачкают” подсеть рано или поздно. Если хочется постоянства, надо смотреть в сторону резиденстких выходных нод.
Я не думаю, что РКН только на это смотрит. Огромное количество сайтов хостится на мощностях различных дата-центров. Да, в том числе там VPS\VDS\VPN можно найти, но если бы РКН ориентировался только на это, они бы давно уже перебанили все ASN всех хостеров с первых 50-100 страниц гугла и это решило бы 90% всех проблем по части VLESS-протокола. Но они так не делают, они пытаются детектить сам VLESS.
В принципе, разделение на входной и выходной IP само по себе радикально усложняет задачу. Даже с моими кривыми руками и спаленным айпишником мой первый VPS еще подает признаки жизни. Причем они явно отслеживают связку IP:порт, поскольку на 443 порту отъехало всё давно, а вот на 20 порту работало долго. Потом я создал конфиг на 1 порту и оно тоже долго работало, пока я не начал другим людям ссылки раздавать, после чего оно тоже быстренько всё отъехало в бан. Конечно, я не знаю что там у людей за софт на телефонах крутится, наверняка рядом с V2RayTun запущен тот же Макс, Сбер, Озон и прочий отечественный софт, который всё это быстро палит.
Сейчас арендовал второй VPS, на нем уже изначально 2 IP сделал, поставил дополнительный блок на geoip .ru. Пока что тестирую на ПК, завтра на телефоне дополнительно потестирую. Если отвалов не будет, начну постепенно расширять охват, возможно, получится даже понять что именно палит: количество коннектов до конкретного IP или какой-то отечественный софт.
Dreaght, тут такой вопрос нарисовался: а что делать владельцам статических IP? У меня вот 178.173.19.2 уже много лет арендован у провайдера, причем их оборудование работает в прозрачном режиме, т.е. данный адрес указан на WAN-интерфейсе моего домашнего роутера. В итоге схема подключения выглядит (по моему мнению) так:
- 192.168.1.2 - мой iPhone
- 192.168.1.1 - мой роутер
- 178.173.19.2 - WAN-порт роутера
- 178.173.19.1 - шлюз интернет-провайдера
- ТСПУ
- N промежуточных узлов
- 213.165.59.188 (входной IP на VPS в другой в стране)
- 138.124.6.91 (выходной IP на том же VPS)
Так выглядит эта схема для меня как для человека, поскольку мне известны основные узлы маршрута и я примерно представляю как идет трафик. Теперь предположим, что я включаю VPN на своем iPhone и у меня в памяти висит мессенджер Мах. Как это выглядит для шпионского модуля в нем? Понятно, что он все еще будет видеть LAN IP телефона (192.168.1.2), но какой узел в таком случае будет следующим в маршруте? Внутренний адрес роутера? Адрес на его WAN-порту? Или входной IP на VPS? Или только выходной? Но ведь входной он все равно должен знать, он же есть в маршруте… Помогите разобраться с этим.
Скорее всего адрес туннеля. Типа что то из серых ip. То. Что указано в настройках клмента. И выходной