Как обойти кэш провайдера

Обновлено: 04.07.2024

Такое случается, и довольно часто. Многие интернет-провайдеры запрещают своим клиентам пользоваться торрентами.

Скорее всего для того, чтобы защитить себя от DMCA-уведомлений (Закон об авторском праве) и писем с угрозами от адвокатских контор. И также в соответствии с законами, запрещающими распространение торрентов.

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

Содержание

Дисклеймер: Мы в CactusVPN ни коим образом не поощряем нарушение авторских прав и использование торрентов. Тем не менее, мы понимаем, что многие люди получают доступ к нужной им информации (развлекательный контент, рабочие файлы, учебные пособия и т. д.) только благодаря торрентам.

Могут ли интернет-провайдеры вычислять торрент-трафик?

Зачастую это возможно, если вы используете устаревший торрент-клиент.

Но как бы ни шифровался, например, трафик Bittorrent, провайдер может выявить его по следующим признакам:

Несколько одновременных потоков загрузки.
Множественные TCP-подключения.
Большая нагрузка на канал интернета.

Также может быть использована технология DPI (глубокий анализ пакетов) для анализа незашифрованных DNS-запросов. Так и обнаруживается использование торрентов.

Провайдер также может нанять специализированное агентство по мониторингу, которые будут выявлять IP-адреса провайдера среди сидов и пиров. То есть тех, кто скачивает и раздает торренты.

Блокирует ли провайдер торренты?

Самый простой способ узнать это – попробовать скачать что-нибудь на торрентах. Если у трекера достаточное количество сидов, но при этом скорость закачки крайне мала, скорее всего, провайдер блокирует торрент-трафик.

Попробуйте загрузить файл напрямую, одновременно c работающим торрент-клиентом. Если загрузка напрямую идет стабильнее и быстрее торрента, то проблема, скорее всего, на стороне провайдера.

Если вы не можете получить доступ к некоторым торрент-сайтам, то провайдер, скорее всего, блокирует и их.

В сети можно найти онлайн-инструменты, которые позволяют обнаружить блокировку провайдера, однако они давно не обновлялись и вряд ли будут хорошо работать.

Небольшая заметка

Порой проблема может быть не в провайдере, а в пирах, которые сами блокируют или ограничивают объём трафика. Подобное происходит если после загрузки контента вы его не раздаёте.

В таком случае следует увеличить максимальное количество пиров и/или подключений. И не забудьте проверить настройки пропускной способности торрент-клиента.

Если это не помогло, значит проблема кроется в провайдере интернета.

Как провайдер блокирует торренты?

У каждого провайдера свои методы, можно лишь строить догадки. Как правило, используются следующие методы:

Ограничение доступа к торрент-сайтам при помощи DNS-фильтрации, блокировки IP или URL-адресов.
Использование технологии DPI для анализа трафика и обрыва торрент-соединений.
Блокировка портов BitTorrent (например, TCP-порты 6881-6889). , которое отбивает всякое желание пользоваться торрентами.

Как можно разблокировать торренты (7 способов)

Учитывая вышесказанное, позвольте рассказать о решениях, которые позволят вам свободно пользоваться торрентами. Некоторые, кстати, помогут и с доступом к заблокированным торрент-трекерам.

Список составлен по степени эффективности и удобства методов.

1. Использовать VPN

VPN-сервисы, такие как CactusVPN, – лучший способ наслаждаться торрентами и не беспокоиться о вмешательстве провайдера. Мы предлагаем услугу, которая позволяет «скрыть» ваш IP-адрес и применить сквозное шифрование. Как это работает?

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

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

Ищете надёжный VPN?

Попробуйте CactusVPN – мы предлагаем высокоскоростные серверы с поддержкой торрентов и неограниченной пропускной способностью. Серверы имеют поддержку протоколов IKEv2 и L2TP/IPsec и обеспечивают стабильно высокую скорость.

А в случае обрыва VPN-соединения вам поможет опция Kill Switch, которая работает как на общесистемном уровне, так и на уровне приложения. И не нужно беспокоиться о том, что провайдер поймает вас с поличным.

Специальное предложение! Получите CactusVPN за 2.7$ в месяц!

И как только вы станете клиентом CactusVPN, у вас будет 30-дневная гарантия возврата денег.

2. Использовать прокси

Прокси-сервер скрывает ваш IP-адрес так же, как VPN. Он точно поможет разблокировать торрент-трекеры.

Однако не все прокси умеют разблокировать торрент-трафик.

Потому что многие из них не используют шифрование. Даже в тех случаях, когда оно используется, оно недостаточно надёжно, что делает его уязвимым для технологии DPI.

Но вместо того, чтобы платить больше и мучаться с неудобным интерфейсом, почему бы не воспользоваться услугами VPN-провайдера, чьи серверы дублируются прокси? В CactusVPN вы можете использовать безопасные VPN-серверы в качестве прокси без дополнительной платы.

3. Зашифровать протокол

Если вы не хотите использовать VPN, можно воспользоваться встроенным в торрент-клиент шифрованием. Обычно необходимые настройки можно найти в разделе: Инструменты > Настройки > BitTorrent .Так можно настроить режим шифрования используемого торрент-клиента. Чтобы включить шифрование, необходимо выбрать один из следующих вариантов: Разрешить шифрование или Требовать шифрование.

Важно отметить, что у данного решения есть определённые недостатки:

4. Использовать порт 80

Чтобы настроить торрент-клиент на использование данного порта, обычно достаточно перейти в раздел Инструменты > Настройки > Подключение. Укажите 80 в поле порта, и отключите UPnP вместе с NAT-PMP.

Можно попробовать найти и другие порты, которые провайдер не заблокировал.

5. Использовать мобильный интернет

Существует два варианта:

Задействовать мобильный интернет на смартфоне или планшете для загрузки торрентов. Мобильный телефон использует отличную от провайдера сеть, поэтому там нет блокировки торрентов (если только мобильный провайдер не решил запретить их использовать). Затем просто перенесите загруженный контент на основное устройство. начните загрузку торрента, а затем подключитесь обратно к сети вашего интернет-провайдера. Торрент-клиент продолжит загрузку в обычном режиме. Но это сработает, только если провайдер использует фаервол с базовой настройкой блокировки.

6. Использовать Seedbox

Прежде чем вы спросите, нет, бесплатных Seedbox не бывает. Владельцы VPS платят за аренду серверов, и им нужно как-то зарабатывать деньги. Бесплатный Seedbox, скорее всего, окажется пустышкой и/или заразит ваш ПК вредоносным ПО.

7. Использовать Anomos

Стоит отметить, сайт Anomos больше не работает, поэтому он и в конце списка. Чтобы воспользоваться сервисом, необходимо скачать приложение со стороннего сайта или с SourceForge.

Сам Anomos – это нечто наподобие торрент-клиента со сквозным шифрованием. Поскольку он написан на Python, его пользовательский интерфейс довольно удобный, и к нему легко привыкнуть.

Однако существуют определённые неудобства.

Проект, скорее всего, уже не поддерживается разработчиками и заброшен. Так что, не удивляйтесь постоянным багам и зависающему приложению.
Anomos может открывать лишь файлы с расширением .atorrent. Придётся либо искать их, либо конвертировать обычные торрент-файлы в этот формат.

Использование обычного торрент-клиента вместе с VPN звучит гораздо удобнее, чем Anomos.

Поможет ли Tor, если провайдер блокирует Utorrent?

В теории, да. Tor – это анонимная сеть, которая скрывает ваш IP-адрес и шифрует трафик. Принцип схож с VPN, но в отличие от последнего, он шифрует трафик несколько раз.

Звучит неплохо, но есть проблема – использование торрентов через Tor не очень безопасно. Об этом заявляют сами разработчики, и призывают людей не делать этого. Использование этой сети нарушает конфиденциальность вашего веб-трафика. И торрент-клиент в конечном итоге может проигнорировать сеть Tor.

А ещё Tor не очень подходит для загрузки торрентов из-за ограниченной скорости. В сети Tor более 2 млн пользователей и лишь 6 тыс. серверов. Соответственно, скачать торренты размером 60 ГБ в краткие сроки просто нереально. Не говоря о том, что из-за вас сеть будет работать ещё медленнее.

Если вы проверите скорость работы Tor, то увидите, что загрузка файла в 1 Мб занимает в среднем около пяти секунд. Получается скорость загрузки ниже 1 Мб/сек, что недостаточно для работы с большими файлами.

Мы имеем дело со скоростью в мегабайты в секунду. Поскольку среднее время скачивания файла размером 1 Мб составляет пять секунд, значит, скорость загрузки 0,2 МБ/сек (или 2 Мбит/сек), что ещё хуже.

Получается Tor совсем не подходит для торрентов. намного лучше использовать VPN или Seedbox.

Избавит ли смена DNS от проблем с блокировкой торрентов?

Если провайдер использует DNS-фильтрацию для блокировки доступа к торрентам-сайтам – то можно поменять DNS. И ваши DNS-запросы будут проходить через другой DNS-сервер, не принадлежащий вашему провайдеру.

Для этого рекомендуется использовать следующие настройки:

: 208.67.222.222 и 208.67.220.220. : 8.8.8.8 и 8.8.4.4. : 1.1.1.1.

Однако изменение DNS не помешает провайдеру блокировать торрент-трафик напрямую.

Да, изменив DNS, вы получаете доступ к торрент-трекерам, но провайдер может использовать технологию DPI для просмотра незашифрованных DNS-запросов, даже если вы используете сторонний DNS-сервер.

Блокирует ли ваш провайдер торренты?

Как вы решаете эту проблему? Используете VPN или иные решения, предложенные в статье? А может у вас на примете есть другие методы? Если они работают, то, пожалуйста, расскажите о них в комментариях.

Стандарт говорит что, ключом при записи ответа в кэш является связка URI и method из соответствующего запроса.

Эксплуатация более вероятна если логика работы кэша на промежуточном узле оказывается более агрессивной, чем описано в стандарте. Например, кэшируются ответы, не являющиеся кешируемыми по-умолчанию. Это далеко не всегда происходит из-за ошибок в реализации, иногда стратегии кэширования намеренно делаются более агрессивными, чтобы снизить давление на бэкэнд сервер.

Ограничь клиента, меньше может — меньше сломает

Ограничения созданы, чтобы их преодолевать

Следовало ожидать, что это излишнее ограничение рано или поздно начнет мешать веб-разработчикам. Ирония в том, что так просто от таких WAF не избавиться. Особенно, когда они стоят у клиентов или провайдеров. Оспаривать чужие политики безопасности — гиблое дело.

Чего в этих статьях нет, так это секции «Security Considerations». А они как раз есть.

Так ли безопасно переопределение метода?

Но мы въезжаем в век CDN, и все больше приложений будут прятаться за CDN, которые читают пользовательский трафик и манипулируют им. Бэкенды напрямую почти никогда не обслуживают пользователей, а прячутся за обратными прокси для повышения отзывчивости и производительности. Поэтому придется помнить о том, как переопределение метода может повлиять на обработку запроса на сервере-посреднике.

Атаки на кэш

Теперь запросы с разными методами выглядят по-разному для кэша, так как ключ у них получается разный. Некоторые прокси предпочитают не кэшировать ответы на запросы, содержащие query компонент в URI. Но это скажется только на эффективности кэширования. Проблемы с некорректным кешированием такой способ решает всегда.

Другой способ — оставить переопределение метода в отдельном заголовке, но ввести вторичный ключ для поиска ответа в кэше. Это возможно при помощи заголовка Vary. Сервер при обслуживании запроса повторит заголовок с переопределением метода и отразит имя этого заголовка в заголовке Vary. Тогда при следующих запросах кэш-сервер будет использовать значение переопределенного метода в качестве вторичного ключа при поиске запроса в кэше.

Этот способ работает, если промежуточный сервер умеет работать с вторичными ключами. Обычно это так, но уровень доверия к прокси, который режет все методы, кроме GET и POST, обычно ниже и это лучше проверить.

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

Даже если атаки на кэш закрыты, это еще не все. Злоумышленник переопределением метода может попытаться изменить фрейминг ответа и тем самым нарушить соответствие пар запрос-ответ для других клиентов. Или заставить серверную часть приложения обработать один и тот же запрос несколько раз.

Самое главное, что для этого требуется — промежуточный сервер, работающий в режиме reverse-proxy. То есть любой кэширующий или CDN сервер. Такой прокси поддерживает относительно небольшое количество соединений с бэкэндом, и мультиплицирует в каждом из них запросы от множества клиентов. Это нужно и чтобы забрать нагрузку по поддержке большого числа соединений с клиентами с бэкэндов на прокси-сервер, и для балансировки нагрузки между бэкэндами. Терминирование TLS-соединений так же происходит на прокси, клиентские соединения никогда не подключаются напрямую к бэкэнду.

Поскольку теперь в одном соединении между бэкэндом и прокси будут находиться запросы от разных клиентов, необходимо поддерживать четкое соответствие пар запрос-ответ. Большая часть прокси не пайплайнит (конвейеризирует) запросы до бэкенда и работает с ним в режиме запрос-ответ. Режим запрос-ответ проще и подвержен фактически одной угрозе — блокировка соединения. Если заставить соединение повиснуть на одной паре запрос-ответ, то можно вызвать задержку или даже отказ обработки следующих запросов (например, если добиться переполнения очередей запросов на прокси).

Более производительные прокси пайплайнят запросы до бэкенда — это позволяет передать серверу сразу пачку запросов и ждать их выполнения. Производительность выше, но и угроз больше. Во-первых, проблема head-of-line blocking никуда не исчезает — даже если бэкэнд может разгребать конвейер запросов и выполнять их параллельно, они не могут быть отправлены, если «завис» первый из них. Во-вторых, если сломать фрейминг ответа, то можно запутать прокси и нарушить соответствие пар запрос-ответ, тогда некоторые клиенты могут получить чужие ответы, или хотя бы добиться мгновенного закрытия соединения с бэкэндом.

Самое простое и самое веселое переопределение метода — подменить GET глаголом HEAD. Если ответ на первый имеет тело, то второй — нет. При этом все остальные заголовки у них одинаковые, в том числе те, которые обеспечивают фрейминг запроса. Когда прокси перенаправит такой переопределенный HEAD серверу, он будет ожидать от сервера не только заголовки ответа, но и тело ответа, которое бэкенд не собирается отправлять. Если прокси и сервер взаимодействуют в режиме запрос-ответ, то соединение «повиснет» до момента пока не разорвется по таймауту.

Даже если все, что удалось добиться переопределением метода — закрытие соединения между прокси и бэкендом, то и этого может хватить для атаки. Можно закидывать такими запросами сервис — соединения с бэкэндами будут постоянно рваться. Их не так много, а переоткрытие занимает время, в итоге можно добиться значительного уменьшения производительности связи прокси-бэкенд и тем самым уменьшить пропускную способность сервиса.

Как раз это свойство нас и интересует. Если соединение между клиентом и сервером внезапно разорвется, клиент, зная что метод идемпотентен, может автоматически повторить отправку запроса. Так же ведут себя прокси. Неидемпотентые запросы автоматически не повторяются, потому что неизвестно, как они влияют на сервер и что клиент получит в итоге. Думаю, всем знакомы всплывающие окна в браузере: «вы уверены, что хотите повторить запрос?».

Если замаскировать неидемпотентный метод за идемпотентным, то в случае ошибок он не будет отброшен, а будет переотправлен на сервер еще раз. Даже если клиент будет учитывать настоящий метод запроса перед повторной отправкой запроса, это не сильно поможет, потому как прокси-сервер не знает о переопределении метода и будет повторять такие запросы.

Если злоумышленник сможет форсировать разрывы соединений между бэкендом и клиентами, то он сможет вызвать многократное выполнение на сервере неидемпотентных запросов и снизить надежность и предсказуемость приложения. В предыдущем разделе мы как раз нашли способ, как можно вызывать разрывы соединений все тем же переопределением метода. Хотя надо помнить, что интернет — ненадежная сеть по определению и приложение само по себе в опасности.

Чтобы обезопаситься от этой атаки следует в качестве транспорта использовать только те методы, которые не добавляют новых свойств запросу. POST — хорошая кандидатура, поскольку по-умолчанию не характеризуется ни как безопасный, ни как идемпотентный метод.

Как безопасно переопределить метод

Если же с переопределением метода приходится как-то жить, то для предотвращения достаточно правок на бэкенде. Во-первых, переопределение метода желательно производить только через query-компонент URI.

Во-вторых, должен быть белый список трансформации методов: какие допустимы в качестве «транспортного», а какие — результирующего. Не должно быть обобщенных функций трансформации, когда любой метод можно переопределить любым. «Транспортный» метод не должен обладать свойствами безопасности и идемпотентности, если ими не обладает результирующий. Должны быть запрещены опасные трансформации, та же замена GET -> HEAD.

Нужно ли патчить проблемный прокси/WAF?

Если прокси реализует только методы GET и POST, а остальные по той или иной причине блокирует — определенно да. Можно оптимизировать в первую очередь для GET и POST, но блокировать другие методы — плохая идея. Которая еще создает пропасть недоверия к продукту: если блокируются базовые вещи, что ожидать от реализации более сложных проблем?

Чему мы можем научиться в этой истории?

Разработчики систем безопасности, не ограничивайте разработчиков приложений политиками безопасности. Они все равно найдут, как их обойти, и чем гибче протокол — тем легче это сделать. Очень вероятно, что они не будут пинать вас и ждать, пока вы не сделаете ограничения более разумными, а просто обойдут их.

Если вы придумали, как что-то реализовать в протоколе, но это переопределяет или идет в разрез с одним из ключевых концептов стандарта, то наверняка возникнут проблемы совместимости и безопасности. И их нужно освещать одновременно с решением. Каждый раз. Если вы встретили такой совет и не увидели предупреждений безопасности, то не стоит тиражировать совет по всему интернету. Всегда критически подходите к решению и прикидывайте, что может пойти не так.

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

Здесь, в этом файле, иногда кэшируются ошибки, иногда – это результат действия хакера (читайте про DNS-спуффинг). Так что рассмотрим вариант, когда пользователю приходится самостоятельно обновлять DNS-кэш на манер очистки кэша любимого браузера. К счастью, это не так трудно.

В продолжении темы напомню, что в Windows есть три типа кэша, которые пользователь может легко контролировать (то бишь просто уничтожать). Мы говорим про:

Опробовано на версиях Windows 7 и 8. Не вижу препятствий для более поздних версий.

Плохо работает интернет ? Очищаем DNS кэш.

Если вам этого мало, и вы желаете лично убедиться, что операция прошла успешно, а заодно полюбопытствовать, как эта штуковина выглядит, можно, не закрывая консоли, набрать следующую команду (браузеры лучше закрыть):

В том же окне консоли появится информация подобно этой:

Все записи кэша отобразятся. Их после очистки будет немного. DNS кэширование можно выключить. Это делается командой

И попытаться проверить работу сети и конкретной страницы. Проверив результаты, запустите кэширование снова (или просто перезагрузите компьютер):

Службу кэширования можно перезапустить и через Диспетчер задач Windows. Её можно найти во вкладке Службы диспетчера:

Плохо работает интернет. Виноват сам сервер.

Да почему бы и нет. Между вашим роутером и искомым сайтом стоит ещё куча всего. Не беспокойтесь, всё это вы можете проверить. Худо-бедно, но общее представление о состоянии связи вы можете проверить прямо сейчас. Откройте консоль cmd и введите команду

tracert адрес_сайта

Вместо адреса_сайта введите предположительно проблемный. Окно консоли вернёт вам статистику трассировки маршрута от вашего компьютера до интернет ресурса. В окне показателей времени обмена данными вы увидите, кто дольше всех обрабатывает пакеты. можно делать выводы.

Про обход блокировок здесь писали много, внесу и я свои пять копеек в борьбу за свободный контент.

Этот способ подойдет счастливым обладателям интернет-центров Zyxel у которых в домашней сети много клиентов, чтоб не настраивать каждый отдельно. А так же тем, у кого есть устройства, умеющие воспроизводить медиаконтент, а обходить блокировки - нет. Например как у меня :

Дисклеймер. Я не несу ответственность за "окирпичивание" роутера, сброс настроек и т.д. В моем конкретном случае данный способ работает.

Работоспособность проверена на Keenetic Ultra, но в теории должно работать и на других моделях:

Keenetic 4G III

Keenetic 4G III B

Keenetic Extra II

Keenetic Giga II

Keenetic Giga III

Keenetic Lite II

Keenetic Lite III

Keenetic Lite III B

Keenetic Omni II

Keenetic Start II

Keenetic Ultra II

Для начала убедимся, что версия прошивки роутера не ниже "2.10.A.1.0-0".

После установки прошивки заходим в веб-конфигуратор -> переходим в раздел "Система" -> "Обновление" -> кликаем "Показать компоненты" и в разделе "Networking" ставим галку напротив "Клиент OpenVPN".

Листаем в самый низ и кликаем "Установить". Роутер - перезагружается.

Далее выбираем одну из конфигураций этого сервера, например с использованием доменного имени DDNS и TCP 995.

При этом на компьютер скачается файл конфигурации с расширением .ovpn. Откройте его в текстовом редакторе Блокнот (Notepad) и скопируйте все содержимое в буфер обмена (Ctrl A, Ctrl C). После чего в веб-конфигураторе Keenetic зайдите в раздел Интернет и на вкладке PPPoE/VPN добавьте соединение. В его настройках поставьте галочку Включить, добавьте Описание (например, vpngate), выберите Тип (протокол) — OpenVPN, а в поле Конфигурация OpenVPN вставьте скопированную конфигурацию из буфера обмена (Ctrl V) и нажмите Применить.

На этом настройка окончена.

Проверьте, что соединение установлено в разделе Интернет на вкладке Подключения.

Лично я подбирал конфигурации openvpn опытным путем, замеряя отклик и пропускную способность соединения.

Если вы все сделали как я написал, но блокировки не пропали, возможно стоит отключить DNS сервера провайдера через командную строку.

Для начала включаем telnet-клиент:

Теперь жмем Пуск – Выполнить…

В открывшемся окне набираем cmd и нажимаем OK. Для подключения к интерфейсу командной строки (CLI — Command Line Interface) интернет-центра введите команду telnet 192.168.1.1 и нажимаем Enter. (192.168.1.1 - адрес роутера по умолчанию, если вы его меняли, значит у вас он будет другой)

Набираем последовательно команды:

(config)> interface ISP no ip dhcp client name-servers

system configuration save

Не забудте назначить вручную в настройках ISP подключения адреса DNS серверов Google: 8.8.8.8 и 8.8.4.4

Перезагрузите роутер и проверьте, что блокировки пропали.

Если захотите вернуть настройки назад, наберите:

(config)> interface ISP ip dhcp client name-servers

system configuration save

В конце должно получиться примерно вот так:

Если какие-то моменты остались не понятны, постараюсь ответить в комментариях.

Всем свободного контента и хороших выходных!

Я думаю, стоит добавить, что в таком случаи весь трафик пойдет через VPN. Если требуется использовать только для доступа к конкретным ресурсам, то во вкладке Подключение, выставляем приоритет для VPN ниже, чем основное подключение. А потом во вкладке Прочее, создаем маршрут: указываем ip адрес сайта и выбираем использовать VPN подключение.

Я бы не особо доверял свои данные какому-то левому VPN-серваку.

Сам для себя держу прозрачный прокси с тором, который запакован в Docker.

Увы, без такого сейчас никак.

Долбаный роскомнадзор всех до печенок умудрился достать.

в 2021 есть что-то нормально работающее? осознал что на опере отключили впн. и загрустил. не думал что меня коснется

на Zuxel Keenetic Giga поставил DNS на DHCP сервер: 8.8.8.8 + 8.8.4.4 + 1.1.1.1

Собственно и всё.

VPN не понадобился.

На моём провайдере работает

Перебрал около 100 серверов с впнгейт, все тормозные, глючные и совсем недолго живущие, правда года два назад, может что-то поменялось в позитивную сторону.
Но можно купить за 100 рублей в мес, предложений навалом. Очень стабильно, но там трафик лимитирован.

А еще проще установить а-ля Frigate для браузера

у вас то же заиграла в голове мелодия it's my life с диким русским акцентом?)

как все сложно. скачай TOR, включи в нем ява-скрипты и наслаждайся.

Пидорская радуга детектед.

такое себе решение. будет работать только до критической массы. потом начнут блокировать VPN да и все.

ну и парочку прилюдных порок

Рекомендую выкинуть zyxel и поставить openwrt на то что есть, в том числе может и на zyxel.

Метод кривой, надо ОБЯЗАТЕЛЬНО доработать - в VPN заворачивать ТОЛЬКО ЗАБЛОКИРОВАННЫЕ, а то что есть - детсад и в морг.

Начало кампании РКН против VPN

Думаю ни для кого не секрет, что в последнее время РКН все больше закручивает гайки. Пробует разные подходы, начиная от реального замедления определенных ресурсов или же ограничиваясь угрозами замедлить их (привет Twitter и YouTube). Конечно, абсолютное фиаско и унижение, полученное после неудачной попытки блокировать Telegram не прошло бесследно. РКН обиду не забыл, а поэтому методы становятся немного более избирательными, чтобы не рушить чудовищное количество важной инфраструктуры, действуя подобно пушке, стреляющей по воробьям (да, это отсылка про рухнувший Сбербанк и прочее при попытке заблокировать Telegram). Хотя и до сих пор каждую неделю звучат призывы огородить богомерзкие и внезапно ставшими неугодными углы интернета от неустоявшейся психики граждан.

Сейчас, пока изгнанные, но все же хоть как-то технически проинформированные пользователи, заново устанавливают OperaVPN в свой браузер, обычные пользователи остались ни с чем. Не особенно хочется выступать в роли проповедника судного дня, но все же, хотя бы в глубине души, все понимают, за каждым ныне популярным, но не особо продуманным в плане защиты от нападок сервисом, придут. Те, кто умудрился вернуть VPN в свой браузер Opera, просто продлевают агонию, вскоре адреса будут забанены и привет.

Можно подумать так: "Ну что ж, значит возьму те, что с конца списка и буду пользоваться ими". Ну например Hola Free VPN Proxy — он есть в списке. Или хотя бы тот же АнтиЗапрет, что угодно, это все вопрос времени. Да, кроме того что придут и за ними, есть еще один нюанс. В конце концов, все эти решения, придумывались в качестве относительно простого обхода блокировок. Раньше, до определенного момента времени, было достаточно любого прокси, как например самый популярный NL (Голландия) прокси или DE (Германия). Сейчас ситуация еще сильнее ухудшилась. Теперь да же зайдя на некоторые заблокированные сайты, то они не откроется из NL и DE. На rezka.ag многие фильмы не откроются да же через UA (Украина).

Т.е. в данный момент не только нужно найти подходящий прокси сервер через который открывается большинство сайтов, но и для части сайтов держать дополнительные сервера. Думаю не нужно говорить что постоянное переключение между этими проксями и сопровождение этих правил, что-откуда надо открывать, не доставляет особого удовольствия. Хоть даже сейчас существуют бесплатные варианты типа той же Hola, но кто-нибудь пытался смотреть через них какое-нибудь потоковое видео? Нужно признать бесплатные варианты, подходят только для того чтобы почитать статеечки или посмотреть картинки. Но интернет давно уже не текст с картинками, это ролики по 150 а то и 1500 mb, YouTube шагает по планете. Обычные варианты такое уже не вывозят.

Все мы хотим пользоваться интернетом так, как этого заслуживаем в 2021 году, а не так как это существует в анально огороженном Китае. Список VPN-сервисов, которые заблокируют на территории России разослали ещё 18 марта среди сотрудников Сбера, а в публичном доступе письмо всплыло 15 апреля. Информация об этом появилась на форуме ntc.party , где сидят разработчики анти-цензурного софта.

И вот настало сегодня, когда зловещее предупреждение о бане исполнилось, решено, что нет лучше времени чем всем вам начать пользоваться тем, что я изначально создавал для себя и не особо пытался продвигать.

Для Google Chrome и Mozilla Firefox релиз уже есть.

Вот главные условия и приципы:

- База всегда максимально полная — обновление происходит ежедневно. Это очень важно.

- Проксировать только заблокированные сайты, все остальные сайты обязаны работать напрямую. Пропускная способность у меня нерезиновая.

- В век страха быть чипированным и получить Covid-19 от вышек 5G клянусь не собирать данных пользователей, не хранить никаких логов на серверах и не передавать ничего третьим лицам. (А нафиг оно мне надо, место у меня тоже ограничено).

Это решение изначально создавалось и планировалось из расчета на будущее. Естественно, я не буду вдаваться в подробности технического решения, но центр логики заключается в ранжированности доверия к пользователям.

Могу заверить, что изначально все создается так, чтобы не допустить остановки сервиса.

Читайте также: