Translation(s): Русский

(!) ?Обсуждения


strongSWAN — полноценная реализация IPsec для ядер Linux версий 2.0, 2.2, 2.4, 2.6 и выше.

OpenSWAN начал разрабатываться как форк прекратившего в настоящее своё существование проекта FreeS/WAN (Free Secure Wide-Area Networking), релизы продолжают выпускаться под свободной GNU General Public License. В отличие от проекта FreeS/WAN, OpenSWAN разрабатывается не только специально под операционную систему GNU/Linux.

This document is intended to give an introduction to strongSwan for new users (or existing users with catching-up to do).Этот документ предназначен, чтобы дать введение в strongSwan для новых пользователей (или существующих пользователей с догоняющего делать).

Предварительные требования



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

Защита сети


strongSwan представляет собой комплексное IPsec-решение для обеспечения шифрования и аутентификации между серверами и клиентами. strongSwan также используется для защиты связи с удалёнными сетями, таким образом нет разницы между удалёнными и локальными подключениями.

Далее в справочном руководстве вы найдёте десятки детальных примеров полной настройки под рассмотренные выше и подобные различные ситуации.

Обратите внимание: Термин Road Warrior в общем понимании связан с людьми, которые основную часть своего времени проводят в пути (вдали от своего офиса или домашнего компьютера), но также при этом активно используют свой ​​ноутбук и/или телефон. Таким людям очень часто бывает необходим доступ к локальной сети/вычислительным ресурсам, которые доступны только в офисе или дома, и для того чтобы подключаться к домашним или офисным ресурсам этим людям как раз требуется виртуальная частная сеть (Virtual Private Network, VPN) или различные аналоги для подключения.

Основы IKE и IPsec


strongSwan в основном манипулирует демоном, который использует протоколы Internet Key Exchange (IKEv1 и IKEv2) для установки соединения связей (ассоциаций) безопасности (Security Associations, SA) между двумя пирами. IKE обеспечивает взаимную строгую аутентификацию у обоих пиров и получает уникальные криптографические сессионные ключи. Такие IKE-сессии часто обозначаются как "IKE_SA" далее в этом справочном руководстве.

Кроме аутентификации и ключей, фактически IKE также предоставляет средства для обмена информацией о различных настройках и производит согласование (связывает) с IPsec SA, которые часто называют как "CHILD_SA". Связи (ассоциации) безопасности IPsec SA в свою очередь определяют какой именно сетевой трафик должен быть защищён, каким образом сетевой трафик должен быть зашифрован и каким образом будет производиться аутентификация сетевого трафика (проверка подлинности).

CHILD_SA всегда на самом деле состоят из двух компонентов:

  1. фактические IPsec SA, описывающие алгоритмы и ключи, используемые для шифрования и аутентификации трафика
  2. а также политики, определяющие, какой именно сетевой трафик будет использовать определённую конкретную ​​SA

Политики работают в обоих направлениях, а трафик, соответствующий политике "входящий", будет разрешён только после расшифровки трафика.

Фактический IPsec-трафик не обрабатывается strongSwan, вместо этого IPsec-трафик обрабатывается сетью и IPsec-стеком в ядре операционной системы.

Вышеуказанные различия между политиками и связями (ассоциациями) безопасности SA очень часто приводит к заблуждениям различного характера. Например, опять же, ссылаясь на изображении выше, если у хоста Луна (moon) есть работающий туннель Сайт-в-сайт к хосту Солнце (sun) (соединяющий две сети 10.1.0.0/24 и 10.2.0.0/24), а у хоста Кэрол (carol) есть установленное roadwarrior-подключение с хостом Солнце (sun) (от которого Кэрол получила виртуальный IPv4-адрес 10.3.0.10), то Кэрол (carol) не сможет автоматически общаться с Алисой (alice), даже если включена переадресация пакетов (forwading) у хоста Солнце (sun). Это происходит потому, что нет абсолютно никакой IPsec-политики, разрешающей трафик между Кэрол (carol) (10.3.0.10) и Алисой (alice) (10.1.0.10). Дополнительные связи (ассоциации) безопасности SA между Луной (moon) и Солнцем (sun), подключающие виртуальную подсеть 10.3.0.0/24 к виртуальной подсети 10.1.0.0/24, будет возможным решением для этой проблемы.

Более подробная информация про IPsec и IKE содержится здесь.

Основы аутентификации


Для проверки гарантии того, что пир с которым установлены IKE_SA действительно является тем за кого он себя выдаёт, пир обязан аутентифицироваться (не авторизоваться, а пройти проверку подлинности).

Для того чтобы это сделать, strongSwan предоставляет несколько способов:

1. Аутентификация с открытым ключом (Public Key Authentication, PKA): Этот способ для проверки подлинности пиров использует X.509-сертификаты RSA или ECDSA.

2. Предварительно согласованный ключ (Pre-Shared-Key, PSK): Предварительно согласованный ключ (PSK) является очень простым в развёртывании вариантом, но этот способ для усиления безопасности требует также соответствующей усиленной строгости ключа (PSK).

3. Расширяемый протокол аутентификации (Extensible Authentication Protocol, EAP): Этот способ охватывает несколько возможных методов аутентификации, некоторые из них основаны на аутентификации при помощи пары имя_пользователя/пароль (логин/пароль) (EAP-MD5, EAP-MSCHAPv2, EAP-GTC) или на аутентификации при помощи сертификатов (EAP-TLS), а некоторые могут даже туннелировать другие EAP-методы (EAP-TTLS, EAP-PEAP).

4. Расширенная аутентификация (eXtended Authentication, XAuth): XAuth предоставляет гибкую структуру проверки подлинности в IKE-v1. XAuth в основном используется для аутентификации при помощи пары имя_пользователя/пароль (логин/пароль). Кроме того, XAuth в основном используется в качестве второго способа (метода) аутентификации после взаимной аутентификации с либо сертификатами либо PSK. С гибридной аутентификацией IKE-v1, таким образом, можно аутентифицировать шлюз при помощи сертификата и использовать только XAuth для аутентификации клиента.

При помощи IKE-v2 можно использовать несколько циклов (кругов) аутентификации, например, для первого круга аутентифируется "машина" при помощи сертификатов, а затем, вторым кругом, "пользователь" при помощи пары имя_пользователя/пароль (логин/пароль), основываясь на схеме проверки подлинности, например, EAP-MSCHAPv2. Кроме того, можно использовать асимметричную аутентификацию, например, путём проверки подлинности шлюза при помощи сертификата и клиента при помощи пары имя_пользователя/пароль (логин/пароль), взяв за основу EAP-метод (аутентификация в первом цикле).

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

Файлы для настройки strongSWAN


Список файлов для настройки strongSwan:

  1. ipsec.conf: определяет параметры для настройки IPsec-подключений
  2. ipsec.secrets: определяет список ключей-паролей, здесь хранятся предварительно согласованные ключи (pre-shared keys, PSK) и приватные ключи (private keys)
  3. ipsec.d: каталог в котором хранятся сертификаты (certificates) и приватные ключи (private keys)
  4. strongswan.conf: позволяет настроить общие параметры настройки, т.н. подключать различные криптографические алгоритмы и дополнительные функции

Терминология

налево (left) и направо (right), используемые в файле ipsec.conf, обозначают две конечные (устанавливающие подключение) IKE_SA-точки, то есть

Вы можете это легко запомнить, смотря на первую согласную букву из первого слога у двух английских слов (left = local, right = remote) вроде всё очень просто!

Прочие источники, предоставляющие настройку strongSWAN

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

Установка


Установка strongSWAN описывается на отдельной страничке.

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

Вызов, запуск программы, и её техническое обслуживание

strongSwan обычно управляется при помощи одной команды "ipsec". Команда "ipsec" в самом начале запускает starter-демон, который в свою очередь, запускает и настраивает ключевой демон charon.

Подключение определяется как один уникальный раздел "conn" внутри ipsec.conf; произвести попытку установить подключение можно только в трёх различных случаях:

После того как была установлена связь SA, командой "ipsec down" можно убрать (разорвать связь с) "IKE_SA" или конкретные индивидуальные "CHILD_SA".

Whenever the ipsec.conf file is changed it may be reloaded with ipsec update or ipsec reload. Already established connections are not affected by these commands, if that is required ipsec restart must be used.

Всякий раз, при изменении содержимого файла "ipsec.conf", для того чтобы изменения вступили в силу, наберите команду "ipsec update" или "ipsec reload". Эти команды не затрагивают ранее установленные соединения любого подключения, но вдруг если вам потребуется переустановить соединения с подключениями заново, то в таком случае воспользуйтесь командой "ipsec restart".

В том случае, если файл "ipsec.secrets" или файлы из каталога "/etc/ipsec.d" были изменены, то воспользуйтесь командой "ipsec reread" для того чтобы изменения вступили в силу.

Сертификаты конечного субъекта, находящиеся в каталоге "/etc/ipsec.d/certs" не обновляются автоматически, сертификаты будут загружены только при помощи "ссылки" на них в параметрах настройки "left|rightcert" раздела "conn". Использование команды "ipsec purge" может потребоваться вам только для того, чтобы пересоздать заново файлы для настройки stronsSWAN.

Команда "ipsec list" используется для предоставления информации о кэше загруженных сертификатов, поддерживаемых алгоритмов и загруженных плагинов.

Логирование и мониторинг

Если вы столкнётесь с проблемами различного характера, то попробуйте увеличить уровень лога, скорее всего более детальный лог поможет вам понять, что именно пошло не так. Различные параметры настройки логирования описываются в справочном руководстве по stronSWAN.

Всякий раз, когда вы сталкиваетесь с сообщениями в журнале похожими на "received ... error notify", где вместо ... будет, к примеру, "NO_PROPOSAL_CHOSEN" или "TS_UNACCEPTABLE", то в таком случае, в первую очередь, вам потребуется проверить лог удалённого пира для того чтобы выяснить, почему пир сгенерировал упомянутое выше уведомление об ошибке.

Запуск демона командой "ipsec start --nofork" предотвращает форк демона и лог направляется непосредственно в консоль (в случае настройки логеров в strongswan.conf, убедитесь в том, что по крайней мере хотя бы один логер указывает на stderr (стандартный поток ошибок) или stdout (стандартный вывод)) .

Команды "ipsec status" и "ipsec statusall" предоставляют информацию про установленные и настроенные подключения. Под Linux пакет "iproute2" предоставляет такие команды как "ipsec xfrm state" и "ip xfrm policy" для запроса подробной информации про связи SA IPsec и политики установленные в ядре. Добавление ключа-параметра "-s" позволяет отобразить обширную подробную статистическую информацию, в т.ч. количество отправленных или невалидных пакетов. На других платформах команда "setkey" из пакета "ipsec-tools" предоставляет подобную информацию.

Для отладки в проблемных ситуациях часто также бывают полезны tcpdump и wireshark.

При проверке установленного подключения при помощи утилиты "ping" удостовертесь в корректно указанном IP-адресе источника (указывается с ключём-параметром -I), который предназначен для корректного выбора при захвате локального трафика (обратитесь также к настройке по типу Сайт-в-сайт которая расположена ниже).

PKI


To use certificate based authentication you'll need to create either self-signed certificates or setup a whole public-key infrastructure (PKI), consisting of a Certificate Authority (CA), optional intermediate CAs and end-entity certificates plus certificate revocation lists (CRL) or other methods like OCSP to verify the validity of certificates.

One of the easiest ways to generate certificates is to use the ipsec pki utility. Since setting up a whole PKI can be quite complex, we only provide instructions to get you started.

OpenSSL is also a widespread alternative to generate certificates, as are several GUI based CA management utilities. Commercial CA management tools like Microsoft's are also often used for large scale CAs.

Настройки для предоставления удалённого доступа


В этом разделе предоставлены примеры настройки для общих случаев использования удалённого доступа. В этих так называемых ситуациях, мобильные клиенты (?RoadWarriors) смогут подключиться в любой момент к удалённой (офисной, домашней) вашей сети.

Because these clients most likely connect from unknown IP addresses the gateway will use right=%any to literally accept connections from anywhere. To simplify routing traffic back to the clients and because roadwarriors are often located behind one or more NAT devices, the use of virtual IP addresses is necessary.

Так как такие клиенты, скорее всего, будут подключаться от неизвестных IP-адресов и шлюз будет использовать такой параметр настройки как "right=%any" для буквального обозначения - принимать попытки установить входящее подключение с любого компьютера. Для упрощения маршрутизации трафика идущего обратно к клиентам и так как мобильные клиенты roadwarriors практически всегда находятся за одним или несколькими устройствами NAT, необходимо использование виртуальных IP-адресов.

Виртуальные IP-адреса могут быть как от различающихся подсетей, так и из рабочей вашей подсети, в которой находится шлюз (при использовании farp и, при желании, DHCP плагинов).

Whether roadwarriors will send all traffic to the gateway or use split-tunneling, that is, only send traffic for specific destinations through the tunnel, is also something to consider. It is explained more detailed in Forwarding and Split-Tunneling. Стоит рассмотреть также ситуацию - будут ли roadwarriors отправлять весь трафик через шлюз или использовать сплит-туннелирование, то есть передавать трафик через туннель только для определённых конкретных конечных IP-адресов (или конечных IP-подсетей). Это разъясняется более детально в главе Пересылка трафика и сплит-туннелирование

Вышеупомянутая глава также объясняет, каким же образом трафик перенаправляется на хосты, которы находятся за шлюзом.

IKE-v2 (Windows 7/8, Linux, Android 4+, Mac OS X)


Различные настройки шлюза, детально рассмотренные в разделе Windows 7 справочного руководства, можно использовать для всех IKE-v2 клиентов. В обоих рассмотренных случаях из раздела Windows 7 используется аутентификация (проверка подлинности) шлюза при помощи сертификата, а тем временем клиенты будут либо аутентифицироваться при помощи сертификатов, либо использовать пару имя пользователя и пароль (логин/пароль). Оба способа настройки одновременно реализуются на шлюзе для того чтобы предоставить выбор клиентам - какой метод проверки подлинности является наиболее приемлемым вариантом?

При помощи плагина eap-radius можно запросто делегировать аутентификацию пользователя на сервер RADIUS (например, существующий DC Active Directory).

strongSwan VPN-клиент под Android 4 и выше, а также strongSwan-плагин под NetworkManager можно использовать с любой из этих настроек.

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

Как альтернатива, начиная с версии strongSWAN 5.1.0, можно воспользоваться charod-cmd, IKE-клиентом в режиме командной строки, который предоставляет простые средства для установки соединений (исходящих от клиента roadwarrior) с подключением.

Приложение stongSWAN под Mac OS X поддерживает IKE-v2 и обычную аутентификацию при помощи метода EAP.

IKE-v1 (iOS, Mac OS X, Android, Windows)


астройка, которая описана на страничках под IOS и под Mac OS X, будет работать для всех клиентов, которые поддерживают IKE-v1-метод аутентификации - XAuth.

Для Windows-хостов версией до ​​Windows 7 рекомендуется использовать сторонний IPsec-клиент, к примеру Shrew, вместо нативного клиента IKE-v1/L2TP.

Вместо генерации пары закрытый ключ/сертификат для каждого клиента, также вы можете использовать пару тот_же_самый_ключ/сертификат для всех клиентов. Фактическая аутентификация клиента будет выполняться при помощи метода XAuth (это похоже на гибридную аутентификацию, но зато будет также работать и для клиентов, которые не поддерживают этот метод, к примеру, некоторые версии IOS). Несмотря на тот факт, что пара закрытый_ключ/сертификат является "открытой для всех", тем не менее этот способ по-прежнему обеспечивает надлежащую аутентификацию шлюза, при этом значительно упрощая развёртывание VPN-клиентов.

Можно даже также воспользоваться методом XAuth при помощи PSK, но всё таки PSK не рекомендуется для деплоя при большом количестве клиентов.

Учётные данные XAuth, полученные от клиентов, можно проверять на том же самом RADIUS-сервере, который используется для аутентификации IKE-v2-клиентов при помощи плагина xauth-eap.

Настройки для способа Сайт-в-сайт


Для настройки подключений типа Сайт-в-сайт (между сайтами, между территориально удалёнными участками физических подсетей) можно обратится к любой ситуации из раздела "net2net" справочного руководства.

Наиболее важное различие по сравнению со случаем предоставления обычного (roadwarrior) удалённого доступа заключается в том, что инициатор на соединение к подключению не будет запрашивать виртуальный IP-адрес, а вместо этого, инициатор будет использовать параметр настройки "leftsubnet" для туннелирования трафика из одной или более локальных подсетей. Для IKE-v2 сразу несколько подсетей (в нотации CIDR) могут быть добавлены в значение параметра "left|rightsubnet", при этом они должны быть разделены запятыми. В том случае, если используется IKE-v1, то должен быть добавлен отдельный каждый раздел "conn" соответственно для каждой конкретной определённой подсети типов "left" и "right" сразу как только будет использована первая подсеть в параметре "left|rightsubnet" (Hint: при помощи раздела "conn %default" или ключевого слова "also" можно уменьшить объём каждого из разделов "conn" на несколько строчек).

Один момент, который часто смущает новичков в IPsec, тестирование ситуации "net-to-net" от имени любого из шлюзов часто требует принудительного указания IP-адреса источника (например, тестирование с утилитой "ping -I"), так как внешние IP-адреса любого из шлюзов могут просто напросто не входить в туннелированные подсети. В противном случае, либо просто добавьте внешние IP-адреса в список подсетей в "left|rightsubnet" либо добавьте определённую конкретную настройку хост-в-хост.

Настройки для способа Хост-в-хост


Установить подключение хост-в-хост совсем очень просто. В основном нужно настроить "right" на hostname или IP-адрес пира и настроить предпочитаемую аутентификацию, ни "leftsubnet" ни "rightsubnet" не должны быть определены явно в настройках.

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