На практике прокси больше подходят для повседневной защиты веб-трафика, не создавая при этом неудобств в виде заметной потери скорости и неизбирательности туннелирования. То есть при использовании хорошего прокси не стоит необходимость его отключать для комфортного пользования интернетом.
В этой статье расказано о преимуществах защищённого прокси перед VPN и предложены различные реализации, готовые к использованию.
В чём различие между VPN и прокси?
VPN — это общее название технологий для объединения внутренних сетей на уровне сетевых пакетов или кадров через соединение, установленное поверх другой сети (чаще всего публичной).
Прокси — это серверное приложение, осуществляющее соединения или запросы от своего имени и сетевого адреса в пользу подключившегося к нему клиента, пересылая в результате ему все полученные данные.
VPN осуществляет пересылку полезной нагрузки, находящейся на третьем или втором уровне сетевой модели OSI. Прокси осуществляют пересылку полезной нагрузки между четвёртым и седьмым уровнями сетевой модели OSI включительно.
И VPN, и прокси могут иметь или не иметь шифрования между клиентом и сервером. Обе технологии пригодны для того, чтобы направить трафик пользователя через доверенный сервер, применяя шифрование по пути до него. Однако, подключение через прокси делает это более прямолинейным способом, не привнося дополнительную инкапсуляцию сетевых пакетов, серые адреса самой VPN сети и изменения таблицы маршрутизации, которые привносит VPN просто лишь для того, чтобы сетевой стек системы пользователя направил трафик через нужный сервер.
Бесплатные Прокси
Это самые простые аддоны, которые представлены в магазине расширений каждого браузера. Единственное, на что они способны – замаскировать IP-адрес, но некоторые сервисы вроде Flash или Java все равно могут обнаружить истинный адрес. Часто такие расширения могут содержать в названии VPN, но являться прокси. Например, именно так было с браузером Opera, который позиционировался как браузер со встроенным ВПН, но это был простейший Proxy, и при этом не слишком качественный.
Преимущества:
- Бесплатных Прокси в отличие от ВПН очень много, и они ставятся буквально за минуту, так что можно легко менять их и пробовать новые.
- Регистрация, как правило, не нужна.
- Можно легко и быстро скрыть гео-локацию, пусть и базово.
Минусы:
- Бесплатного не бывает: или вам будут показывать рекламу, или ограничат скорость и трафик, стимулируя оплатить пакет, или будут собирать и перепродавать трафик.
- В худших случаях ваш девайс может использоваться в цепочке, и через него будут идти атаки и совершаться противоправные действия.
- Поток информации не шифруется.
Преимущества прокси
- В условиях реальной сети с потерями практическая скорость прокси зачастую выше, чем у VPN-решений. Это вызвано тем, что при проксировании TCP-соединений ретрансмиты на участках клиент-прокси и прокси-целевой узел происходят независимо. Прокси имеет свои TCP-буферы и кратковременные задержки ввода-вывода в обе стороны не сказываются на передаче с противоположной стороны. VPN же работает только на сетевом уровне (IP) и потерянные сегменты TCP будут пересылаться по всей длине пути от VPN-клиента до целевого сервера.
- Гибкость. Проще настроить избирательное проксирование. Использование прокси можно ограничить конкретными приложениями, в браузере — конкретными доменами. Можно использовать несколько разных прокси для разных адресов назначения одновременно.
- Трудно обнаружить с помощью DPI, в том числе DPI осуществляющими активные пробы. Однако, для этого необходима некоторая донастройка. В случае с прокси через TLS, такое соединение можно выдать за обычное HTTPS-соединение. В случае с VPN факт его использования виден даже пассивному DPI. Даже если это Wireguard.
- Нет целого класса проблем с внезапно прервавшимся VPN-соединением. В худшем сценарии VPN-соединение может прерваться и пользователь не заметит, что его трафик уже не защищён и/или он уже работает со своего «домашнего» IP-адреса. В случае с прокси такие проблемы исключены.
- Нет принципиальной возможности проводить атаки, пускающие трафик мимо VPN-туннеля. Пример такой проблемы.
- Не нужны высокие привилегии в системе ни для клиента прокси, ни для сервера. Это может быть весьма полезно в случаях, когда у Вас нет высоких прав в системе.
Выбор наших специалистов (рекомендовано)
- Месяц $11.95
- 12 месяцев $83.88
- 24 месяца $95.75
Читать обзор →
Nord VPN в рейтинге ВПН сервисов особенно рекомендуется тем, кто нуждается в повышенной безопасности и анонимности в сети
Плюсы
- Повышенная безопасность
- Нет логов
Минусы
- Нет возврата Bitcoin
- Нет техподдержки по телефону
от $4.95 месяц, скидка 58%
Получить скидку
→
1.
Плюсы:
- При выборе хорошего провайдера вы полностью защищены, и можно даже скрыть сам факт подключения к ВПН-серверу.
- Безлимитный трафик, минимальное снижение скорости, очень широкий выбор стран.
- Сервера для различных задач – для обмена файлами P2P, просмотра видео, серфинга.
- Работоспособность даже в странах, где доступ к сети жестко контролируется.
- Функция Kill Switch защитит вас, даже если связь с ВПН-сервером прервется.
- Функция CyberSec (или аналоги) блокирует нежелательную рекламу и вредоносное ПО.
- Шифрование военного уровня – для расшифровки понадобятся десятки лет.
Минусы:
- Хорошие сервисы – платные, стоимость может быть 10-13 долларов в месяц, а если покупать большие пакеты – 3-5 долларов, но тогда нужно сразу выложить всю сумму (около 60-100 USD).
- Некоторые провайдеры очень сильно снижают скорость и тормозят работу устройства.
Когда применять:
- Если нужна максимальная защита.
- В странах с жесткой цензурой или ограничениями интернета.
- Когда вы хотите сохранить абсолютную анонимность.
Выбрать ВПН
Как правило, одну платную лицензию можно использовать для нескольких устройств – от 3 до 6, так что получается относительно недорого. Все провайдеры предлагают скидки на большие пакеты.
Требования к прокси
Выбирая для себя реализацию защищённого прокси-сервера, я отметил несколько критериев, которым она должна удовлетворять:
- Обязательное шифрование и защита целостности данных внутри соединения.
- Надёжная и проверенная криптография. Доморощенные криптопротоколы крайне нежелательны.
- Устойчивость к DPI, в том числе к активным пробам. В идеале протокол должен внешне выглядеть неотличимо от протоколов, к которым обычно не возникает претензий. Например, как HTTPS.
- Отсутствие мультиплексирования нескольких TCP-соединений внутри одного. Причина этого требования такова: нежелательно, чтобы скорость нескольких соединений была ограничена скоростью одного TCP-соединения. Кроме того, при мультиплексировании нескольких соединений внутри одного приостановка получения данных из одного внутреннего (подвергнутого мультиплексированию) соединения может застопорить все остальные на неопределённое время. Для этого достаточно, чтобы со стороны прокси-сервера ожидало отправки больше данных, чем суммарный размер буфер отправки клиента-демультиплексора и буфер приёма сокета у застопорившего приём приложения. В частности такого эффекта можно иногда добиться, начав качать большой файл через SSH SOCKS5 прокси (ssh -ND 1080), и поставив скачивание на паузу. При неудачном стечении обстоятельств никакой трафик через туннель больше не будет принят. Более подробно о проблеме head-of-line blocking.
- Отсутствие привязки к поставщику или сервису.
Я рассмотрел несколько известных протоколов для шифрования соединения с прокси:
| Наименование | Резюме |
| OpenSSH dynamic port forwarding (ssh -ND 1080) | Использует мультиплексирование: низкая скорость, задержки |
| shadowsocks | Провал DPI |
| obfs4 | По внешнему виду он удовлетворяет всем требованиям, но есть моменты, вызывающие сомнения |
Особенности obfs4
В спецификации протокола obfs4 есть места, которые вызывают вопросы. В рукопожатии со стороны клиента используется номер часа от начала эпохи UNIX, который потом участвует в HMAC-подписи. Сервер, принимая такой пакет от клиента проверяет его, подставляя номер часа по своему времени. Если всё верно, то отвечает своей частью рукопожатия. Для борьбы с разбросом часов сервер должен ещё проверять предыдущий и следующий час.
Зная такое характерное поведение, можно проверить сервер на границе следующего и послеследующего часа, воспроизведя одно из прошлых записанных рукопожатий со стороны клиента. Если сервер перестанет отвечать своей частью рукопожатия в это самое время, то это достаточное основание, чтобы судить, что сервер обслуживает протокол obfs4.
Судя по всему, автор со временем осознал эту проблему и в коде obfs4 реализована защита от обнаружения через воспроизведение. В спецификации она нигде не описана.
Однако, такая защита наоборот упрощает работу по блокировке протокола: сетевому фильтру достаточно в случае сомнений задержать отправку рукопожатия от клиента, перехватив её, а затем отправить сообщение с рукопожатием первым. Таким образом он спровоцирует защиту от воспроизведения уже против клиента, вынуждая сам сервер блокировать клиента.
Следующий момент, вызывающий сомнения это формат «кадра» с данными. Выглядит он следующий образом:
+————+———-+———+—————+————+————+ | 2 bytes | 16 bytes | 1 byte | 2 bytes | (optional) | (optional) | | Frame len. | Tag | Type | Payload len. | Payload | Padding | +————+———-+———+—————+————+————+ \_ Obfs. _/ \___________ NaCl secretbox (Poly1305/XSalsa20) ___________/ Первые два байта каждого кадра это длина пакета, гаммированная с ключом, который вычисляется от предыдущих ключей. Как он вычисляется ключ не столь важно, главное, что настоящая длина пакета подвергается операции побитового исключающего ИЛИ каким-то ключом. Это значит, что можно инвертировать бит в этой части данных и подмена не будет сразу замечена. Если инвертировать младший значащий бит этого поля, то длина кадра станет либо на единицу меньше истинной, либо на единицу больше. В первом случае это приведёт к сбросу соединения через небольшое случайное время из-за ошибки распаковки NaCl secretbox.
Второй случай более интересный: сервер будет ждать ещё один байт для того, чтобы начать распаковку криптобокса. Получив ещё ровно один байт он также сбросит соединение из-за ошибки распаковки криптобокса. Это поведение можно считать специфичным для obfs4 и можно судить, что мы с высокой вероятностью имеем дело с ним. Таким образом, удачно разрушив одно из соединений клиента, можно с примерно 50%-ным шансом обнаружить obfs4.
Конечно, определение границ одного кадра в потоке тоже может представлять непростую задачу, но нет чётких гарантий, что нерешаемую. В случае обмена короткими сообщениями границы одного кадра могут совпасть с границами TCP-сегмента.
Ну и последняя особенность заключается в том, что сам по себе протокол внешне не похож ни на один из общепринятых. Он спроектирован с предположением, что DPI играет по правилам и незнакомые протоколы просто не трогает. Суровая реальность может показать, что это не так.
По всем этим соображениям я воздержался от использования obfs4.
TLS и SSH в качестве криптографического транспорта
Разумно было бы воспользоваться стандартными защищёнными сетевыми протоколами вроде TLS или SSH для обёртывания соединений с прокси. Действительно, к таким протоколам обычно не возникает претензий со стороны DPI, потому что ими может быть зашифрован легетимный трафик. Что же касается активных проб со стороны DPI, этот вопрос можно решить в частном порядке, в зависимости от конкретного протокола прокси.
Ниже будут представлены несколько готовых решений на базе этих протоколов, пригодных для повседневной постоянной защиты трафика.
SOCKS5 внутри SSH
Вариант с использованием функции dynamic port forwarding у OpenSSH рассматривался выше, но он имеет большие проблемы со скоростью. Единственный способ избавиться от мультиплексирования соединений — это использовать альтернативную реализацию клиента SSH, который обеспечивал бы каждое проксируемое соединение отдельной SSH-сессией.
Я проделал такую работу и реализовал его: Rapid SSH Proxy. Эта реализация обеспечивает каждое проксируемое соединение отдельной SSH-сессией, поддерживая пул подготовленных SSH-сессий для удовлетворения поступающих запросов подключения с минимальной задержкой.
Порядок работы с ним такой же, как у ssh -ND 1080: на стороне клиента запускается локальный SOCKS5-прокси, принимающий соединения и напрявляющий их в туннель через SSH-сервер.
Следует особо отметить ключевую особенность: никакого стороннего ПО не нужно устанавливать на сервер — rsp работает как ssh-клиент с обычным сервером OpenSSH. Сервером может быть любая unix-подобная операционная система, а так же Windows и Windows Server (в новых версиях OpenSSH теперь доступен в компонентах системы).
Приведу сравнение скорости через сервер в США:
| OpenSSH | rsp |
Что такое прокси и чем он отличается от VPN
Прокси-сервером называют промежуточное устройство между ноутбуком (или другой техникой) и интернет-ресурсом. Чтобы обойти блокировку прокси-сервер также меняет IP-адрес, после чего географическое расположение устройства, с которого происходит вход в интернет, меняется. Вместе с ним вы можете побывать в любой стране земного шара (Германии, Франции, Италии и т.д.), правда, только виртуально и чтобы обойти блокировку или оставаться анонимным (увы).
Например, если хотите войти в ВК, выбирайте географическое расположение страны, в которой не запрещено использовать эту социальную сеть. Для этой цели подойдет российский IP.
Установка и настройка прокси не отнимет много сил и времени, ведь все происходит быстро и «безболезненно». Прокси-сервер можно установить, как в браузере, так и на Windows. Второй вариант будет более обширным, так как местоположение меняется сразу в нескольких браузерах. Первоначальную настройку сделает даже ребенок, если использовать нашу наглядную инструкцию с картинками.
Важно! Российские прокси или какой-либо другой страны можно использовать на любом устройстве: ноутбук, планшет или телефон.
При первом подключении можно использовать бесплатный прокси. Но, он, конечно же, имеет не настолько большую скорость и слабо защищен по сравнению с приватным, что может привести к потере информации. Поэтому его рекомендуется использовать временно.
Прокси-сервера, которые можно купить, имеют много плюсов:
- Высокая скорость подключения интернета (не грузит при обходе запретов);
- Настройка под себя для комфортного использования;
- При возобновлении потерянного Интернет-соединения не нужно перезапускать браузеры, чтобы прокси-сервер вновь заработал (как в случае в впн);
- Осуществление любого вида деятельности в анонимном порядке.
Конечно, у прокси есть и недостатки, но к счастью они не серьезные, из-за чего на это можно закрыть глаза:
- Не происходит шифрования данных, идет просто подмена местонахождения;
- Если для соединения с запрещенным сайтом вы выбрали точку нахождения в другом конце земного шара, вероятно соединение уже не будет таким быстрым в этом случае (например, если это США). Но, можно обратиться за помощью в поддержку, специалисты подберут нужные адреса для быстрого соединения.
SOCKS5 внутри TLS
В случае с TLS очевидным решением было бы использовать stunnel или аналогичную TLS-обёртку для TCP-соединений с SOCKS5-сервером. Это действительно вполне хорошо работает, но возникает следующая проблема: рукопожатие TLS для каждого нового соединения занимает дополнительное время и появляется заметная на глаз задержка при установлении новых соединений из браузера. Это несколько ухудшает комфорт при веб-серфинге.
Для того, чтобы скрыть эту задержку, я подготовил специализированную замену stunnel на клиенте, которая поддерживает пул уже установленных, готовых к запросу TLS-соединений. Даже целых два — первый из них послужил прототипом:
- Pooling TLS Wrapper
- steady-tun
В качестве сервера я предлагаю два варианта:
- Связка из реверс-прокси haproxy и SOCKS5-прокси dante, настроенная на защиту от активных проб со стороны клиентов, не прошедших аутентификацию по сертификату: github.com/Snawoot/ptw/tree/master/docker_deploy
- Мой форк go-socks5-proxy со встроенной поддержкой TLS: github.com/Snawoot/socks5-server
HTTP-прокси внутри TLS aka HTTPS-прокси
Есть небольшая путаница в отношении сочетания слов «HTTPS» и «прокси». Есть два понимания такого словосочетания:
- Обычный HTTP-прокси без шифрования, который поддерживает метод HTTP CONNECT и через который может успешно работать HTTPS.
- HTTP-прокси, принимающий TLS-соединения.
Речь пойдёт о втором. Все платные и бесплатные браузерные расширения, предоставляющие «VPN», по сути настраивают браузер на использование такого прокси.
Примечательно, что ни в одном браузере нет простой возможности задать в настройках HTTPS-прокси через пользовательский интерфейс (то поле HTTPS-прокси, которое там есть, как раз относится к первому случаю). Но это не представляет собой большой трудности.
Поперебирав различные готовые варианты, я решил написать свой HTTP(S) прокси-сервер: dumbproxy.
Ключевой особенностью получившегося решения является то, что современные браузеры (Firefox и семейство Chrome, включая новый MS Edge) могут работать с ним без какого-либо дополнительного ПО на клиенте (см. руководство по настройке клиентов).
Следует отметить особенности реализации в отношении противодействия активным пробам со стороны DPI. HTTP-прокси легко распознать, подключившись к нему и осуществив попытку какого-либо запроса стороннего ресурса. Если прокси имеет авторизацию, то по стандарту он должен отвергнуть запрос с кодом 407, специфичным именно для HTTP-прокси, и предложить возможную схему для авторизации. Если прокси работает без авторизации, то он выполнит запрос, чем так же себя выдаст. Есть как минимум два способа решения этой проблемы (и оба они реализованы в dumbproxy).
Первый способ заключается в том, чтобы использовать аутентификацию клиентов по сертификатам ещё на этапе TLS-рукопожатия. Это самый стойкий метод, и это действительно корректная причина, по которой любой обычный веб-сервер мог бы отвергнуть клиента.
Второй способ заключается в том, чтобы скрыть от неавторизованных клиентов код ответа 407, возвращая вместо него любой другой ответ с ошибкой. Это вызывает другую проблему: браузеры не смогут понять, что для прокси требуется авторизация. Даже если браузер имеет сохранённый логин и пароль для этого прокси, ответ 407 важен для определения схемы авторизации, по которой эти учётные данные должны быть отправлены (Basic, Digest и т. д.). Для этого нужно позволить прокси генерировать ответ 407 на секретный запрос, чтобы браузер мог запомнить схему авторизации. В качестве такого секретного запроса используется настраиваемый секретный домен (не обязательно реально существующий). По умолчанию этот режим выключен. Подробности можно посмотреть в разделе об аутентификации.
Как скачать и установить расширение iNinja VPN & Proxy в Google Chrome
Установка плагина совершенно бесплатна и выполняется из магазина расширений. Чтобы установить расширение iNinja в Google Chrome, зайдите в магазин приложений: https://chrome.google.com/webstore/category/extensions и введите в поиске [iNinja proxy].
На открывшейся странице найдите нужное расширение и нажмите «Установить».
Появится всплывающее окно, в котором потребуется подтвердить установку и предоставить расширению доступ к управлению настройками посещения сайтов.
Начнётся процесс установки, по завершению которого у вас появится новый значок в верхней панели браузера.
При нажатии на значок, появится меню, где вы можете включить и отключить использование прокси-сервера. Здесь же можно выбрать геолокацию, которая будет использоваться при посещении сайтов.
Изменение IP-адреса вы можете проверить с помощью нашего бесплатного сервиса: https://socproxy.ru/ip.
В других браузерах — Яндекс.Браузер, Safari, Mozilla Firefox и Opera, установить расширение нельзя.
