Где-то давно тут читал, что якобы блокируются исходящие соединения, но не блокируются входящие, найти тот топик не смог поэтому и решил уточнить как с подобным обстоят дела сейчас.
Возможно ли будет, условно, поднять дома (или на российском VPS провайдере) какой-нибудь WireGuard сервер, подключиться к нему из-за границы и через зарубежного пира гнать трафик? По скорости не должно сильно ударить, да и поднять такое соединение довольно просто, например Headscale (как и Tailscale ре-имплементацией которого он является) имеет такую функцию из коробки
Да - чаще всего “обратные” подключения не фильтруются. Иногда все-таки бывает, но там скорее косяки настройки ТСПУ или какие-нибудь особенности построения сети хостера/магистралов. Если они определяют тупо по GeoIP назначения то могут быть некорректные записи в базе, а если именно по “направлению”, то там иногда сам черт ногу сломит как и куда трафик ходит. Поэтому если имеет место вариант 2, то UDP-based протоколы типа Wireguard не советую - из-за самой специфики работы UDP там часто непросто определить “направление” и риск блокировки по-прежнему есть.
2 сервера в РФ, в разных ЦОДах (в разных городах) - к обоим есть доступ с из-за бугра по openVPN точно, скорее всего по остальным протоколам тоже.
Так что видимо как повезёт. Но блокировки в обратную сторону должны быть скорее исключением, т.к. на это надо условно в два раза больше фильтрующих мощностей.
UPD: недостатком схемы является проблема не со скоростью, а с задержкой - один туннель идёт от клиента до входной точки в РФ, второй - до (или скорее “от“) сервера за бугром, что приводит к тому, что каждый пакет шифруется/дешифруется ещё раз ;(
Звонил по Telegram в разных комбинациях с Wi-Fi и мобильных операторов РБ и РФ. Снаружи РФ ничего не нужно. Внутри РФ nfqws на Android-смартфоне. Качество связи отличное.
А вот за квартиру уже не смог заплатить - ЖКХ РФ блокирует входящие.
Это уже совсем другое. Телеграм делает исходящее подключение с обеих сторон. Сайт жкх блокирует зарубежные айпи на своей стороне (защита от хакеров), это не тспу делает
я думаю утверждение неверно понято. имеется ввиду цензор не проверяет пакеты которые возвращаются с забугра.
ваш прокси конект с серваком это не есть загадочная труба, направление у которой когда-то там лишь однажды вначале определяется. если речь за еще не весь заблокированный tcp то тут на протяжении всей сессии будут от вас исходить пакеты, и будут приходить к вам, это неизбежно. перефразирую: тспу не особо интересно что возвращается, ему интересно откуда и как вы запрашиваете. если он заблочит запрос, то и ответов не будет. хотя при 16-20 кб блокировке он как раз блочит ответ а не запрос, но справедливости ради опять же на базе того куда вы сходили.
что касается приведенной схемы - это может работать да, но оно не про указанный факт. в этом кейсе все равно будет два двунаправленных соединения, от вас к первому серверу, и от первого сервера ко второму.
и на первом соединении цензор все равно просматривает куда вы ходите, и может вас там отрезать, просто пока еще этого не делает (если ток не белые списки). а на втором конекте либо не стоит тспу, и данные можно перекидывать как угодно, либо стоит но с менее жесткими правилами.
Некоторое время у меня был доступ к ВПСке заблокированной по IP. Пакеты отправленные от VPS прекрасно принимались на домашнем роутере, но все дропалось в обратную сторону. (и кого тут защищает ТСПУ?). По фану даже собрал схемку на чистом WG где нисходящий поток шел напрямую, а восходящий пропускался через вторую незаблокированную ВПС.
Прекрасно работало. По сравнению полным заворотом через промежуточный релей в рф такая штука должна увеличивать скорость, хотя, конечно, дома нужен публичный IP-адрес.
Скорее всего признаком сработавшей односторонней блокировки является остановка TCP ровно после 16кБ. Сервер отдает буфер, останавливается и ждет подтверждения приема (ACK), которое так и не будет получено.
Идею для абонента за GCNAT тут писал (но в том случае переставали приходить пакеты от сервера к клиенту), но тестировочную програмку, которая будет мусор слать, пока лень писать.
Да, хорошая идея! Можно попытаться отправлять небольшие мусорные дейтаграммы от роутера к серверу для открытия NAT. Однако, есть достаточно высокая вероятность того, что NAT изменит номер порта и такой трюк не сработает.
Это будет не простенькая программа, а что-то вроде кастомного форка headscale. Нужен управляющий сервер, который будет координировать отправку пробивающих пакетов и учитывать порты с обоих сторон, но при этом туннель должен строиться строго в направлении VPS>>>HOME, чтобы не стриггерить блокировку. Вообще, можно попробовать детально изучить headscale/tailscale, может их можно настроить таким образом даже без форка.
Если блок срабатывает каждый heartbeat, то realtime интернет не получится, только с пингом в 1 минуту.
Если блок 16-31 КиБ безусловный, то можно менять исходящий порт для новой сессии (для посылки TCP пакетов можно использовать библиотеку npcap), второй сервер не понадобиться.
Трудно точно сказать, что он искал, но скорее всего если бы бот обнаружил что-то похожее на прокси или впн адрес улетел бы в блок. Вероятно, поскольку нисходящие пакеты невидимы для ТСПУ, то логика работы фильтров другая - активное зондирование. Это сработает так быстро, но тоже достаточно эффективно.
По-моему представлению блокируют только адреса мостов тора. Остальные виды блокировок по подсетям/AS действуют, если проследить репорты на этом форуме (тех хостингов, которые не выполнили закон о приземлении). Бот ГРЧС и без соединений сканит интернет.
Перебирает сканер приложений, пока не найдет вариант с ответом. Это как раз не удивительно. По информации абуз баз с этих адресов не только сканируют все порты и вызывают демонов, но и проверяют на уязвимости.
Санитары леса. Причем всего леса, а не только своего загончика.
