Сломался у меня в очередной раз VLESS+Reality. Уже два раза такое было, помогала смена маскировочного домена или fingerprint. Но в этот раз он сломался совсем. Не работает ничего. При этом, это не полная блокировка по IP:Port, сайт на nginx на том же порту открывается без проблем. tcpdump показывает, что принимаемый на сервер ClientHello пакет достаточно сильно отличается от отправленного. Отличается размер и внутренние поля: первое измененое поле - это второй байт в пакете: IP TOS, он с 0x00 меняется на 0x28. Далее, IP Leghth (очевидно), TLS Length, Client Random, Cipher Suites меняются местами и Extensions не совпадают. Этого достаточно, что бы REALITY отбрасывал эти пакеты: [Info] transport/internet/tcp: REALITY: processed invalid connection from 127.0.0.1:45010: failed to read client hello
Покопался с XHTTP и тоже не удалось заставить работать уже проверенную конфигурацию. Пока сильно не менял, может поможет TLS с Certificate Pinning, но REALITY похоже, всё.
провайдер? регион? моб проводной? риалити селф стил или обычный?
Никак он не ломает ни Reality, ни XHTTP, ни VLESS. Твой inbound IPv4 утёк к шпионскому сервису, который донёс твой IP Роскомпозору и тот его забанил на всех ТСПУ.
Решение - разделить inbound / outbound IPv4. Предыдущий забаненный использовать как outbound IPv4, оставить дефолтным, купить новый белый IPv4 и поставить в inbound.
Да, я понимаю, что я так уверенно об этом заявляю, но у меня очень высокая уверенность на счёт этого.
Вы с этим сами сталкивались? Вы уверены что бан не из-за тор релея или ватсап прокси? Айпи адрес не помешало бы увидеть.
В инете слишком много реалити прокси которые дико палятся но их не трогают, но при этом банят ваш айпи адрес
Да, до этого постоянно были периодически обрывы. Тогда плевался на провайдерский NAT, мол захлебывался и чинился, когда я менял SRC IP (при переключении на другой Wi-Fi из той же подсети).
Они то-ли от мой ACK серверу не показывали, то-ли ACK сервера не доходил мне.
Потом вообще глухой бан inbound IPv4.
Всякие Tor релеи и прокси я не поднимал у себя. Тогда классификацию типа “сервис увидел мой inbound IPv4” сводим к “любой сервис может шпионить” как я уже сказал.
А потом как только сменил inbound IPv4 и заблоканный IPv4 пустил в outbound - так никаких обрывов больше нет. Тут уже обсуждали в соседних темах ситуацию с MAX. Но я даже им не пользовался, значит какие-то другие сервисы шпионят тоже.
Давать айпи адрес вы отказываетесь?
Какой IP? inbound IP? Чтобы что?
Ну начинается. Должно быть понятно сразу что для проверки. Чем больше слов без дела тем больше у меня уверенности что у вас воображение разыгралось, потому что никаких доказательств не даете. Если и дальше ничего не будете предоставлять то лучше промолчать до того как кто-то более детально проанализирует
Вы же понимаете что я себя моментально этим деанонимизирую? Ничего у меня не разыгралось, смысл мне тут врать.
Я кучу раз проверял через Wireshark, запускал SSH over Tor на и на сервере tcpdump с real-time показом через netcat в Wireshark, и на клиенте. В моменты обрывов клиент спамил ACK, а сервер на него послушно отвечал. Но до сервера мои ACK не доходили. В этом и обрывы все были.
И обойти эти обрывы я мог сменив Wi-Fi / WAN точку в моей провайдерской подсети. То есть походу ломал им SRC → DST связку. Но после глухого бана в конце они забанили мой inbound IPv4 на всех ТСПУ.
Угу.
Почитайте мои комменты, я еще ни разу не писал “айпи 1.2.3.4 используется пользователем нтс с ником qwerty”. Если не хотите ничего давать то предлагаю закончить. Буду ждать пока мой впн которым пользуюсь уже полтора года (в т.ч. ру сервисами) отлетит
Я уже сам всё проверил, доступ к VPS отлетел с разных локаций, с “проводного” интернета, с сотовой, с сотовой и домашней в другом регионе. На счёт глухого IPv4 бана я чёт соврал, на самом деле только по 443 порту недоступно подключение (как минимум). По SSH - доступно, но ненадолго, потом отваливается.
Не в обиду, но IP я не стану палить здесь, я не говорю что Вы деанонимизируете, любой сможет.
Может IP репутацию какую-то имеет уже. Может под самого себя маскируется (под сервис с хорошей репутацией).
Ну так в чем проблема написать в лс?
Про 16кб блок и триггер блоки в курсе?
И про сиб блок еще*
В курсе, но я не за CDN. 16кб блок по “вражеским” CDN обычно действует. У меня статический IP.
Хз, я не в Сибири
А, там retransmission что-то такое было в Wireshark. А с 16 Кб блоком вроде сначала идет трафик потом RST после 16 Кб. А у меня не так, вроде ACK/Dup-ACK или типа того было, в перемешку с RST. Хотя возможно это клиент просто долбился. Кстати возможно, про 16 Кб. Может клиент реально просто долбил снова и снова новыми подключениями. Надо будет проверить попробовать.
UDP: сейчас скину dump
UDP2: блт, облом, как на зло, я просрал доступ туда где я это сохранил
этот блок распространился по другим регионам. Недавно увидел его на провайдере планета05 к серверам fdcservers (напоминаю что он срабатывает если открыть примерно 12 тлс потоков за короткое время)
https://habr.com/ru/articles/1010336/
Не RST, соединение просто висит.
Прочитал статью, нет, не похоже. Во-первых я почти никакого трафика не генерировал в это время, во-вторых при отвалах отваливался и доступ по SSH в том числе. ClientHello доходил, просто сервер мои ACK не видел, а клиент ими долбился.
UDP: Вспомнил, при глухом блоке потом RST от лица сервера ко мне, и от моего лица к серверу шли. Короче там ТСПУ 100% подменял это.
Он действует не только по CDN, а по целым диапазонам у зарубежных AS. Неважно, CDN или не CDN. Обычные VPS у Hetzner (и не только) тоже подвергаются 16КБ блоку.
Ясно, но у меня не зарубежный хостер и не CDN. Российский. Так-что 16КБ вряд ли, симптомы не совпадают. А вот подмена RST - это уже факт. Разве возможно, чтобы сервер видел от меня RST, а я в это время видел от сервера RST? Понятное дело что ТСПУ развлекается.
Айпи я так и не увижу. Ладно, последнее - вбей его в bgp.he.net и проверь, не относится ли он к cogent