Как коммерческие VLESS-подписки могут «сливать» ваш IP

[Dmitri-D]

нет, добавлять “X-Forwarded-For” никакой сервер посредине не может, если только ваш клиент не использует незашифрованный HTTP трафик. Добавляйте правила по запрету HTTP, разрешайте только HTTPS (TLS) и всё что сервер сможет увидеть - это незашифрованный SNI.

[Phonetastic]

спасибо за советы! очевидно, что это поможет в ряде случаев, но как быть с тем фактом, что подписочный провайдер "отделяет мух от котлет" и при попадании моих запросов в подсети, которые он (провайдер) считает "локальными" - отдаёт им мой IP напрямую?

[Dmitri-D]

запретите все протоколы кроме TLS и проверьте. Я имею ввиду не порты, а именно протоколы. Порты запрещать для этой цели бессмысленно, потому что никто не мешает клиенту посылать plain HTTP в надежде что прокси добавит вот эти самые X-Forwarded-For и при этом использовать tcp/443.

[press_a_key]

TLDR: облачный провайдер сам подставляет ваш реальный IP, при доступе к российским серверам.

В данном случае не по злому умыслу, а по причине экономии трафика и более адекватной работы с российскими сервисами, где зарубежные IP бывают забанены. Но это лишний раз доказывает, что все сторонние провайдеры не дают никаких гарантий анонимности. И их удел - использование их канала как способа проброса до своего VPS, откуда трафик будет идти уже наружу. Потому что надо признать, коммерческие решения часто хуже режутся ТСПУ.

[dartraiden]

все сторонние провайдеры не дают никаких гарантий анонимности

Стоит начать с выяснения того, обещал ли этот провайдер анонимность. Может статься, что ничего, кроме обхода белых списков, он и не обещал и прямой доступ к российским ресурсам преподносится как удобство для пользователя. А то, что пользователь сам выдумал, как работает сервис и его выдумки не совпали с реальностью, это его проблемы.

[korn3r]

Звучит несколько странно.

Вы точно поддержку правильно поняли? Более вероятен вариант что коммерческий впн раздаёт вам конфиг в формате json. У панелей есть 2 формата выдачи конфигов по подписке - просто ключи подключения и json конфиг в котором может быть вшит роутинг на стороне клиента. И вполне может быть что ру диапазоны и всякие domain: ru клиенту прописаны ходить напрямую с себя. Тогда у вас получается схема следующая: запускаете приложение внутри вм, проксифаер перехватывает трафик вм и заворачивает в хапп, маршрутизация в хаппе видит что трафик должен быть прямо и шлет его прямо через интернет вашего хоста, а не через впн.

Маршрутизация из json конфига работает "отдельно" от галочек в настройках хаппа. В json конфиге это маршрутизация непосредственно для ядра.

Проверить просто - в хаппе проверьте не помечен ли конфиг как json (рядом с протоколом) и нажмите на стрелочку справа от сервера чтобы проверить собственно полный конфиг на предмет наличия в нем блока routing

[balamutang]

Более того, такой способ работы — единственный способ выжить прокси в текущих условиях. Потому что как только на какой-то российский белосписочный сервис, кто-то зайдёт с зарубежного адреса - из RKN пойдёт запрос для проверки этого IP-адреса. И как только выяснится, что на этом IP-адресе работает прокси, этот IP-адрес попадёт в чёрный список и соединиться с ним будет уже невозможно.

Поэтому именно так и надо делать: на российские сервисы ходить с российского IP, а на "замедленные" с прокси. Либо иметь два телефона: один только для российских сервисов, другой только для зарубежных.

[korn3r]

не знаю проверяют ли они IP клиентов на сервисах, но в целом зачастую банят зарубежные подсети просто так.

в любом случае иметь что-то прямо полезно в первую очередь тем что в логах оператора у вас не "все идет на такой-то один адрес", а куча трафика на разные сервисы

[Ahalay_Mahalay]

Пока не настроил маршрутизацию таким образом, что Россия идёт напрямую, а то что надо уже через впс, постоянно попадал на блок сервера, а теперь все хорошо, банки грузятся, озон работает, да и нагрузка на впс меньше