Глава 10. Будущие направления

История OpenVPN была ухабистой - от неопытного новичка до широко используемого, почти мертвого и обратно. Разрыв в разработке с 2006 по примерно 2009 год был значительным, но тяжелая работа и преданность разработчиков, таких как Дэвид Соммерсет (dazo), Герт Доеринг (cron2), Штеффан Каргер и Самули Сеппанен, дали проекту недавнее успешное прошлое и светлое будущее.

OpenVPN доступен практически на всех доступных платформах. Snom (производитель IP-телефонов), например, включает в себя версию прошивки своего VOIP-телефона с включенным клиентом OpenVPN. pfSense, OpenWRT и другие WAP/брандмауэры операционных систем включают OpenVPN и (обычно) веб-интерфейс для управления развертыванием.

В последние годы OpenVPN был доступен на многих мобильных телефонах. Первый был доступен для Android, OpenVPN для Android от Арне Швабе. При этом использовался перенесенный драйвер tun и он не поддерживал VPN-режим в режиме tap (мост).

Однако приложение OpenVPN для iOS (Apple) появилось гораздо позже. OpenVPN Technologies Inc. потребовалось почти год, чтобы договориться с Apple о поддержке внешнего API VPN и предоставить доступ к этому API для их использования. На Android исходный код OpenVPN может быть перенесен на платформу, с некоторыми упущениями для tap, так как драйвер tap не был доступен на платформе. Из-за среды разработки на iOS клиент должен был быть написан с нуля. Джеймс Йонен написал за несколько месяцев почти полностью функциональный клиент на C++ и OpenVPN Connect был опубликован в App Store®.

Сильные стороны

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

Есть несколько вещей, которые OpenVPN делает хорошо. OpenVPN расширяемый, подключаемый и динамический. Он имеет функциональную поддержку IPv6, передачу шлюза по умолчанию (даже в сломанных сетях) и поддерживает общедоступные IP-адреса при сохранении соединений.

Кроссплатформенная поддержка непревзойденна для различных реализаций VPN.

Текущие слабости

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

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

Масштабирование на гигабитных скоростях и выше

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

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

Для этого требуются инструкции шифрования AES (известные как AES-NI), имеющиеся в современных процессорах, таких как процессоры Intel Core i7 и Xeon E5, а также в современных процессорах AMD. Также требуется, чтобы шифр кодирования был установлен на AES, например, с помощью --cipher aes-256-cbc как в конфигурации сервера, так и клиента.

Заметка

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

Здесь также играют роль операционная система и библиотека шифрования. Большинство настроек сервера используют библиотеки OpenSSL для шифрования и дешифрования. Поддержка набора команд AES-NI была включена только в OpenSSL 1.0.0. Например, CentOS 5 по-прежнему использует библиотеку OpenSSL (0.9.8e-fips), которая не поддерживает эти инструкции. Достаточно легко проверить, используют ли процессор и операционная система инструкции AES-NI. Используя команду openssl speed вы можете быстро определить производительность кодирования как для шифра OpenVPN по умолчанию (BlowFish или bf-cbc), так и для шифра AES (aes-256-cbc):

$ openssl speed -evp bf-cbc
[…]
type        …   256 bytes   1024 bytes    8192 bytes
bf-cbc      …  137977.26k   138565.97k    137470.47k

$ openssl speed -evp aes-256-cbc
type        …   256 bytes   1024 bytes    8192 bytes
aes-256-cbc    566760.53k   588199.94k    591250.12k

Этот тест проводился на процессоре Intel Core i7-4810MQ под управлением Fedora 20, и очевидно, что AES намного быстрее чем BlowFish. Мы можем с уверенностью заключить, что AES-NI поддерживается как процессором, так и операционной системой. Если мы отключим поддержку OpenSSL для инструкций AES-NI, влияние на производительность будет весьма существенным:

$ OPENSSL_ia32cap=0 openssl speed -evp aes-256-cbc
type        …   256 bytes   1024 bytes    8192 bytes
aes-256-cbc    120009.39k   264001.19k    262821.68k

Используя процессор, такой как i7 Core, можно достичь производительности более 500 Мбит в обоих направлениях, как было показано в Главе 9, Устранение неполадок и настройка.

Дополнительные улучшения могут быть получены с использованием --mssfix, --tun-mtu и --fragment. При совместном использовании может быть достигнуто увеличение скорости до 400 процентов.

Другие факторы могут способствовать проблемам с производительностью вне OpenVPN. Масштабирование сверх гигабитных скоростей потребует обширной модернизации OpenVPN, поскольку требует совершенно другого подхода к обработке таких высоких уровней трафика. Имейте в виду, что сетевой трафик обычно обрабатывается кусками по 1500 байт (обозначается как Maximum Transmission Unit (MTU)). Для гигабитного канала это означает, что ядру операционной системы и процессу OpenVPN необходимо обрабатывать примерно 80 000 пакетов в секунду. На 10-гигабитном канале это число возрастает до 800 000 пакетов, с которыми даже самые современные процессоры не так легко справляются. Увеличение значения MTU с 1500 до 9000 байтов также известного как гигантские кадры, уменьшает количество пакетов, не уменьшая при этом пропускную способность. Jumbo-frames должны поддерживаться всеми узлами в сети, иначе может возникнуть фрагментация пакетов.

Куда идем

Начиная с 2010 года, разработчики открытого исходного кода начали дискуссии о способах улучшения процесса сервера OpenVPN и повышения эффективности. Был определен ряд областей, которые можно улучшить. К счастью, начало этой работы было завершено переписыванием клиентского кода Джеймса для приложения iOS. Официальные дорожные карты для предстоящих v2.4 и будущих версий v3.0 можно найти в вики сообщества OpenVPN в следующих местах:

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

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

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

Полный список текущих ошибок доступен на трекере ошибок сообщества OpenVPN. Патчи всегда приветствуются в списке рассылки, и хорошо написанные и протестированные патчи обязательно получат быстрое одобрение. Ссылка http://community.openvpn.net/openvpn/report/1 приведет вас непосредственно к открытым отчетам об ошибках.

Улучшение поддержки сжатия

Начиная с версии 2.4, OpenVPN будет поддерживать различные механизмы сжатия VPN-трафика. В настоящее время поддерживается только сжатие LZO2, но в версии 2.4 вы также можете компилировать в поддержку алгоритмов сжатия Snappy и LZ4. Это может немного улучшить производительность в зависимости от типа трафика, который проходит через VPN. Обычный веб-трафик значительно повысит производительность, в то время как в трудносжимаемом трафике, таком как изображения или видеофайлы, вероятно, произойдет небольшое снижение производительности из-за дополнительных затрат на сжатие и распаковку каждого пакета.

Сжатие на клиенте

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

Новые криптографические процедуры

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

Надеемся, мы также увидим поддержку шифрования на основе GCM в версии 2.4. Шифрование GCM (Galois/Counter Mode) более эффективно и производительно, чем используемые в настоящее время процедуры шифрования CBC (Cipher Block Chain).

Шифрование с проверкой подлинности с помощью связанных данных (AEAD) также дебютирует в версии 2.4.

Смешанная аутентификация сертификата/имени пользователя

В настоящее время OpenVPN поддерживает аутентификацию с использованием сертификатов и/или имени пользователя и пароля, но тоже/или невозможно. Опция --client-cert-not-required фактически отключает проверку сертификата.

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

Параметр --client-cert-not-required будет объявлен устаревшим в ближайшем будущем и упоминается в дорожной карте v3.0.

Поддержка IPv6

Сетевой код в OpenVPN использует отдельные функции для путей кода IPv4 и IPv6. Пару лет назад произошел серьезный пересмотр работы с IPv4, но работа над функциями IPv6 так и не была выполнена. OpenVPN 2.3 поддерживает полностью собственный транспорт IPv6, а также инкапсулированный трафик. Использование DNS-серверов IPv6 и получение этой информации от DHCP не поддерживается, но включено в план для v2.4.

push "redirect-gateway ipv6" также есть в списке. Вы все еще можете имитировать маршрут по умолчанию с IPv6, передавая специальные маршруты вручную:

push "route-ipv6 ::/0 2600:dead:beef::1"

Разделение привилегий Windows

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

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

Первый из двух достигается путем предоставления интерактивной службы OpenVPN. Хайко Хунд впервые предложил такой подход в феврале 2012 года (http://thread.gmane.org/gmane.network.openvpn.devel/5685/focus=5728). Эта концепция включает в себя централизованную службу, которая действует как оболочка вокруг другого процесса OpenVPN. Будет установлено клиентское соединение от интерактивного пользователя OpenVPN или OpenVPN GUI и этот процесс будет подключаться к этой службе. Затем служба будет принимать аргументы от клиента и создавать актуальный VPN-туннель, установливать маршруты и другие параметры.

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

Чтобы быть полным, оболочка [=interactive service] также должна владеть закрытым ключом OpenVPN – в противном случае конфигурация будет копироваться непривилегированным пользователем, что должно быть предотвращено корпоративной моделью. Защита приватного ключа может быть выполнена путем хранения ключа в системном хранилище сертификатов/ключей и доступа к ключу через API криптографического поставщика, например Crypto API в Windows, PKCS#11 в Linux или Keychain на Mac. – Джеймс Йонан

Во-вторых, интерактивный сервис не должен разрешать доступ другим процессам (не OpenVPN) работать как тот же (текущий) пользователь:

Канал/сокет для привилегированного процесса [=interactive service] должен быть управляем доступом, чтобы его мог использовать только openvpn. Вы не захотите получить уязвимость эскалации привилегий, когда операции, которые обычно были бы привилегированными (например, изменение маршрута по умолчанию), теперь могут быть выполнены любым процессом в пользовательском пространстве, просто используя канал OpenVPN/сокет. –Джеймс Йонан

В-третьих:

Другие непривилегированные программы могут получить доступ к API-интерфейсам для этих оболочек [=interactive service], например, путем ввода маршрутов в API. Вредоносные программы, которые обычно были бы ограничены пользовательским пространством, теперь могут выполнять привилегированные операции, такие как изменение маршрута по умолчанию. Теперь конечный пользователь может подключиться к любому VPN-серверу по своему выбору (серьезное нарушение корпоративной модели). То, что вы фактически сделали с этой моделью - это ввели уязвимость эскалации привилегий, потому что операции, которые обычно требуют привилегий, такие как добавление маршрутов, теперь могут выполняться непривилегированным пользователем.

Второй подход использует два или три отдельных объекта COM+, как предложено Алоном Бар-Левом в марте 2012 года (http://thread.gmane.org/gmane.network.openvpn.devel/5755/focus=5869). При таком подходе необходимы три компонента: OpenVPN GUI, служба OpenVPN и сетевой обработчик OpenVPN.

OpenVPN GUI не сильно изменится по сравнению с тем, что есть сегодня. Он будет продолжать передавать задачи и обновления в бэкэнд-процесс. Поскольку нет текущего разделения привилегий, текущий GUI не должен обрабатывать какую-либо авторизацию. С использованием COM+ и сетевого модуля OpenVPN графический интерфейс пользователя может быть полностью непривилегированным.

Резюме

После нескольких лет работы в IRC-канале OpenVPN и на форуме поддержки OpenVPN среди пользователей администрирования сервера возникают некоторые постоянные трудности: базовые сети и маршрутизация, управление сертификатами X.509 и аутентификация пользователей или клиентов. Прочитав эту книгу, вы должны хорошо понимать эти концепции и основные механизмы. Различия между виртуальными сетевыми адаптерами tun и tap также обсуждались. OpenVPN - очень активный проект с открытым исходным кодом, который постоянно развивается. Методы и примеры в рамках освоения OpenVPN, скорее всего, не устареют в ближайшем будущем. Однако в коде возможны недостатки, поэтому мы настоятельно рекомендуем вам прочитать руководство (man page), доступное по адресу https://openvpn.net/index.php/open-source/documentation/manuals.html.

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

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