Защищённые прокси — практичная альтернатива VPN


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

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

В этой статье расказано о преимуществах защищённого прокси перед VPN и предложены различные реализации, готовые к использованию.

В чём различие между VPN и прокси?


VPN — это общее название технологий для объединения внутренних сетей на уровне сетевых пакетов или кадров через соединение, установленное поверх другой сети (чаще всего публичной).

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

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

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

Преимущества прокси


  1. В условиях реальной сети с потерями практическая скорость прокси зачастую выше, чем у VPN-решений. Это вызвано тем, что при проксировании TCP-соединений ретрансмиты на участках клиент-прокси и прокси-целевой узел происходят независимо. Прокси имеет свои TCP-буферы и кратковременные задержки ввода-вывода в обе стороны не сказываются на передаче с противоположной стороны. VPN же работает только на сетевом уровне (IP) и потерянные сегменты TCP будут пересылаться по всей длине пути от VPN-клиента до целевого сервера.
  2. Гибкость. Проще настроить избирательное проксирование. Использование прокси можно ограничить конкретными приложениями, в браузере — конкретными доменами. Можно использовать несколько разных прокси для разных адресов назначения одновременно.
  3. Трудно обнаружить с помощью DPI, в том числе DPI осуществляющими активные пробы. Однако, для этого необходима некоторая донастройка. В случае с прокси через TLS, такое соединение можно выдать за обычное HTTPS-соединение. В случае с VPN факт его использования виден даже пассивному DPI. Даже если это Wireguard.
  4. Нет целого класса проблем с внезапно прервавшимся VPN-соединением. В худшем сценарии VPN-соединение может прерваться и пользователь не заметит, что его трафик уже не защищён и/или он уже работает со своего «домашнего» IP-адреса. В случае с прокси такие проблемы исключены.
  5. Нет принципиальной возможности проводить атаки, пускающие трафик мимо VPN-туннеля. Пример такой проблемы.
  6. Не нужны высокие привилегии в системе ни для клиента прокси, ни для сервера. Это может быть весьма полезно в случаях, когда у Вас нет высоких прав в системе.

Требования к прокси


Выбирая для себя реализацию защищённого прокси-сервера, я отметил несколько критериев, которым она должна удовлетворять:

  1. Обязательное шифрование и защита целостности данных внутри соединения.
  2. Надёжная и проверенная криптография. Доморощенные криптопротоколы крайне нежелательны.
  3. Устойчивость к DPI, в том числе к активным пробам. В идеале протокол должен внешне выглядеть неотличимо от протоколов, к которым обычно не возникает претензий. Например, как HTTPS.
  4. Отсутствие мультиплексирования нескольких TCP-соединений внутри одного. Причина этого требования такова: нежелательно, чтобы скорость нескольких соединений была ограничена скоростью одного TCP-соединения. Кроме того, при мультиплексировании нескольких соединений внутри одного приостановка получения данных из одного внутреннего (подвергнутого мультиплексированию) соединения может застопорить все остальные на неопределённое время. Для этого достаточно, чтобы со стороны прокси-сервера ожидало отправки больше данных, чем суммарный размер буфер отправки клиента-демультиплексора и буфер приёма сокета у застопорившего приём приложения. В частности такого эффекта можно иногда добиться, начав качать большой файл через SSH SOCKS5 прокси (ssh -ND 1080), и поставив скачивание на паузу. При неудачном стечении обстоятельств никакой трафик через туннель больше не будет принят. Более подробно о проблеме head-of-line blocking.
  5. Отсутствие привязки к поставщику или сервису.

Я рассмотрел несколько известных протоколов для шифрования соединения с прокси:

Наименование Резюме
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
Speedtest - OpenSSH Speedtest - rsp


SOCKS5 внутри TLS


В случае с TLS очевидным решением было бы использовать stunnel или аналогичную TLS-обёртку для TCP-соединений с SOCKS5-сервером. Это действительно вполне хорошо работает, но возникает следующая проблема: рукопожатие TLS для каждого нового соединения занимает дополнительное время и появляется заметная на глаз задержка при установлении новых соединений из браузера. Это несколько ухудшает комфорт при веб-серфинге.

Для того, чтобы скрыть эту задержку, я подготовил специализированную замену stunnel на клиенте, которая поддерживает пул уже установленных, готовых к запросу TLS-соединений. Даже целых два — первый из них послужил прототипом:

  1. Pooling TLS Wrapper
  2. 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» и «прокси». Есть два понимания такого словосочетания:

  1. Обычный HTTP-прокси без шифрования, который поддерживает метод HTTP CONNECT и через который может успешно работать HTTPS.
  2. HTTP-прокси, принимающий TLS-соединения.

Речь пойдёт о втором. Все платные и бесплатные браузерные расширения, предоставляющие «VPN», по сути настраивают браузер на использование такого прокси.

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

Поперебирав различные готовые варианты, я решил написать свой HTTP(S) прокси-сервер: dumbproxy.

Ключевой особенностью получившегося решения является то, что современные браузеры (Firefox и семейство Chrome, включая новый MS Edge) могут работать с ним без какого-либо дополнительного ПО на клиенте (см. руководство по настройке клиентов).

Следует отметить особенности реализации в отношении противодействия активным пробам со стороны DPI. HTTP-прокси легко распознать, подключившись к нему и осуществив попытку какого-либо запроса стороннего ресурса. Если прокси имеет авторизацию, то по стандарту он должен отвергнуть запрос с кодом 407, специфичным именно для HTTP-прокси, и предложить возможную схему для авторизации. Если прокси работает без авторизации, то он выполнит запрос, чем так же себя выдаст. Есть как минимум два способа решения этой проблемы (и оба они реализованы в dumbproxy).

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

Второй способ заключается в том, чтобы скрыть от неавторизованных клиентов код ответа 407, возвращая вместо него любой другой ответ с ошибкой. Это вызывает другую проблему: браузеры не смогут понять, что для прокси требуется авторизация. Даже если браузер имеет сохранённый логин и пароль для этого прокси, ответ 407 важен для определения схемы авторизации, по которой эти учётные данные должны быть отправлены (Basic, Digest и т. д.). Для этого нужно позволить прокси генерировать ответ 407 на секретный запрос, чтобы браузер мог запомнить схему авторизации. В качестве такого секретного запроса используется настраиваемый секретный домен (не обязательно реально существующий). По умолчанию этот режим выключен. Подробности можно посмотреть в разделе об аутентификации.

Заключение


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

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

P.S. Если вам важна анонимность вашего адреса в интернете, не забудьте выключить WebRTC в своём браузере. Провериться на утечки IP-адреса можно здесь.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 52

    +1

    А вы уверены, что прокси на себя берёт всё то, что с браузера летит? WebRTC это же только одна ипостася. Есть резолвинг странных имён, пуши и т.д.


    Да что там, тупой ftp: на сайте может спалить браузер мимо прокси.
    … А какие протоколы ещё ваш браузер умеет?

      –2
      А вы уверены, что прокси на себя берёт всё то, что с браузера летит? WebRTC это же только одна ипостася. Есть резолвинг странных имён, пуши и т.д.
      Да, уверен. В случае использования socks5 надо не забыть поставить галку remote dns.

      Да что там, тупой ftp: на сайте может спалить браузер мимо прокси.
      … А какие протоколы ещё ваш браузер умеет?
      Можете привести пример?
        0

        \mydomain.com\for\ie, это что я с ходу придумать могу. Покопался, 5 лет назад FF перепосылал запрос без прокси, если прокся не доступна (https://bugzilla.mozilla.org/show_bug.cgi?id=1207798)


        Кстати, а DOH уважает прокси или нет?

          0
          Там у него PAC-файл недоступен вообще, как по мне это нормальное поведение. Неплохо, конечно, что они закрыли это, но я бы не стал ожидать чего-то другого. В предлагаемых мною настройках для HTTPS-прокси PAC-файл задаётся как Data URL и там ошибки такого класса исключены.

          Что касается FTP, то никак он адрес не раскрывает, браузеры давно все работают в пассивном режиме протокола FTP. Главным образом чтобы не было вообще никаких потенциальных проблем с NAT-ом.

          Я так понял, что если включён DOH, то браузер будет его использовать, чтобы резолвить адрес самого прокси, но далее резолвинг идёт как часть запроса к самому прокси.
        +1
        Я на Винде использую Proxifier для этого, там и правила можно гибко прописать.
          0
          Жутко костыльное и кривое решение как по мне. Самое адекватное решение всё таки VPN и либо роут по умолчанию в тоннель, либо что-то отдельное в тоннель, а что-то в обход.
            0
            Про глобальный прокси в Винде не слышали?
              +1
              Знаю, использовал, и proxy auto config со шлюза раздавал для I2P. Но это не работает с приложениями, которые не поддерживают прокси и с протоколами тоже, кроме того на мобильных системах этого вообще нет, а вручную где то лазить это фу, хочется чтобы просто работало ;) Вот VPN это позволяет, на шлюзе по умолчанию просто настраивается маршрутизация чего надо куда надо и всё, клиентам вообще ничего знать не надо.
              +1
              Badvpn тогда, а еще более лучшее решение — как шэдоусокс-клиента юзать аутлайнВПН (по сути там тоже бэдвпн для тунеллирования) и просто пускать его через апстрим-прокси обфускатор.
                0
                Да, Badvpn не плох, я его как то пробовал для человечной прозрачной отдачи I2P и Tor в локалку, но так и не получилось настроить волшебство с DNS, в итоге похоронил идею.

                Собственно я вообще не сторонник прокси, VPN на порядки лучше и удобнее.
                  0
                  Зависит от целей и задач. Потоки лучше разделять и не смешивать.
                    0
                    Ну да, я теперь жду когда Tor browser в виде расширения будет доступен в Firefox, тема с прозрачной работой была похоронена так и не реализовавшись как требующая слишком сложной настройки.
          +2

          Я бы добавил к преимуществам низкое потребление ресурсов а как следствие и электроэнергнии, целый день ходить со включённым OpenVPN весьма накладно для использования батареи, а вот с Outline дело обстоит намного лучше.

            +4

            И ключевой(для меня) недостаток прокси — требуется его поддержка приложением. VPN позволяет пользоваться не только браузером.

              0
              И ключевой(для меня) недостаток прокси — требуется его поддержка приложением.
              Не обязательно, есть прозрачные прокси. Мой ptw и rsp умеют такое из коробки, все остальные могут работать через transocks.

              VPN позволяет пользоваться не только браузером.
              У меня вот прямо сейчас запущены несколько разных мессенджеров, торрент-клиент и почтовый клиент. Все, кроме Viber, поддерживают прокси. Viber почему-то именно на десктопе не поддерживает, хотя на телефоне — да. Тем не менее его бы я как раз через удалённый сервер и не стал заворачивать, чтобы не было ненужных задержек при разговоре.
                0

                Скорее наоборот. Приложение должно поддерживать ВАРИАНТЫ. А прокси можно использовать глобально для всей системы. Не знаю как Windows, а вот в Linux — уж точно можно.


                image

                  0

                  Ставится какая-нибудь настройка в gconf/dconf и, возможно, ставятся переменные среды *_proxy при запуске десктопных приложений. Совершенно не факт, что все ваши приложения будут это поддерживать, это же Linux :)

                    0
                    В Винде тоже есть глобальный прокси, вот только на системные службы самой Винды он почему-то не распространяется.
                      0
                      С настройками прокси проблема в Android, например. Глобально его можно настроить только для wifi-соединений, индивидуально — только в браузерах.
                      Есть разный сторонний софт для конфигурирования на системном уровне, но он весь требует рута, что не всегда возможно.
                    0
                    Чем ваша реализация лучше squid-ssl?

                    wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection
                      +2
                      Вот чем:

                      1. Поддержка HTTP/2 между клиентом и прокси, и между прокси и целевым веб-сервером.
                      2. Есть возможность прятать 407ой ответ, чтобы не давать обнаруживать прокси.
                      3. Есть аутентификация клиентов по сертификатам.
                      4. Нет кэширования, ненужной буферизации ответов, добавления заголовков Via и X-Forwarded-For. Клиент через dumbproxy начинает получать ответ как можно более оперативно и его не нужно долго и внимательно конфигурировать, чтобы он просто «тупо» форвардил трафик без лишних действий. Он только под это заточен изначально. Проще настроить.
                      5. Возможность развёртывания на почти любой платформе/ОС путём запуска единственного статически слинкованного исполняемого файла.


                      Иными словами, squid это вебкэш из эпохи, когда они были актуальны, а моё решение узкоспециализировано под задачу из поста. Но squid, конечно, имеет массу других возможностей, это большой «комбайн».
                      +2

                      Интересно, каков процент людей, которым нужен именно vpn (например, полноценный вход в локалку в офисе), а не просто выход веб браузером (ну или ещё какой конкретной софтиной) через другую точку?

                        0
                        > Интересно, каков процент людей, которым нужен именно vpn
                        > (например, полноценный вход в локалку в офисе), а не просто
                        > выход веб браузером (ну или ещё какой конкретной софтиной)
                        > через другую точку?

                        Я только для этого VPN и применяю — для доступа в удалённую локальную сеть офиса на любые внутренние компьютеры этой сети по любым портам (vnc там к примеру, да хоть банальный пинг для проверки).

                        Я в офисной локальной сети на шлюзовом компьютере (FreeBSD) установил VPN-сервер mpd, к которому нормально подключаюсь из винды ейным VPN-клиентом, а из другой FreeBSD — тоже нормально подключаюсь к этому mpd программой ppp (написав для этого соответствующий раздел в /etc/ppp/ppp.conf для VPN-подключения).

                        Ищу способы подобного подключения к моему VPN-серверу с мобилы:

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

                        А сторонние VPN-клиенты (из гугловских Плей-маркетов там всяких) почему-то заточены только под какую-то там защиту чего-то да от кого-то. Хотя мне нужна не защита, а просто доступ к внутренним станциям удалённой локальной сети в офисе.
                          0
                          Штатный андроидный VPN-клиент хоть и подключается нормально и даже работает тоже нормально, но ставит пароль на разблокировку экрана.

                          Что Вы имеете ввиду?
                            0
                            Захожу в Андроиде сюда:
                            Настройки
                            Подключения
                            Другие настройки
                            VPN
                            В правом верхнем углу — знак «3 точки, расположенные вертикально»
                            Добавить профиль VPN

                            И после этого вижу (см. копию экрана ниже), что перед созданием учётной записи VPN меня пытаются заставить «выбрать тип безопасной блокировки экрана» с двумя вариантами:
                            ОК (после этого учётную запись VPN создать разрешат)
                            Отмена (создание учётной записи полностью отменяется)

                            Вот копия экрана:

                            image

                            Если я соглашусь выбрать «тип безопасной блокировки экрана», то созданный после этого VPN-клиент будет нормально подключаться к моему серверу VPN, используя указанные ему в настройках только адрес VPN-сервера, логин и пароль (и никаких там странных и непонятных сертификатов).

                            Но мне выбирать «тип безопасной блокировки экрана» не надо потому, что после этого блокировку экрана придётся делать не лёгким движением руки, а вводом пароля или какой-то другой мантры, что мне очень неудобно. Приходится отказываться от создания учётной записи VPN на мобиле.
                              +2
                              Личные данные на смартфоне должны быть зашифрованы и сам смартфон должен блокироваться. Это стандарт информационной безопасности сейчас, особенно, если вы живете в России.
                                0
                                Это понятно, что за пользователя кто-то другой решил — как ему защищаться: ходить в маске или ставить пароль на экран. Свободы нет давно даже тут. Печаль. :-)
                          0
                          Ещё какая то софтина, их ведь много. Мне нужен мой DNS через тоннель, например, через который, например flibusta.lib резольвится и до сиз пор torrents.ru открывается ) Ну и прочие мелочи которые шлюз разгребает и не требует конских таблиц на устройствах.
                          +1
                          Хорошая статья. Прочитал с большим удовольствием. Я бы еще дополнил местами, где можно приобрести недорогие хостинги под это, но это мое мнение.

                          Автору большое спасибо за статью!
                            +1
                            В случае с прокси через TLS, такое соединение можно выдать за обычное HTTPS-соединение. В случае с VPN факт его использования виден даже пассивному DPI. Даже если это Wireguard.
                            Существуют VPN, которые работают так же через «обычный» TLS — например, SoftEther, AnyConnect/OpenConnect и SSTP и со стороны DPI видны как обычный HTTPS. С помощью некоторых трюков можно так же заставить отвечать вместо них безобидный веб-сайт, чтобы избежать active probing.
                            Нет целого класса проблем с внезапно прервавшимся VPN-соединением. В худшем сценарии VPN-соединение может прерваться и пользователь не заметит, что его трафик уже не защищён и/или он уже работает со своего «домашнего» IP-адреса.
                            Решается настройкой маршрутов — удаляется дефолтный роут в системе, прописывается дефолтный роут на шлюз внутри VPN, и отдельный маршрут до VPN-сервера. Тогда при падении туннеля доступ во внешнюю сеть прекращается полностью до возобновления соединения.
                            Первый способ заключается в том, чтобы использовать аутентификацию клиентов по сертификатам ещё на этапе TLS-рукопожатия. Это самый стойкий метод, и это действительно корректная причина, по которой любой обычный веб-сервер мог бы отвергнуть клиента.
                            Не нашел в вашей инструкции по конфигурированию клиентов dumbproxy ничего про клиентские сертификаты, можно подробнее?
                              0
                              Существуют VPN, которые работают так же через «обычный» TLS — например, SoftEther, AnyConnect/OpenConnect и SSTP и со стороны DPI видны как обычный HTTPS. С помощью некоторых трюков можно так же заставить отвечать вместо них безобидный веб-сайт, чтобы избежать active probing.
                              Вопрос только в том, как это сделать.

                              Я экспериментировал с SSTP и ставил перед сервером haproxy, который в начальном состоянии маршрутизирует входящее соединение на веб-сервер (который тоже встроен в haproxy). При поступлении особого запроса (который извне не читаем из-за TLS) он запоминает адрес клиента и дальше маршрутизирует соединения от него на SSTP-бэкенд. Получилась примерно такая конфигурация:

                              frontend sstp
                              bind 10.19.0.5:443 ssl crt /etc/haproxy/example.com.combined.pem
                              acl allowed src,map_ip(/etc/haproxy/wl_map.txt) 1
                              use_backend sstp-server if allowed
                              default_backend sstp-decoy

                              backend sstp-decoy
                              server decoy 127.0.0.1:41720 send-proxy-v2

                              frontend sstp-decoy
                              bind 127.0.0.1:41720 accept-proxy
                              mode http
                              http-request set-map(/etc/haproxy/wl_map.txt) %[src] 1 if { path /mysecretlocation }
                              http-request deny deny_status 400

                              backend sstp-server
                              server sstp 127.0.0.1:4433

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

                              И даже если это всё проделать, на выходе получится тормозной VPN, работающий через один TCP-коннект.

                              Решается настройкой маршрутов — удаляется дефолтный роут в системе, прописывается дефолтный роут на шлюз внутри VPN, и отдельный маршрут до VPN-сервера. Тогда при падении туннеля доступ во внешнюю сеть прекращается полностью до возобновления соединения.
                              Да, эта проблема решаемая. Кроме этой, есть ещё проблема с DNS leak, в особенности на винде: VPN-клиент добавляет свои DNS-серверы, но винда может пройтись по всем сконфигурированным DNS-серверами, посылая запрос мимо туннеля в DNS-сервер в локальной сети. А у прокси всех этих проблем просто нет.

                              Не нашел в вашей инструкции по конфигурированию клиентов dumbproxy ничего про клиентские сертификаты, можно подробнее?
                              Сначала нужно сгенерировать сертификаты для клиентов. Я обычно использую свой же quickcerts. Затем на сервере нужно указать параметры -cert, -key, -cafile, где сертификат и ключ — любой ваш сертификат для TLS, а cafile — сертификат CA, которым выпущены серты для клиентов. Кроме этого, нужно выставить параметр -auth в значение cert://
                              Далее есть два варианта:
                              • Установить клиентский сертификат прямо в браузер и дальше настройка как обычно. У меня в Firefox и вроде бы даже в Chrome это работало, но я наблюдал кое-какие странности в поведении браузеров.
                              • Запустить steady-tun или ptw на клиенте, указав в нём клиентский сертификат и адрес сервера, а браузер уже настроить на подключение к локальному порту steady-tun или ptw как к обычному HTTP-прокси без TLS.
                                +1
                                Я экспериментировал с SSTP и ставил перед сервером haproxy, который в начальном состоянии маршрутизирует входящее соединение на веб-сервер (который тоже встроен в haproxy). При поступлении особого запроса (который извне не читаем из-за TLS) он запоминает адрес клиента и дальше маршрутизирует соединения от него на SSTP-бэкенд.
                                Я делал примерно так же, использовал https-нокер, который применял правила фаервола, и переадресовывал входящие подключения на 443 с заданного IP на локальный порт VPN-сервера в течении 15 секунд, чего было достаточно для установления соединения. Если все юзеры провайдера вместе с DPI не сидят за одним NAT'ом, либо же active probing происходит не мгновенно сразу же, то эта схема получается весьма надежной.
                                Из других вариантов:
                                — линуховый sstp-сервер можно запускать в режиме no-ssl, а TLS-подключение принимать тем же stunnel, и давать отлуп клиентам с неподходящим сертификатом;
                                — дождаться повсеместного введения TLS1.3 с eSNI и разруливать всё nginx'ом с ngx_stream_ssl_preread_module — и тогда «секретом» будет имя хоста, коннекты к правильному хостнейму перекидываются на VPN, остальным показывается сайт-заглушка; со стороны имя хоста не видно, т.к. зашифровано.
                                И даже если это всё проделать, на выходе получится тормозной VPN, работающий через один TCP-коннект.
                                SSTP у меня между городком в Поволжье и VPN-сервером в восточной Европе вполне спокойно выжимал 30-40 мегабит в обе стороны, чего более чем достаточно для повседневных нужд.
                                AnyConnect/OpenConnect после успешной аутентификации по HTTPS умеет устанавливать DTLS-линк (UDP) для более эффективного транспорта. DTLS со стороны выглядит, опять же, вполне безобидно, он, например, используется в WebRTC.
                                Кроме этой, есть ещё проблема с DNS leak, в особенности на винде: VPN-клиент добавляет свои DNS-серверы, но винда может пройтись по всем сконфигурированным DNS-серверами, посылая запрос мимо туннеля в DNS-сервер в локальной сети.
                                Тоже чинится довольно просто — на дефолтном интерфейсе ставим в качестве DNS либо некорректный адрес в локалке, либо IP-адрес dnsmasq внутри VPN-подсети (фиг знает, будет ли через него резолвится, но по крайней мере во внешнюю сеть запрос не уйдет), к VPN подключаемся по IP, либо прописываем его имя в hosts.
                                  +1
                                  дождаться повсеместного введения TLS1.3 с eSNI и разруливать всё nginx'ом с ngx_stream_ssl_preread_module — и тогда «секретом» будет имя хоста, коннекты к правильному хостнейму перекидываются на VPN, остальным показывается сайт-заглушка; со стороны имя хоста не видно, т.к. зашифровано

                                  уже сейчас часть этого можно реализовать с помощью Shadowsocks, v2ray и Nginx (без eSNI, т.к. его не хотят еще пилить в Go).
                                    –2
                                    О чем вы говорите, автор тестит голый СС и думает что он плохо работает, какой в2рей
                                      0
                                      Без eSNI это не имеет смысла — хостнейм передается в открытом виде, и следовательно active probing по нему же и стукнется. Или вы еще какое-то звено не упомянули в своей цепочке?
                                      v2ray, например, насколько я помню, умеет заворачиваться в websockets — вот это очень хороший вариант выходит, плюс можно даже немного понаглеть и задействовать cloudflare :)
                              0
                              > Гибкость. Проще настроить избирательное проксирование.
                              > Использование прокси можно ограничить конкретными приложениями

                              Возможность использования прокси только для конкретных протоколов (обычно, как это изначально и было в старину, для http) является нщё и недостатком по сравнению с vpn. Ведь через vpn подключается канал связи по любым протоколам (это же очень удобно), а прокси предоставляет доступ только по некоторым протоколам.
                                +1

                                А какой прокси клиент посоветуете? на андроид, чтоб без сложных настроек, рута нет .

                                  0
                                    –1
                                    На андроиде есть клиент HTTPS-прокси Drony, который имитирует VPN и может заворачивать все TCP-соединения любых приложений через прокси. Но он не очень удобный, его муторно настраивать и я пока так и не понял, как заставить его не отправлять DNS-запросы напрямую.

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

                                    Лучшее, что доступно на андроиде и нормально работает — это VPN-клиент Wireguard. Возможно, если у меня наберётся достаточно материала, я напишу пост про то, как можно использовать Wireguard и получить дополнительные преимущества по скорости как у прокси путём прозрачного проксирования TCP-соединений на сервере Wireguard.
                                      +2
                                      Ваергард не соответствует вашему критерию «устойчивости к DPI» от слова совсем. Вы определитесь, вам или устойчивость и обфускацию надо, или что-то еще. Потому что ваергард, это не про то.
                                        –1
                                        Я и не говорил, что соответствует, в статье ровно обратное написано. Просто лучше вариантов нет.
                                          0

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

                                            +1
                                            Я упоминал это в статье, но если Вы не читали, то вот: github.com/net4people/bbs/issues/22

                                            Что же касается shadowsocks с v2ray-плагином — в режиме HTTP он так же подвержен активным пробам, потому что сторонний наблюдатель так же сможет воспроизвести то, что видел в открытых фрэймах вебсокета.

                                            В режиме HTTPS всё вроде бы неплохо, но возникает вопрос: а зачем сам shadowsocks в этой схеме, если сокрытие начала диалога возложено на TLS? Вот он и есть как раз велосипед, в итоге, который сам по себе провалился с точки зрения цензуроустойчивости, но может использоваться под TLS. А под TLS и стандартный HTTP-прокси отлично работает, который в браузерах из коробки поддерживается.
                                              –2

                                              Я конечно читал, вот только это не актуально для России. Для Китая — да, для России — нет. Это китайцам приходится прорываться сквозь Золотой щит, это у них прокси обнаруживаются с помощью зондирования и блокируются. У нас такой проблемы нет. У вас несколько надуманная модель угроз.
                                              А что, если я скажу, что вы со своими прокси не защищены от атак сопоставлением? Тогда нет смысла в любом вашем методе, ведь с помощью пакета Яровой вас все равно вычислят.
                                              По поводу зачем вообще в схеме shadowsocks? Так только из-за удобства. Вы мобильные клиенты написали под свои решения или предлагаете в Android сидеть из под shell? А в iOS?

                                                0
                                                Я конечно читал, вот только это не актуально для России. Для Китая — да, для России — нет. Это китайцам приходится прорываться сквозь Золотой щит, это у них прокси обнаруживаются с помощью зондирования и блокируются. У нас такой проблемы нет. У вас несколько надуманная модель угроз.
                                                Ну значит тогда в России и shadowsocks не нужен, так получается?

                                                А что, если я скажу, что вы со своими прокси не защищены от атак сопоставлением?
                                                Сказать-то легко, доказать трудно.
                                                  –1
                                                  Вы не поняли: речь шла о связке shadowsocks+v2ray, вы же ее назвали «велосипедом». Сам shadowsocks отлично и шифрует, и мультиплексирует, и скорость не режет, и работает на всех платформах.
                                                  Так про мобильные клиенты: есть или нет? Получается какое-то половинчатое решение у вас.
                                                  Сказать-то легко, доказать трудно.

                                                  Докажите наличие active probing в России.
                                                    +1
                                                    Вы не поняли: речь шла о связке shadowsocks+v2ray, вы же ее назвали «велосипедом». Сам shadowsocks отлично и шифрует, и мультиплексирует, и скорость не режет, и работает на всех платформах.
                                                    Так про мобильные клиенты: есть или нет? Получается какое-то половинчатое решение у вас.
                                                    Сам он не отлично шифрует и легко провалился. А при зависимости от TLS он и не нужен как протокол. Да, клиенты shadowsocks на телефоны сейчас есть, для HTTPS-прокси тоже есть, но плохие. Тем не менее, это не отменяет ущербности shadowsocks как протокола.

                                                    Докажите наличие active probing в России.
                                                    Я такого утверждения не делал, но при этом не считаю правильным дожидаться, когда active probing появится. А Вам своё заявление подкрепить нечем, я так понимаю?
                                                      0
                                                      Я такого утверждения не делал

                                                      Значит и смысла никакого нет заворачивать прокси в TLS.
                                                      Сам он не отлично шифрует и легко провалился

                                                      Легко — это проработав 4 года без блокировки в Китае?
                                                      Тем не менее, это не отменяет ущербности shadowsocks как протокола.

                                                      Конечно, ss ущербен, именно поэтому им пользуются до сих пор по всему миру, да, прикрутив плагин для TLS в Китае.
                                                  0
                                                  У нас такой проблемы нет.
                                                  Вы забыли слово «пока». "Пока нет".
                                                  0
                                                  Что же касается shadowsocks с v2ray-плагином — в режиме HTTP он так же подвержен активным пробам, потому что сторонний наблюдатель так же сможет воспроизвести то, что видел в открытых фрэймах вебсокета.


                                                  Можно использовать симпл-обфс с включенным фейловером на локальный nginx.

                                                  Вопрос в другом. Если вас активно тыкают палочкой в ручном режиме, вам уже ничего не поможет.

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

                                                  Shadowsocks в данной связке выступает как прокси — роутит ваш трафик между клиентом и сервером, имея минимальный оверхед. Чисто теоретически можете через в2рей-плагин хоть опенВПН пускать, хоть данте, только нафига? А сам по себе в2рей-плагин это просто враппер для трафика.
                                        0
                                        del

                                        Only users with full accounts can post comments. Log in, please.