Vpn tunnel что это
ВПН туннель
Перед тем, как объяснить, что такое VPN-туннель, следует вспомнить, что такое виртуальная сеть. VPN или виртуальная частная сеть – это технология, позволяющая создать одно или несколько соединений поверх другой сети. При подключении к VPN, создается «виртуальная» сеть между устройством пользователя и сервером ВПН, с зашифрованным соединением. Запрос в зашифрованном виде направляется от пользователя, через защищенный канал связи, именуемый ВПН–туннелем, на сервер ВПН. Оттуда запрос перенаправляется по назначению – в интернет или к другому серверу.
Безопасность
Если используется обыкновенное подключение к сети, трафик передается от пользователя напрямую интернет провайдеру. Информация передается в открытом виде, и третьи лица могут получить к ней доступ. Туннелирование позволяет создать защищенный канал, по которому информация передается в зашифрованном виде на сервер, а ключи шифрования есть только у пользователя и сервера. Получить доступ к информации пользователя можно, лишь имея физический доступ к серверу в момент подключения. Большинство крупных провайдеров VPN услуг никогда не сохраняют логи, а физический доступ к их серверам практически исключен. Хотя трафик расшифровывается на сервере, определить конкретного пользователя, который делал этот запрос невозможно – к ВПН подключаются одновременно сотни хостов.
Методы шифрования в туннелях
ВПН туннель – это своеобразный защищенный мост между устройством пользователя и сервером, где данные шифруются при помощи надежных 256-битных алгоритмов. Некоторые сервисы используют 128 битные AES. Даже такие ключи взломать невозможно – используя метод грубого перебора (брутфорса) это заняло бы миллионы лет.
Типы протоколов в VPN туннелях
Самый распространенный среди ВПН сервисов протокол передачи данных в ВПН сетях — OpenVPN. Он использует стандартные TCP и UDP запросы, что позволяет скрыть использование VPN подключения. Пакеты данных шифруются 256-битным шифрованием, а для его работы нужно только соответствующее клиентское приложение. PPTP – самый простой программный протокол. Используется для установления связи типа точка-точка. Для авторизации использует пароль. Шифрование отсутствует, его область применения — настройка соединений программными средствами операционных систем L2TP, IPSec. L2tp это более совершенная версия PPTP, но шифрование у протокола по-прежнему отсутствует. L2TP используется в связке с IPSec – протоколом, шифрующим пакеты данных и обеспечивающим безопасность. Главный недостаток IPsec – сложная настройка клиентских приложений. PPTP или IPSec гораздо менее стабильные протоколы, чем OpenVPN. Хотя для настройки виртуальной сети через PPTP не требуется никаких дополнительных программ, PPTP требует поддержки GRE47, из-за чего может нестабильно работать под сетевым экраном (NAT) и требовать долгих настроек.
Как установить и настроить VPN туннель
Туннелирование VPN может использоваться для объединения двух локальных сетей, к примеру внутренних сетей двух филиалов одной организации для безопасного обмена информацией. Сделать VPN туннель можно как при помощи стороннего ПО, вроде программы OpenVPN, так и при помощи встроенных средств ОС.
Создание ВПН туннеля
Самой простой задачей, для которой может потребоваться VPN туннели – получение доступа к домашнему ПК из любой точки мира. Нередки ситуации, когда человек уезжает в командировку в страну, в которой доступ к соцсетям или любимым ресурсам заблокирован. Чтобы не платить деньги ВПН-провайдерам, достаточно настроить vpn туннель между мобильным устройством и домашним ПК. Собственный VPN туннель будет совершенно бесплатным. Доступ к сайтам восстановится, а скорость работы будет всегда большой, ведь к домашнему ПК подключается только один пользователь.
Порядок настройки
В первую очередь, необходимо обеспечить статический ip-адрес для ПК, к которому планируется подключаться.
При помощи мобильного приложения OpenVPN Connect и файла конфигурации, можно подключиться по защищенному ВПН туннелю к домашнему ПК из любой точки мира.
Что такое VPN-туннель?
Узнайте больше о туннелях VPN.
VPN-туннель обеспечивает защиту и приватность
VPN-туннель (также известный как VPN — от англ. virtual private network, виртуальная частная сеть) — это зашифрованное соединение между вашим компьютером или мобильным устройством и Интернетом. Так как это соединение зашифровано, то проходящий по нему трафик нельзя перехватить, отследить или изменить.
Весь ваш трафик проходит через VPN-туннель, обеспечивающий ему полную защиту от посторонних глаз. Это ограждает все ваши онлайн-действия, переписку и любой другой трафик от не в меру любопытных интернет-провайдеров, правительства или хакеров, отслеживающих действия подключившихся к публичным точкам доступа Wi-Fi пользователей.
VPN-туннель скрывает ваше местоположение
VPN-туннель не только защищает ваши данные от перехвата, но и скрывает ваш IP-адрес, с помощью которого посторонние смогут идентифицировать вас во время работы в Интернете. Но когда вы подключитесь к VPN, сайты будут видеть уже не ваши исходные IP-адрес и местоположение, а, собственно, выбранного вами VPN-сервера.
Таким образом, VPN-туннели помогают обойти цензурные блокировки как локальных сетей, так и самих сервисов, к которым вы хотели бы получить доступ.
Типы протоколов VPN-туннелирования
ExpressVPN supports a variety of protocols for all your needs. The app will choose its optimal configuration automatically, but advanced users have the opportunity to configure their VPN tunnel manually.
In addition to offering standard protocols, ExpressVPN built Lightway to outdo them all in speed, reliability, and security. Give it a try to see for yourself. Learn more about Lightway.
Строим туннели. Разбираемся с новинками VPN
Содержание статьи
При работе с облачными сервисами важна не только скорость обработки и передачи данных — на первое место выдвигается гарантированный уровень безопасности. Данные, хранящиеся на внешнем ресурсе, ни в коем случае не должны попасть в чужие руки. C другой стороны, постоянно появляются сообщения о попытках государств что-нибудь да заблокировать. Наверное, поэтому в последнее время вырос интерес к VPN-решениям, и наряду с уже традиционными IPsec/XFRM и OpenVPN в Linux стали активно развиваться еще несколько проектов. Сегодня тебя ждут четыре интересных экземпляра: SoftEther VPN, WireGuard, FreeLAN и GoVPN.
SoftEther VPN
SoftEther VPN — академический проект японского Цукубского университета (University of Tsukuba), распространяемый под лицензией GPLv2. Главной его особенностью является поддержка нескольких VPN-протоколов, совместимых с оригинальными клиентами. Это позволяет вместо парка серверов из проприетарных и open source решений использовать для подключения клиентов, работающих под управлением разных ОС, одно приложение. И просто выбирать нужный протокол в зависимости от конкретной ситуации. Поддерживаются: SSL-VPN (HTTPS), IPsec, L2TP, MS-SSTP, L2TPv3, EtherIP и OpenVPN. SoftEther VPN работает в режимах remote-access и site-to-site, на уровнях L2 (Ethernet-bridging) и L3 (IP). В случае замены OpenVPN мы получаем более простую конфигурацию. Есть генератор ovpn-файлов для быстрого подключения VPN-клиента. Замена SSTP VPN позволяет отказаться от использования серверов на базе Win2k8/2012, требующих лицензии. Собственный протокол обеспечивает прохождение Ethernet поверх HTTPS (отсюда и название проекта — Software Ethernet), характеризуется хорошей пропускной способностью и низкой латентностью. Его использование дает возможность прозрачно соединить несколько Ethernet-сетей в одну, то есть отпадает необходимость в дополнительных решениях Ethernet-over-IP.
И главное — он совместим с NAT и работает через стандартный 443-й порт, который обычно не блокируется брандмауэрами провайдеров. Эта возможность позволяет скрыть вообще использование VPN: со стороны трафик выглядит как обычный и не обнаруживается технологиями Deep Packet Inspection. Собственно, поэтому он и стал очень популярен в Китае, где его используют для обхода Великого китайского файрвола. При этом на стороне клиента реализован виртуальный сетевой адаптер Ethernet, а на сервере — виртуальный коммутатор. Большой плюс — наличие NAT Traversal, включенной по умолчанию, то есть не нужно просить админа открыть доступ к VPN-серверу, находящемуся во внутренней сети. Но и это еще не все. В сетях с ограниченным доступом, у которых блокируются все TCP- и UDP-пакеты (например, публичные Wi-Fi), для создания VPN можно использовать протоколы ICMP и DNS, обычно не блокируемые брандмауэром. Поддерживается Dynamic DNS, позволяющий получить доступ при динамически меняющемся IP-адресе. Для этого реализован сервис VPN Gate, называемый VPN Azure Cloud Service, — к нему можно организовать соединение из внутренней сети и затем при необходимости свободно попадать внутрь сети. Клиентская часть содержит специальный плагин VPN Gate, позволяющий отслеживать смену IP и быстро подключаться к VPN Gate.
Обеспечивается высокая производительность и скорость соединения 1 Гбайт/с без существенных ограничений по объемам ОЗУ и минимальной нагрузке на процессор. Поэтому требования к серверной части очень невысоки. По тестам SoftEther VPN обходит на том же оборудовании оригинальные решения. Поддерживается шифрование AES-256 и RSA-4096, IPv4/IPv6, журналирование трафика и событий. Аутентификация пользователей локальная, RADIUS и домен Windows.
Далее, отвечая на вопросы vpncmd (или при помощи Server Manager), настраиваем параметры подключения.
Управлять SoftEther VPN можно при помощи графического интерфейса
WireGuard
WireGuard — результат исследований автора проекта Джейсона Доненфилда (Jason A. Donenfeld), главы компании Edge Security. Продукт со встроенной криптографией, одновременно простой в использовании и в реализации (чуть более 4000 строк кода), что существенно выделяет его среди остальных решений. Например, его код легче проанализировать, чем все, что написано в рамках *Swan/IPsec или OpenVPN. Самый молодой проект обзора. О нем заговорили в середине лета 2016-го после публикации анонса в списке рассылки разработчиков ядра Linux, где был представлен патч к ядру. Хотя сам проект развивается уже несколько лет и прошел стадию рецензирования криптографии, то есть его можно внедрять в основное ядро.
VPN-соединение инициализируется (handshake) путем обмена открытыми ключами и напоминает подход, применяемый в SSH. Все остальное прозрачно обрабатывается WireGuard, нет необходимости беспокоиться о ключах, роутинге, контроле состояния и прочем, это все забота WireGuard. Возможно использование симметричного шифрования, но это потребует чуть больших настроек. Маршрутизация производится по ключам шифрования, для этого к каждому сетевому интерфейсу привязывается закрытый ключ. Для обновления ключей handshake происходит через определенное время или по сигналу, что ключи устарели. Для согласования ключей и соединения вместо собственного демона в пространстве пользователя используется механизм Noise_IK из Noise Protocol Framework, похожий на поддержание authorized_keys в SSH, без усложнений в виде поддержки x509 и ASN.1.
Для шифрования применяются потоковый шифр ChaCha20 и алгоритм аутентификации сообщений (MAC) Poly1305. Для генерации совместного секретного ключа — протокол Диффи — Хеллмана на эллиптических кривых в реализации Curve25519, предложенной Дэниелом Бернштейном. Для хеширования используются BLAKE2s (RFC 7693) и SipHash-2-4. Избежать replay-атаки позволяет метка времени TAI64N, пакеты с меньшей меткой времени отбрасываются.
Передача данных осуществляется на третьем уровне ISO через инкапсуляцию в пакеты UDP. Поддерживаются IPv4 и IPv6, инкапсуляция v4 в v6 и v6 в v4. Может работать за NAT и файрволом. Поддерживается смена IP-адреса VPN-сервера без разрыва соединения с автоматической перенастройкой клиента.
После установки в системе появляется новый сетевой интерфейс wg0, который может быть настроен штатными инструментами ipconfig/ip-address и route/ip-route. Специальная утилита wg позволяет установить секретный ключ устройства и указать список ассоциаций для клиентов (его публичный ключ, разрешенный IP).
Для установки понадобится дистрибутив с ядром Linux >4.1. Пакет можно найти в репозиториях основных дистрибутивов Linux. Для Ubuntu 16.04 есть PPA.
Самостоятельная сборка из исходных текстов также несложна. Поднимаем интерфейс, генерируем пару ключей (для примера сохраняем в файлах privatekey и publickey):
Получаем публичный ключ от клиента и создаем соединение.
Возможно использование PresharedKey (генерируется командой wg genpsk), который добавляет еще один уровень симметричного шифрования к имеющемуся шифрованию с открытым ключом. Для пира можно указать PersistentKeepalive, позволяющий поддерживать соединение из-за NAT и файрвола. Поднимаем интерфейс:
Для удобства лучше заранее подготовить конфигурационный файл, содержащий секцию interface и секции peer. Формат можно увидеть, введя wg showconf.
Подходит как для небольших встроенных устройств вроде смартфонов, так и для магистральных маршрутизаторов. Тесты показали, что WireGuard имеет примерно в четыре раза лучшую пропускную способность и в 3,8 раза более отзывчив по сравнению с OpenVPN (256-bit AES c HMAC-SHA-2–256). Здесь сказывается не только реализация в виде модуля ядра, тогда как OpenVPN работает в userspace. Повышение производительности обусловлено отказом от использования CryptoAPI ядра, работающего достаточно медленно. Вместо него в WireGuard задействованы собственные реализации ChaCha20, Poly1305, BLAKE2s и Curve25519, которые позиционируются как быстрые и безопасные аналоги AES-256-CTR и HMAC, их программная реализация позволяет добиться фиксированного времени выполнения без аппаратной поддержки.
Также WireGuard благодаря меньшим задержкам чуть лучше выглядит в производительности по сравнению с IPsec (256-bit ChaCha20 + Poly1305 и AES-256-GCM-128), но вот настройки гораздо проще.
Пока WireGuard доступен только для Linux, после тестирования предполагается портировать в другие ОС. Код распространяется под лицензией GNU GPLv2.
Настройка WireGuard 
Смотрим конфигурацию WireGuard
FreeLAN
FreeLAN — мультиплатформенный VPN-клиент, который распространяется по лицензии GNU GPL и относится к так называемому классу Full Mesh, то есть использует P2P-технологии. Проект относительно молодой, активно начал продвигаться только с 2013 года. Его главное отличие от других проектов — это выбор варианта архитектуры: клиент-серверная (как привычный VPN, клиенты в зависимости от установок могут или не могут обмениваться данными друг с другом, сервер может выступать как релей), P2P (клиенты подключаются друг к другу напрямую) и смешанный (оба варианта). Таким образом, можно гибко настроить VPN практически под любые условия. Например, сервер может понадобиться, чтобы получать доступ во внутреннюю сеть или для контроля соединений, в остальных случаях можно позволить подключаться напрямую.
Основой служит собственный протокол FSCP (FreeLAN Secure Channel Protocol), базирующийся на UDP. Может работать как на уровне Ethernet, устанавливая прямые Ethernet-соединения между узлами, так и на уровне IPv4/IPv6. Предусмотрена авторизация по секретному слову и по X.509-сертификатам, минимальный размер открытого ключа RSA — 1024 бит, рекомендуемый — 2048 бит, в качестве симметричного ключа используется AES-256. Сессии имеют ограниченный срок службы, после окончания которого перезапускаются, сообщения содержат счетчики и контролируют время, что позволяет избежать replay-атак. Для поддержания сеанса отправляются сообщения keep-alive. Заголовок сообщения подписывается частным ключом или HMAC-SHA-256, если используется pre-shared-ключ. В общем, выбор в настройках очень большой.
Поддерживаются Win, Linux, macOS, Raspberry Pi. Пакет есть в репозиториях основных дистрибутивов, поэтому установка сложностей не вызывает. По факту программа представляет собой один бинарник, поэтому создавать сети очень просто.
По умолчанию сервер откроет порт UDP/12000 на всех интерфейсах, виртуальный интерфейс получит адрес 9.0.0.1. Используя дополнительные параметры, их можно переопределить, как и указать сертификаты. Подключаемся к серверу с другого узла, присвоим ему другой внутренний IP:
Для удобства все настройки можно поместить в конфигурационный файл. При установке в Ubuntu уже есть готовый шаблон /etc/freelan/freelan.cfg, который будет прочитан при запуске, а поэтому лучше сразу внести в него параметры. Альтернатива FreeLAN — PeerVPN или Cjdns, в которых также используют распределенные технологии.
Поднимаем сервер FreeLAN 
Конфигурационный файл FreeLAN
GoVPN
GoVPN — легкий и простой в настройке демон VPN, предназначенный для создания шифрованных и аутентифицированных каналов связи поверх UDP или TCP. Среди задач проекта — безопасный код, который легко читать и анализировать, безопасность, устойчивость к DPI/цензуре. Фактически GoVPN просто туннелирует кадры Ethernet — ни больше ни меньше. Нет никаких особых инструментов для управления IP, но для этого можно самостоятельно написать скрипты. Использует TAP сетевые интерфейсы, в настройках можно задавать его имя. MTU конфигурируются относительно каждого клиента отдельно. Написан на языке Go и распространяется под лицензией GPLv3. Для согласования ключей используется протокол с двусторонней аутентификацией сторон по парольной фразе (PAKE DH A-EKE: Diffie — Hellman Augmented Encrypted Key Exchange). Клиент для подключения вводит парольную фразу, на серверной стороне хранится верификатор, который нельзя использовать с клиентской стороны, поэтому даже при взломе сервера хакер не может выдавать себя за клиента.
Реализовано три режима работы:
В последних двух режимах благодаря генерированию постоянного шумового трафика удается скрывать длину сообщений и сам факт передачи полезной нагрузки. Имеет свойство нулевого неразглашения, при котором невозможна offline-атака по словарю, устойчив к replay-атакам через использование одноразового кода аутентификации сообщения (message authentication code) и синхронизацию времени (опционально). Предусмотрена ротация сессионных ключей и отправка heartbeat для поддержания работы через NAT или файрвол. Для хеширования парольных фраз задействован Balloon (в релизе 6.0). В релизе 5.0 это был Argon2d, еще ранее PBKDF2. Поэтому версии несовместимы.
Есть нешифрованный режим, также обеспечивающий конфиденциальность и аутентичность данных благодаря технологии chaffing and winnowing. Он позволяет обойти ограничения на использование криптографических инструментов в некоторых странах. Вместо шифрования применяются алгоритмы аутентификации и передача множества лишних пакетов (получатель просто отбирает те, которые ему подходят). Но это увеличивает каждый пакет на 4128 байт, поэтому режим требователен и к процессору, и к лишнему передаваемому трафику.
Совместим с IPv4 и IPv6. Возможно подключение через внешний HTTP-прокси, клиент также имеет встроенный режим HTTP-прокси, который можно использовать для доступа к серверу. Для получения статистики о подключенных клиентах в режиме реального времени в JSON-формате используется встроенный HTTP-сервер. Поддерживается работа в GNU/Linux и FreeBSD. Сервер конфигурируется с использованием YAML-файла.
Готовых пакетов проект не предлагает, только исходные тексты, для сборки понадобятся пакеты uml-utilities и golang. Хотя неофициальные порты появились уже в некоторых дистрибутивах. Дистрибутив постоянно развивается, и часть инструкций по настройке уже недействительна.
Настройка клиента в GoVPN
Заключение
Каждое из представленных решений имеет свои плюсы, стоит присмотреться и выбрать нужное в зависимости от планируемых задач.
Туннели и VPN, устойчивые к DPI
Мы живем в интересное время. Я бы даже сказал, в удивительное. По одну сторону мы видим неких лиц, которые очень хотят знать, о чем между собой разговаривают другие люди, и очень хотят указывать им, что можно читать, а что нельзя. С другой стороны граждане, которые хотят отстоять свои права тайны личной переписки и свободного получения информации, и не хотят, чтобы факты этой самой переписки и получения этой самой информации были использованы против них. Бонусом страдает огромное количество сторонних сайтов, сервисов и бизнесов, которых задевает «ковровыми блокировками».
Но нет, эта статья не об обществе, а о технологиях.
Техническая грамотность людей, благодаря всему происходящему, тоже растет. Если раньше слова «VPN» и «прокси» были знакомы только IT-специалистам, то теперь даже домохозяйки их знают, и более того — используют то, что эти слова означают.
Вообще, новости в последнее время приходят весьма занятные. Например, предоставление услуг VPN и аналогичных для шифрования трафика и обхода блокировок ныне наказуемо, а в Китае так за это вообще сажают в тюрьму. А не так давно РКН начал применять анализ пакетов для блокировки протокола MTProxy. Можно также обратиться к опыту стран-собратьев, которые наиболее преуспели в таких делах: Китая, Ирана, Казахстана, Венесуэлы. В Венесуэле, например, вполне конкретно блокируют прямые подключения к Tor и обфусцированный трафик к мостам. Исходя из всего этого, можно предположить, что будущее ждет нас тоже очень интересное, особенно, если «ответственные лица» перестанут устраивать тупые факапы раз за разом, а будут действовать умнее и изощреннее.
На Хабре неоднократно в комментариях озвучивали прогнозы как дальше может происходить борьба с технологиями шифрования для обычных граждан. Анализируя озвученные мысли и посмотрев на свидетельства из других стран, я попробовал предположить, в какую сторону могут дальше двинуться меры по ограничению связи. DistortNeo и shifttstas подкинули еще несколько интересных идей, и в итоге я пообещал el777 все-таки дописать эту статью.
С фильтрами по ACL всё в целом ясно. Они действуют уже сейчас, и с ними с переменным успехом получается и не получается бороться (хотя существуют вполне себе пессимистические прогнозы). С DPI все интереснее.
Способы «определения» типа трафика у DPI можно разбить на две группы:
Можно разбить трафик на несколько групп и предположить, что будут делать с каждой из них.
То есть, при желании маскироваться под специальные протоколы, или же обфусцировать соединения, чтобы было невозможно определить их тип, придется так же позаботиться о создании «шума», препятствующего выявлению реально паттернов обмена. Пока что подобных разработок мне на глаза не попадалось.
Про разные ICMP и DNS туннели можно даже не вспоминать — большой объем трафика «куда не надо» по ним тоже автоматически вызывает подозрения.
5. TLS и SSL, HTTPS. Резать подчистую невозможно, поскольку это автоматически означает блокировку всего Интернета. Анализ паттернов не имеет смысла, поскольку веб-серфинг — как раз-таки и есть основное предназначение использование HTTPS. Из всего вышеперечисленного, SSL/TLS на 443 порту выглядит самым «не подозрительным» и надежным вариантом. Следовательно, давайте и попробуем замаскироваться под него.
Маскируемся
Для рассмотрения было решено выбрать решения Streisand и SoftEther.
Streisand — целый набор различных сервисов: OpenConnect/AnyConnect, OpenVPN, stunnel, Shadowsocks, WireGuard. Все это ставится в автоматическом или полуавтоматическом режиме «под ключ», и на выходе пользователь получает сконфигурированный сервер, а также файлы и подробную документацию по настройке клиентов.
SoftEther — VPN-сервер, который может поднимать L2TP/IPsec, OpenVPN, SSTP, и другие протоколы, а также имеет свой собственный протокол «SSL-VPN», который, по заявлениям авторов, неотличим от обычного HTTPS-трафика.
OpenConnect/AnyConnect. Опенсорсная реализация протокола AnyConnect SSL от Cisco. При установлении соединения видны не только пакеты TLS (TCP), но и DTLS (UDP). DTLS в принципе тоже много где используется «в мирных целях», но это уже совсем не похоже на «обычный HTTPS». Впрочем, если порезать UDP-трафик на фаерволе, то AnyConnect сразу переключается обратно на TCP и со стороны выглядит, опять же, целиком и полностью как обычный TLS, и даже аутентификация внутри зашифрованного тоннеля проходит почти как в HTTP.
Shadowsocks. Шифрованный SOCKS-прокси. Судя по всему, при желании может быть детектирован, однако существуют плагины, маскирующие его под «чистый HTTPS». Так же есть плагин для работы через websockets, но об этом чуть позже.
WireGuard. Судя по описанию, имеет хорошо закрученное шифрование и механизм установки сессии, но весь обмен происходит по UDP. Wireshark определяет тип пакетов как нечто совсем невнятное, а какое мнение обо всем происходящем сложится у стороннего DPI — очень и очень большой вопрос. Upd: Новые версии определяют Wireguard однозначно как Wireguard, так что ответ на вопрос очевиден.
obfs3, obfs4. Обфуцируют пакеты так, что со стороны они выглядят абсолютно случайным набором значений. То есть попадают под п.4 из списка выше.
SoftEther. Выглядит как HTTPS, но с одним подвохом. Кроме непосредственно TLS over TCP активно шлет пачками UDP-пакеты. Как удалось выяснить в документации, UDP может использоваться для ускорения передачи данных в том случае, когда он не зарезан на фаерволе. Данный функционал отключается в конфигурации, и после его отключения все становится как надо.
SSTP. VPN-прокотол от компании Microsoft. Нативно поддерживается в Windows, вспомогательным софтом в GNU/Linux. Со стороны выглядит как HTTPS, и Wireshark это вполне подтверждает.
Но это еще не все
Предположим, вы установили на хост VPN-сервер или конец туннеля и сконфигурировали, чтобы он слушал 443 порт. Казалось бы, все прекрасно, но есть одно НО: если мы маскируемся под HTTPS, проверить, что по факту висит на 443 порту можно просто попробовав уткнуться в этот порт простым браузером или CURL’ом, или еще каким угодно способом. В некоторых статьях подобный метод называется «опережающим подключением», и, как упоминается, уже вполне используется в Китае.
Следовательно, нам необходимо чтобы по 443 порту у нас отвечал самый обычный и порядочный веб-сервер. И вот тут встает интересная проблема.
Ни у одного из вышеперечисленных сервисов в основной документации не нашлось описания рабочего механизма port sharing’а. Вариант с SSLH не подходит, хотя бы потому, что sslh не способен разделить трафик между HTTPS и вышеуказанными сервисами. Как минимум, потому что если тип трафика без полной расшифровки смог отличить sslh — то сможет и DPI.
Большинство манов, наподобие этого, предлагают использовать Server Name Indication (SNI) — расширение TLS, позволяющее указывать имя хоста, и потом с помощью HAProxy, sniproxy и других тулов раскидывать подключения по сервисам. Проблема в том, что в современных реализациях TLS указанное при использовании SNI имя хоста передается plain text’ом, то есть в незашифрованном виде, и, следовательно, тоже может быть подсмотрено и использовано в дальнейшем.
Поэтому, будем импровизировать, и тут мне на ум пришли два варианта.
Port knocking
Port knocking как раз предназначен для активации «скрытых сервисов» на сервере. Например, подобным образом часто закрывают «наружу» порт, на котором висит SSH-демон, чтобы избежать брутфорса и использования 0-day уязвимостей. В классическом варианте (см. например реализацию демона knockd) под нокингом обычно понимают попытки установки соединения или посылку пакетов на определенные порты хоста в определенной последовательности, в результате чего демон вас «опознает» как своего, и активирует правило фаерволла, открывающее доступ на определенный порт только с вашего IP.
В нашем же случае, этот вариант не совсем приемлем. Во-первых, сами «нестандартные» порты могут быть заблокированы где-то по пути, а во-вторых, сама процедура при анализе со стороны может выглядеть подозрительно. Раз уж мы маскируемся под HTTPS, то и «стучаться» нужно по HTTPS.
Как ни удивительно, но HTTP/HTTPS нокеров с требуемой функциональностью не нашлось, и поэтому на свет родился нокер с романтичным названием Labean (гусары, молчать!).
Дано: наш сервер, на котором на 443 порту крутится Nginx c корректно настроенными сертификатами и выдает какой-нибудь вполне безобидный контент, например, GIF’ки с котиками, ISO-образы дистрибутивов GNU/Linux, или зеркало Википедии и библиотеки Мошкова.
При этом в конфиге Nginx затаились строки вида
Далее через N секунд (да, поддерживается автоматический таймаут) выполняется команда, отменяющая вышеуказанное правило фаервола, и таким образом наше установленное подключение остается висеть, но подключиться к сервису снова даже с нашего IP без повторного дерганья нокера уже не выйдет.
Либо можно не использовать автоматический таймаут, а вручную деактивировать сервис, запросив URL наподобие указанного выше, только с /off в конце.
Таким образом можно сконфигурировать даже несколько разных сервисов, в том числе используя IPv6 (v6-адреса в заголовке типа X-Real-IP также поддерживаются).
Нокер написан на Go, не требует внешних зависимостей, прост как топор, и вполне себе работает. Исходники, подробное описание и примеры конфига nginx и init-скриптов можно найти на Github:
https://github.com/uprt/labean
Websockets
Вторая идея озарила еще более неожиданно: лучшее средство замаскировать туннель внутри HTTPS — использовать общепринятые стандартные инструменты. Современные Web-технологии давно уже содержат решение для установления связи поверх TCP между браузером и сервером, и имя ему Websocket (RFC 6455). Клиент формирует особый HTTP-запрос, на который сервер отвечает определенным образом, и после небольшого хендшейка мы можем начинать передачу данных по этому же TCP-соединению. Со стороны, соответственно, все выглядит в точности как обычный HTTPS и не требуется установки никаких дополнительных соединений.
Еще одним существенным преимуществом варианта с WS является то, что веб-сокеты — стандартная и распространенная технология, и они поддерживаются многими CDN, например, Cloudflare даже на бесплатном тарифе. Таким образом, это дает нам возможность повысить надежность нашей схемы: при блокировке по IP вашего CDN/proxy сервера вы сможете все равно подключиться к нему через CDN, либо же наоборот по умолчанию работать с этим вашим VPN/proxy сервером через CDN, скрывая его реальный адрес от сторонних наблюдателей.
Реализаций WS-туннелей существует несколько (есть даже вариант на Haskell), я для теста взял wstunnel, сделанный на nodejs и не прогадал, все завелось легко и с первого раза.
Лишь один нюанс был не прояснен в документации. Для запуска клиента предлагается указывать просто wss://-адрес, типа
В нашем же случае, необходимо «отделить» ws-подключения к серверу туннелирования от запросов «обычного» сайта. Изучив исходники wstunnel, я пришел к выводу, что ничего не помешает удлинить URI после имени хоста каким-нибудь уникальным идентификатором:
и оказался прав: все заработало с первого раза
Снова рассмотрим наш сервер, на котором на 443 порту запущен Nginx c каким-нибудь безобидным сайтом.
В конфиг нужно добавить proxy-проброс для нашего Websockets-туннеля:
После чего мы можем тайным образом поднимать наш websockets-туннель. Поверх туннеля можно пустить подключение к обычному SOCKS-прокси (например, Dante), или OpenVPN, хотя, как по мне, это уже будет избыточно.
Если у вас RHEL подобный дистрибутив, и включен SELinux, и в логах nginx видны ошибки типа
2018/07/05 13:28:03 [crit] 7724#0: *11 connect() to 127.0.0.1:8081 failed (13: Permission denied) while connecting to upstream, client: IP_ADDRES, server: _, request: «GET /hiddenws/?dst=localhost:22 HTTP/1.1», upstream: «127.0.0.1:8081/hiddenws/?dst=localhost:22»,
то вам нужно разрешить демону подключаться к необходимому порту:
Спасибо Renatk за то что обратил внимание и предложил решение.
Единственный минус такого подхода — кроме непосредственно SOCKS- или VPN-клиента на устройстве также нужно иметь клиент wstunnel, что может быть сложным в случае использования смартфона или другого «недесктопного» устройства.
Кроме того, существует плагин v2ray для shadowcocks, позволяющий использовать websockets как транспорт для shadowsocks. Найти его можно здесь: https://github.com/shadowsocks/v2ray-plugin
Несколько советов
— Установите на VPN-сервере какое-нибудь стандартное значение MTU, например 1400;
— Назначьте вашему VPN-серверу 2 IP-адреса. На один он будет принимать подключения к VPN/прокси, а с другого будет уходить исходящий трафик;
— Для «выходного» IP-адреса закройте все порты, отключите ответ на ICMP ping;
— Пропишите для вашего сервера какое-нибудь безобидное reverse DNS имя, похожее на пул доступа интернет-провайдера, например, gateway-001.somehomeisp.net;
— Для резолва доменов клиентами вашего VPN/прокси используйте DNS-сервера проекта OpenNIC;
Все эти меры помогут пресечь выявление туннелей недобросовестными ресурсами (подробнее здесь).
Вместо заключения
Как на самом деле будет развиваться социально-техническое противостояние, мы знать не можем — только предполагать. Воплотятся ли в жизнь предположения, изложенные в статье, не воплотятся — узнаем со временем, как и о том, что будет дальше. Да, маскировка под HTTPS тоже не панацея от всего — например, делать это может быть опасно, если будут введены какие-либо реальные наказания за «использование несертифицированных средств шифрования»/ознакомление с заблокированными ресурсами/etc., или бесполезно, если всех обяжут устанавливать некий «сертификат безопасности», как это некоторое время назад хотели сделать в Казахстане.
Пока еще, к счастью, ни до того, ни до другого не дошло ни в одном из известных нам государств, и если оно случится — это знак, что пора эвакуироваться, причем не из страны, а с планеты.
Берегите себя.