Где-то давно тут читал, что якобы блокируются исходящие соединения, но не блокируются входящие, найти тот топик не смог поэтому и решил уточнить как с подобным обстоят дела сейчас.
Возможно ли будет, условно, поднять дома (или на российском 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), второй сервер не понадобиться.
