Linux charon что это

Обновлено: 07.07.2024

The strongSwan VPN suite uses the native IPsec stack in the standard Linux kernel. It supports both the IKEv1 and IKEv2 protocols.

charon is an IPsec IKEv2 daemon which can act as an initiator or a responder. It is written from scratch using a fully multi-threaded design and a modular architecture. Various plugins can provide additional functionality.

Другие пакеты, относящиеся к strongswan-charon

  • зависимости
  • рекомендации
  • предложения
  • enhances
  • dep: debconf система настройки пакетов Debian или debconf-2.0 виртуальный пакет, предоставляемый cdebconf, cdebconf-udeb, debconf
  • dep: iproute2 настройка сети и управление трафиком или iproute Пакет недоступен
  • dep: libc6 (>= 2.32) [не alpha, ia64] библиотека GNU C: динамически подключаемые библиотеки
    также виртуальный пакет, предоставляемый libc6-udeb
  • dep: libc6.1 (>= 2.32) [alpha, ia64] библиотека GNU C: динамически подключаемые библиотеки
    также виртуальный пакет, предоставляемый libc6.1-udeb
  • dep: libstrongswan (= 5.9.4-1) strongSwan utility and crypto library
  • dep: strongswan-libcharon (>= 5.9.4) strongSwan charon library
  • dep: strongswan-starter strongSwan daemon starter and configuration file parser

Загрузка strongswan-charon

Загрузить для всех доступных архитектур
Архитектура Размер пакета В установленном виде Файлы
alpha (неофициальный перенос) 102,1 Кб233,0 Кб [список файлов]
amd64 102,1 Кб236,0 Кб [список файлов]
arm64 102,1 Кб232,0 Кб [список файлов]
armel 101,6 Кб228,0 Кб [список файлов]
armhf 101,6 Кб228,0 Кб [список файлов]
hppa (неофициальный перенос) 102,4 Кб229,0 Кб [список файлов]
i386 102,1 Кб232,0 Кб [список файлов]
ia64 (неофициальный перенос) 104,4 Кб241,0 Кб [список файлов]
m68k (неофициальный перенос) 101,7 Кб232,0 Кб [список файлов]
mips64el 102,0 Кб233,0 Кб [список файлов]
mipsel 101,9 Кб229,0 Кб [список файлов]
ppc64 (неофициальный перенос) 102,6 Кб281,0 Кб [список файлов]
ppc64el 102,4 Кб281,0 Кб [список файлов]
riscv64 (неофициальный перенос) 101,4 Кб229,0 Кб [список файлов]
s390x 101,7 Кб232,0 Кб [список файлов]
sh4 (неофициальный перенос) 102,3 Кб228,0 Кб [список файлов]
sparc64 (неофициальный перенос) 101,9 Кб234,0 Кб [список файлов]
x32 (неофициальный перенос) 102,0 Кб232,0 Кб [список файлов]

Эта страница также доступна на следующих языках (Как установить язык по умолчанию):

Авторские права © 1997 - 2021 SPI Inc.; См. условия лицензии. Debian это торговый знак компании SPI Inc. Об этом сайте.

Кто бы мог подумать, что развернуть часть серверов компании в Amazon было плохой идеей.

В итоге поставленная задача — сделать дополнительный VPN-туннель между Amazon и инфраструктурой в РФ.

image



Кроме простого how-to опишу несколько особенностей в настройке, с которыми можно столкнуться.

Настройка файрвола и роутинга

Покупаем у пока еще не заблокированного хостера VPS за сумму, эквивалентную 10 000 монгольских тугриков в месяц, ставим CentOS 7, включаем пересылку пакетов


Добавляем в файрволе правила для приема пакетов IPsec

Настройка StrongSwan

Устанавливаем демон IPsec StrongSwan:


Делаем предварительные настройки в /etc/strongswan.d/charon.conf:


Настройка Strongswan может быть проведена двумя способами.

Старый способ, использующий демон strongswan, уже достаточно хорошо описан:

/etc/strongswan/ipsec.conf

Файл с паролями и сертификатами:

/etc/ipsec.secrets

Новый способ, использующий демон charon, появившийся в версии 5.2.0:

Вся конфигурация хранится в /etc/strongswan/swanctl/swanctl.conf

Рассмотрим два варианта настройки демона charon:

Одинаковые настройки аутентификации и шифрования для всех. Сделаем разными только PSK:

Индивидуальные настройки аутентификации и шифрования:

Поднятие туннелей с маршрутизаторами Cisco

Настраиваем GRE-туннели в CentOS


В настройке GRE-интерфейсов есть пара особенностей.

Первая — необходимо уменьшить MTU для корректного прохождения пакетов.

Второе — указать TTL, это понадобится в будущем, когда будем настраивать OSPF. Если этого не сделать, пакеты OSPF будут приходить на удаленный хост с TTL, равным единице (из-за GRE over IPsec), оставаясь без ответа. Соответственно устройства будут висеть в состоянии INIT/DROTHER, связности мы не дождемся. При этом корректные ответы ICMP могут сбить с толку.

Создаем туннель на Cisco 2951

Создаем туннель на Cisco CSR1000V

Настройка динамической маршрутизации на Quagga

Если вы используете динамическую маршрутизацию на основе OSPF, то следующим шагом логично было бы поднять демон OSPF на CentOS, настроив новые туннели в качестве резервного маршрута.

Настройка OSPF на CentOS

В качестве демона установим Quagga:


Создаем конфигурационный файл демона /etc/quagga/zebra.conf


Вес пути можно регулировать параметрами cost либо bandwidth, устанавливая их на нужных интерфейсах.

Устанавливаем права и включаем службу


Создаем конфигурационный файл демона /etc/quagga/ospfd.conf


Устанавливаем права и включаем службу


Далее можем запустить терминал vtysh и работать с Quagga в циско-подобном интерфейсе, например:

Настройка OSPF на Cisco 2951

Настройка OSPF на Cisco CSR1000V

Что осталось нерассмотренным

Я описал самый простой вариант. Конечно же, вы настроите обмен ключами, используя IKE v2, авторизацию по сертификату, добавите в файрвол дополнительную фильтрацию по адресам, сделаете OSPF с авторизацией и, при большом количестве маршрутизаторов, с разделением на area, измените значения hello-interval и dead-interval на интерфейсах.

Изначально VPN планировался только для организации канала между мини-роутером родителей и домашним «подкроватным» сервером, по совместительству выступающим в роли маршрутизатора.

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

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

К тому же некоей гражданке, внешне напоминающей Шапокляк, всюду бегающей со своим ридикюлем Пакетом и, вероятно, считающей что «Кто людям помогает — тот тратит время зря. Хорошими делами прославиться нельзя», захотелось тайком подглядывать в чужой трафик и брать его на карандаш. Придется тоже защищаться от такой непрошенной любви и VPN в данном случае именно то, что доктор прописал.

Подведем небольшой итог. Нужно было подобрать решение, которое в идеале способно закрыть сразу несколько поставленных задач:

  • Объединить сети между Linux-маршрутизаторами
  • Построить туннель между Linux и бытовым Keenetic
  • Дать доступ к домашним ресурсам и интернету носимым устройствам (телефоны, ноутбуки) из недоверенных сетей
  • Создать надежно зашифрованный туннель до удаленной VPS

Обзор существующих решений

Коротко пройдемся по тому что есть сейчас:

Дедушка Ленин всех протоколов. Умер, «разложился на плесень и на липовый мёд».

Кто-то, кроме одного провайдера, это использует?

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

  • Поддержка множества платформ — Windows, Linux, OpenWRT и её производные, Android
  • Стойкое шифрование и поддержка сертификатов.
  • Гибкость настройки.
  • Работа целиком и полностью в user-space.
  • Ограниченная поддержка со стороны домашних машрутизаторов — кривенько-косенько на Mikrotik (не умаляя остальных достоинств железок) и нормально в OpenWRT.
  • Сложности с настройкой мобильных клиентов: нужно скачивать, либо создавать свой инсталлятор, копировать куда-то конфиги.
  • В случае наличия нескольких туннелей ждут танцы с правкой systemd-юнитов на сервере.
  • Относительно широкая поддержка различных платформ — Windows, Android, Mac на базе родного приложения Cisco Anyconnect из магазина — идеальный вариант предоставить доступ ко внутренней сети носимым устройствам.
  • Стойкое шифрование, поддержка сертификатов, возможность подключения 2FA
  • Сам протокол полностью TLS-based (в отличие от OpenVPN, который легко детектится на 443 порту). Кроме TLS поддерживается и DTLS — во время установленного сеанса клиент может переключится на передачу данных через UDP и обратно.
  • Прекрасное сосуществование на одном порту как VPN, так и полноценного web-сервера при помощи sniproxy.
  • Простота настройки как сервера, так и клиентов.
  • Работа целиком и полностью в user-space.
  • TCP поверх TCP плохая идея.
  • Поддержки со стороны customer-grade оборудования нет.
  • Сложность установки туннелей между двумя Linux: теоретически можно, практически — лучше потратить время на что-то более полезное.
  • В случае наличия нескольких туннелей ждут танцы с несколькими конфигами и правкой systemd-юнитов.

IKEv2 IPSEC

  • Необходимо потратить немного времени на изучение и понять как это работает
  • Особенность, которая может сбить с толку новичка: IPSec, в отличие от привычных VPN решений, не создает сетевые интерфейсы. Задаются только политики обработки трафика, всё остальное разруливается средствами firewall.

Приступаем к настройке

Определившись с решением приступаем к настройке. Схема сети в моем случае имеет следующий вид (убрал под спойлер)


Первый шаг. От простого к сложному: туннели с использованием pre-shared keys (PSK)

На обоих Linux-box устанавливаем необходимые пакеты:


На второй стороне аналогично:


В данном случае в качестве ID выступает вымышленный адрес элестронной почты. Больше информации можно подчерпнуть на официальной вики.

Секреты сохранены, движемся дальше.


Аналогично редактируем на удаленном пире /etc/strongswan/ipsec.conf:


Если сравнить конфиги, то можно увидеть что они почти зеркальные, перекрёстно поменяны местами только определения пиров.

Директива auto = route заставляет charon установить ловушку для трафика, подпадающего в заданные директивами left/rightsubnet (traffic selectors). Согласование параметров туннеля и обмен ключами начнутся немедленно после появления трафика, попадающего под заданные условия.

Рестартуем strongswan на обоих серверах и пробуем выполнить ping центрального узла:

Нелишним будет так же убедиться что в файле /etc/strongswan/strongswan.d/charon.conf на всех пирах параметр make_before_break установлен в значение yes. В данном случае демон charon, обслуживающий протокол IKEv2, при выполнении процедуры смены ключей не будет удалять текущую security association, а сперва создаст новую.

Шаг второй. Появление Keenetic

Приятной неожиданностью оказался встроенный IPSec VPN в официальной прошивке Keenetic. Для его активации достаточно перейти в Настройки компонентов KeeneticOS и добавить пакет IPSec VPN.

Готовим настройки на центральном узле, для этого:

Правим /etc/strongswan/ipsec.secrects и добавляем PSK для нового пира:


Правим /etc/strongswan/ipsec.conf и добавляем в конец еще одно соединение:


Со стороны Keenetic настройка выполняется в WebUI по пути: Интернет → Подключения →
Другие подключения. Всё довольно просто.





Если планируется через тоннель гонять существенные объемы трафика, то можно попробовать включить аппаратное ускорение, которое поддерживается многими моделями. Включается командой crypto engine hardware в CLI. Для отключения и обработки процессов шифрования и хеширования при помощи инструкций CPU общего назначения — crypto engine software

После сохранения настроек рестрартуем strongswan и даём подумать полминуты Keenetic-у. После чего в терминале видим успешную установку соединения:

Шаг третий. Защищаем мобильные устройства

После чтения стопки мануалов и кучи статей решено было остановиться на связке бесплатного сертификата от Let's Encrypt для проверки подлинности сервера и классической авторизации по логину-паролю для клиентов. Тем самым мы избавляемся от необходимости поддерживать собственную PKI-инфраструктуру, следить за сроком истечения сертификатов и проводить лишние телодвижения с мобильными устройствами, устанавливая самоподписанные сертификаты в список доверенных.

Устанавливаем недостающие пакеты:


Получаем standalone сертификат (не забываем предварительно открыть 80/tcp в настройках iptables):


После того как certbot завершил свою работу мы должны научить Strongswan видеть наш сертификат:


Перезапускаем Strongswan и при вызове sudo strongswan listcerts мы должны видеть информацию о сертификате:


После чего описываем новое соединение в ipsec.conf:


Не забываем отредактировать файл /etc/sysconfig/certbot указав, что обновлять сертификат тоже будем как standalone, внеся в него CERTBOT_ARGS="--standalone".

Так же не забываем включить таймер certbot-renew.timer и установить хук для перезапуска Strongswan в случае выдачи нового сертификата. Для этого либо размещаем простенький bash-скрипт в /etc/letsencrypt/renewal-hooks/deploy/, либо еще раз редактируем файл /etc/sysconfig/certbot.

Перезапускаем Strongswan, включаем в iptables маскарадинг для сети 10.1.1.0/24 и переходим к настройке мобильных устройств.

Android

Устанавливем из Google Play приложение Strongswan.

Запускаем и создаем новый



Сохраняем профиль, подключаемся и, спустя секунду, можем не переживать о том, что кто-то сможет подсматривать за нами.

Windows

Windows актуальных версий приятно удивил. Вся настройка нового VPN происходит путем вызова двух командлетов PowerShell:


И еще одного, в случае если Strongswan настроен на выдачу клиентам IPv6 адреса (да, он это тоже умеет):

Часть четвертая, финальная. Прорубаем окно в Европу

Считаем что VPS подготовлена, Strongswan и Certbot уже установлены.


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

Готовим VPS

Правим ipsec.secrets, внося в него единственную строку:


Конфиги почти зеркальные. Внимательный читатель мог сам уже обратить внимание на пару моментов:


И на стороне хоста ipsecgw

Туннель установлен, пинги ходят, в tcpdump видно что между хостами ходит только ESP. Казалось бы можно радоваться. Но нельзя расслабляться не проверив всё до конца. Пробуем перевыпустить сертификат на VPS и…

Шеф, всё сломалось

Начинаем разбираться и натыкаемся на одну неприятную особенность прекрасного во всём остальном Let's Encrypt — при любом перевыпуске сертификата меняется так же ассоциированный с ним закрытый ключ. Изменился закрытый ключ — изменился и открытый. На первый взгляд ситуация для нас безвыходная: если даже открытый ключ мы можем легко извлечь во время перевыпуска сертификата при помощи хука в certbot и передать его удаленной стороне через SSH, то непонятно как заставить удаленный Strongswan перечитать его. Но помощь пришла откуда не ждали — systemd умеет следить за изменениями файловой системы и запускать ассоциированные с событием службы. Этим мы и воспользуемся.

Создадим на каждом из хостов служебного пользователя keywatcher с максимально урезанными правами, сгенерируем каждому из них SSH-ключи и обменяемся ими между хостами.

sudo vi /opt/ipsec-pubkey/pubkey-copy.sh

Скрипт pubkey-copy.sh нужен для извлечения открытой части ключа и копирования его удаленному хосту во время выпуска нового сертификата. Для этого в каталоге /etc/letsencrypt/renewal-hooks/deploy на обоих серверах создаем еще один микроскрипт:


Половина проблемы решена, сертификаты перевыпускаются, публичные ключи извлекаются и копируются между серверами и пришло время systemd с его path-юнитами.


Аналогично на VPS хосте:


И, напоследок, на каждом сервере создаем ассоциированную с данным юнитом службу, которая будет запускаться при выполнении условия (PathChanged) — изменении файла и его закрытии его после записи. Создаем файлы /etc/systemd/system/keyupdater.service и прописываем:


Не забываем перечитать конфигурации systemd при помощи sudo systemctl daemon-reload и назначить path-юнитам автозапуск через sudo systemctl enable keyupdater.path && sudo systemctl start keyupdater.path.

Как только удаленный хост запишет файл, содержащий публичный ключ, в домашний каталог пользователя keywatcher и файловый дескриптор будет закрыт, systemd автоматически запустит соответствующую службу, которая скопирует ключ в нужное расположение и перезапустит Strongswan. Туннель будет установлен, используя правильный открытый ключ второй стороны.

Можно выдохнуть и наслаждаться результатом.

Вместо заключения

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

Конечно за рамками статьи остались моменты настройки iptables, но и сама статья уже получилась и без того объемная и про iptables написано много.

Есть в статье и моменты, которые можно улучшить, будь-то отказ от перезапусков демона Strongswan, перечитывая его конфиги и сертификаты, но у меня не получилось этого добиться.

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

The charon-systemd daemon implements the IKE daemon very similar to charon, but is specifically designed for use with systemd. It uses the systemd libraries for a native integration and comes with a simple systemd service file.

Instead of using starter and an ipsec.conf based configuration, the daemon is directly managed by systemd and configured with the swanctl configuration backend. ipsec.conf based configurations are not supported with that daemon, as that would require the starter process.

Legacy systemd support using ipsec.conf and starter

Since 4.5.2, strongSwan comes with a systemd service unit called strongswan . This service invokes starter, which then loads ipsec.conf. This service is different from the charon-systemd based service we discuss here, which has a much simpler design and native systemd integration. charon-systemd implements the systemd service unit called strongswan-swanctl , because it relies on swanctl for its configuration.

Build options¶

To build the daemon, add
to the ./configure options.

To disable starter, ipsec and the stroke backend, additionally add
to build a lightweight and clean IKE daemon using modern tools.

The systemd unit file directory is detected automatically using pkg-config, but may be set manually using the --with-systemdsystemunitdir= option.

It is available since 5.2.1.

Behavior¶

charon-systemd gets installed as native systemd daemon, and should be started and stopped using systemctl. The systemd service unit is named strongswan (was strongswan-swanctl before 5.8.0, to distinguish it from the strongswan service that uses starter, which is now called strongswan-starter ).

After startup, systemd uses swanctl to load the swanctl-based configuration, including connections, pools and credentials.

The reload command reloads strongswan.conf and since 5.7.0 also the swanctl-based configuration.

Configuration¶

To configure configurations and connections, refer to the swanctl backend documentation. charon-systemd requires the use of a swanctl based configuration.

Logging¶

By default the charon-systemd backend logs to the systemd journal, use journalctl to inspect the log. Loglevels can be configured very similar to the other charon logger configuration, but using a journal section:

Of course one may define traditional syslog and filelog loggers in the strongswan.conf charon-systemd section, refer to LoggerConfiguration for details. To disable the journal logger, set default = -1 to make it silent.

The journal based logger provides some additional metadata in custom journal fields:

Field Description
LEVEL numerical strongSwan log level
GROUP logging subsystem string
THREAD numerical thread identifier issuing the journal entry
IKE_SA_UNIQUE_ID IKE_SA unique identifier, if available
IKE_SA_NAME name of the IKE_SA configuration, if available

The MESSAGE field contains the log message, MESSAGE_ID uses a unique identifier specific to each log message type.

The log levels are also mapped to values stored in the PRIORITY field (0 to LOG_NOTICE, 1 to LOG_INFO, everything above to LOG_DEBUG, see syslog(3) ).

NetworkManager allows configuration and control of VPN daemons through a plugin interface. We provide such a plugin for NetworkManager to configure road warrior clients for the most common setups. The plugin supports connections using the IKEv2 protocol only.

NetworkManager uses D-Bus to communicate with a special build of the charon IKE daemon (charon-nm), which runs independent of the regular daemon (e.g. charon-systemd) to avoid conflicts.

The plugin uses a certificate for server authentication and supports EAP and public key authentication for client authentication (since 5.8.3 / NetworkManager-strongswan 1.5.0 also EAP-TLS). PSK authentication is supported starting with version 1.3.1 of the plugin, but strong secrets (min. of 20 characters) are enforced.

You can use any password based EAP method supported by strongSwan (MD5/GTC/MSCHAPv2) or public key authentication. Private keys are either stored in a file or accessed through your ready-to-use ssh-agent. You'll need a certificate matching that key. Starting with strongSwan 4.5.0 / NetworkManager-strongswan 1.2.0, private keys and certificates on a smart card can be used (see below for details).

If you configure the server certificate directly on the clients, there are no requirements to the certificate. If you deploy CA certificates (supported since 4.3.1), the server certificate will need a subjectAltName including the host name of the server (the same you enter in the client's configuration). Since 5.8.3 / NetworkManager-strongswan 1.5.0 it's possible to configure the server identity explicitly. Starting with 4.3.5, you can also use preinstalled root CA certificates of your distribution, using the --with-nm-ca-dir configure option. Since 5.5.1 this can also be modified with the charon-nm.ca_dir setting. Just don't specify any server/CA certificate in the GUI to use preinstalled root certificates. CA certificates on a smart card are automatically used.

Screenshots¶



Dependencies¶

The original strongSwan NM plugin and the NetworkManager VPN module were based on the NetworkManager 0.9 interface. Version 1.4.0 of the plugin updated parts of it to the NetworkManager 1.2 interface (mostly related to the GUI, the plugin in charon-nm is largely unchanged). It should work out-of-the-box with the latest packages of your favorite Linux distribution.

Installation¶

Your distribution may provide a package (e.g. network-manager-strongswan on Debian/Ubuntu).

Otherwise, you have to build strongSwan from source.

Building from source¶

To build from source you additionally need the NetworkManager headers for the strongSwan NM backend:

NM integration works only for IKEv2. Since on a desktop we have OpenSSL installed anyway, we are going to use libcrypto for all cryptographic operations. --enable-agent builds the ssh-agent private key plugin, EAP plugins are enabled using --enable-eap-gtc --enable-eap-md5 --enable-eap-mschapv2 . For smart card support, --enable-pkcs11 . You may omit options you don't need.

Configuration¶

  • Click on nm-applet -> Edit Connections. (or VPN Connections -> Configure VPN. in older releases)
  • Add -> IPsec/IKEv2 (strongswan) -> Create.
  • Configure your client
  • Click on nm-applet -> VPN Connections -> Your Connection
  • Enter password

As you can see, there is no subnet configuration for the tunnel. We let the server administration choose the subnet(s); the client always proposes 0.0.0.0/0 for the remote network and the server narrows that down to the configured subnet(s).

If you use Certificate/private key authentication, please store your certificate and private key in separate files.

Smart card requirements¶

The use of smart cards should be as simple as possible to the end user, which brings some restrictions. For instance, the daemon automatically selects the first certificate with a private key on any token in any slot.

You may define multiple modules, the daemon looks for the first certificate/private key in the specified module order.