Протокол OpenVPN хорошо известен как инструмент обхода блокировок сайтов, но плохо приспособлен к преодолению блокировок, которые нацелены против него самого.
Установка связи между клиентом и сервером (т.н. handshake) в этом протоколе имеет фиксированную сигнатуру, которая не защищена шифрованием, поэтому легко обнаруживается на ТСПУ и блокируется.
Шифрование передаваемых данных через TLS/SSL начинает использоваться позднее, когда сигнатура уже передана.
С учётом планируемого общероссийского запрета всех зарубежных VPN-сервисов имеет смысл заблаговременно оценить, какие инструменты помогут минимизировать нанесённый этим вне всякого сомнения гениальным нововведением урон.
Что нам советует официальная документация?
В документе https://community.openvpn.net/openvpn/wiki/TrafficObfuscation предлагаются два «решения»: встроенные статические ключи и работа поверх прокси-сервера (в качестве которого предложен obfsproxy из состава TorProject).
Совет про статические ключи является бесполезным, потому что (а) они начинают использоваться после handshake, да к тому же (б) конфликтуют с tls-auth, являясь его усечённой и устаревшей альтернативой.
Вариант с прокси превращает конфигурацию из типовой в нестандартную, т.е. (а) требующую специальной настройки на сервере и клиенте и (б) не всегда возможную на клиентских устройствах (особенно если речь идёт о мобильных телефонах и Windows). Но ниже мы рассмотрим и его.
Существует ли рабочее решение, встроенное непосредственно в OpenVPN?
Существует т.н. xor_patch, который не включён в основной проект из-за нежелания разработчиков. Его текущую поддержку взял на себя проект TunnelBlick, разрабатывающий для OpenVPN популярную графическую оболочку под MacOS.
Как история вопроса с цитатами и ссылками, так и параметры добавляемой патчем директивы "scramble" собраны на странице https://tunnelblick.net/cOpenvpn_xorpatch.html
Хотя общая идея xor_patch выглядит примитивно и антиакадемично (из-за чего её и отвергли в upstream), практическая польза от неё несомненна, потому что она позволяет добиться сокрытия протокольных сигнатур от массового автоматизированного анализа, т.е. вынужденно ограниченного в функциональности ради производительности.
Каков нынешний статус xor_patch?
- для MacOS/X предлагается поддерживаемая и регулярно обновляемая сборка OpenVPN в составе TunnelBlick,
- для Windows, Android и Docker существуют пользовательские сборки на https://github.com/lawtancool?tab=repositories&q=xor,
- для устройств Apple с iOS поддержка отсутствует.
Можно ли избежать сигнатурной блокировки, не шифруя весь трафик OpenVPN через xor_patch или дополнительным ПО?
Можно, если перед запуском OpenVPN сгенерировать мусорный трафик, использующий те же IP-адреса и порты. ТСПУ не увидит в нём искомой сигнатуры и запомнит соединение как не подлежащее блокировке. Для генерации трафика годится утилита nping из состава nmap:
sudo nping --count 10 --udp --source-port 1194 --dest-port 1194 --data-length 1200 -v vpn.yandex.ruПосле того, как она отработает, сразу запускаем OpenVPN в расчёте на то, что его трафик будет пропущен по проторенному пути без сигнатурной проверки:
sudo openvpn --server vpn.yandex.ru --proto udp --port 1194 ...Если в исходных настройках клиента OpenVPN присутствует директива "nobind", её следует убрать, чтобы для установки соединения использовался фиксированный порт отправителя:
- заданный директивой lport,
- или (при отсутствии lport) директивой port,
- или (при отсутствии port и lport) 1194, т.е. значение по умолчанию.
При запуске nping мы указываем его через "--source-port ..."
Коллективный опыт гласит, что количество передаваемых через "--count ..." пакетов должно подбираться экспериментально, в диапазоне от 1 до 310. Чем меньше — тем быстрее, чем больше — тем надёжнее. Замечено, что чем быстрее сеть, тем меньше пакетов требуется. Установлено, что в большинстве случаев хватает 10.
Инкапсуляция трафика OpenVPN дополнительными приложениями
Вместо установки и настройки obfsproxy мы решили проверить, как OpenVPN будет работать через аналогичный прокси, встроенный в OpenSSH:
- в одной консоли запустили ssh с ключом "-D 1080"
- в другой сначала проверили его работоспособность с помощью "curl -x socks5h://127.0.0.1:1080 -v showip.net"
- и после успешной проверки запустили openvpn с ключом "--socks-proxy 127.0.0.1 1080".
Результат оказался плачевным — openvpn выдал ошибку:
recv_socks_reply: TCP port read failed on recv(): Operation now in progress (errno=115)Ошибка обсуждается давно, но безрезультатно. Например, одно из обсуждений начато в 2013 году и продолжается до сих пор:
На этом наши изыскания приостановлены за ненадобностью до худших времён. В конце концов, когда мы хотим построить VPN поверх OpenSSH, то зачем нам для этого что-то ещё, кроме самого OpenSSH?
Поверхностный поиск в сети приносит улов из множества решений. Начнём с простых:
- stunnel — очевидный кандидат №1, но со столь же очевидным недостатком — поддерживает только TCP и не умеет туннелировать UDP,
- dtlspipe — "Like stunnel, but for UDP",
- udp2raw — "A Tunnel which Turns UDP Traffic into Encrypted UDP/FakeTCP/ICMP Traffic by using Raw Socket",
- shadowsocks с плагином v2ray-plugin — как альтернатива obfsproxy и "ssh -D"?
И закончим тяжеловесными:
- Cloak — мультипротокольный L4 мультиплексор, "A censorship circumvention tool to evade detection by authoritarian state adversaries",
- Trojan — "Proxy server, client and protocol, designed to bypass the Great Firewall of China by imitating HTTPS. Trojan claims to be unidentifiable",
- проекты от OperatorFoundation.org — "Useable tools to help people around the world with censorship, security, and privacy".
Увы, но остаётся лишь гадать, как скоро они превратятся из любопытных игрушек в незаменимых помощников.
Что предлагают коммерческие VPN-провайдеры?
Вероятно, сочетание одного или нескольких решений, перечисленных выше. Например, StrongVPN и IPVanish имеют опцию под названием "Scramble", а UTunnel и CactusVPN называют её "Obfuscation", причём CactusVPN прямо поясняет, что речь идёт про obfsproxy.
Безусловный плюс — клиентские дистрибутивы с поддержкой этих опций опубликованы в магазинах мобильных приложений, поэтому от пользователя данных сервисов не требуется настраивать для включения защиты ничего, кроме клика по галке в личном кабинете.
Безусловный минус — вряд ли от указанного плюса есть польза для тех, кто не является их клиентом и\или хочет иметь OpenVPN на собственном сервере, т.к. каждое приложение наверняка умеет подключаться только к серверам того сервиса, которым выпущено.
Что почитать, чтобы быть в курсе?
Поскольку ввод новых ограничений носит поступательный характер, требуется регулярно проверять, что накопленные инструменты и приёмы не утратили актуальность. То, что успешно работало вчера, может оказаться бесполезным сегодня.
Наиболее известным русскоязычным специалистом в почётном деле технического противостояния интернет-цензуре является уважаемый ValdikSS. Готовы рекомендовать всё, что он публикует по данной тематике.
Основным местом для дискуссий является управляемый им форум ntc.party.
В настоящий момент приведённого минимума вполне достаточно для результативного погружения в тему.
