Детальная архитектура strongSwan

strongSwan по сути является программой-демоном (фоновой программой), которая автоматически создает настройки безопасных соединений, управляя криптографическими ключами и параметрами безопасности. Она использует протокол Internet Key Exchange версии 2 (IKEv2) для установления ассоциаций безопасности (Security Associations, или SA) и согласования политики безопасности (Security Policies) между двумя одноранговыми узлами (peers). Что касается устаревших приложений, для них всё ещё осуществляется поддержка протокола IKEv1, однако пользоваться им крайне нежелательно из-за проблем со стабильностью и безопасностью (официально это теперь считается недопустимым).

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

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

Политики работают в обе стороны, то есть после дешифрования будет разрешен прием только такого трафика, который соответствует «входящей» политике (правилам и настройкам, которые контролируют входящий трафик). Политики определяются на основе селекторов трафика (Traffic Selectors, или TS) – правил, определяющих, какой именно трафик (IP-адреса, подсети или порты) должен проходить через туннель VPN, – согласованных через IKE при создании CHILD_SA. Небезопасный трафик, поступающий в «ядро» процесса установления сеанса IKE и не соответствующий ни одной входящей политике IPsec будет отклонён. Это является одним из аспектов безопасности.

Обработку текущего IPsec-трафика выполняет не strongSwan, а сетевой и IPsec-стек ядра операционной системы. strongSwan устанавливает согласованные IPsec-SA и SP-протоколы в ядро операционной системы, используя платформенно-зависимый интерфейс.

Вышеупомянутое отличие между политиками и SA часто вызывает недопонимание. Например, в соответствии с изображением выше, если у хоста moon имеется site-to-site-туннель к хосту sun (соединяющий подсети 10.1.0.0/16 и 10.2.0.0/24), а у хоста carol имеется roadwarrior-подключение к sun (от которого carol получила виртуальный IP-адрес 10.3.0.10), то carol не сможет автоматически обмениваться данными с alice, даже если на sun включёно перенаправление данных. Причина этого в отсутствии политики IPsec, которая разрешала бы прохождение трафика между carol (10.3.0.10) и alice (10.1.0.10). Возможным решением было бы создание дополнительной SA между moon и sun, которая соединяла бы виртуальную подсеть 10.3.0.0/24 с 10.1.0.0/16.

В целом, обработка трафика с помощью IPsec и маршрутизация не связаны напрямую. IPsec часто просто встраивается в сетевой стек, и соответствующий трафик обрабатывается прозрачно в соответствии с политиками (policy-based). Поэтому любые маршруты к удалённым TS технически будут работать, позволяя IPsec перенаправлять и обрабатывать пакеты данных. Однако выбор исходного адреса может стать проблемой, если данные отправляются с самого VPN-хоста. Если локальные TS не содержат «публичный» адрес трафика, то трафик не будет обработан, если исходный адрес выбран, например, на основе маршрута по умолчанию. Особенно важно учитывать это, если используются виртуальные IP-адреса. Чтобы адрес, полученный от локального селектора трафика (TS) был гарантированно выбран как исходный, демон strongSwan charon по умолчанию устанавливает определенные маршруты к удалённым TS для большинства CHILD_SA (исключение составляют, например, соединения в транспортном режиме или TS с конкретными портами/протоколами).

Альтернативный подход – это маршрутно-ориентированный IPsec (route-based IPsec), где используются интерфейсы и прозрачные маршруты, для того чтобы контролировать, какие именно пакеты будут обработаны IPsec-туннелями (при этом трафик всё равно должен соответствовать согласованным политикам).

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

У strongSwan есть несколько методов для этого:

В операционной системе Linux strongSwan по умолчанию устанавливает маршруты в таблицу маршрутизации 220, поэтому требуется поддержка политико-ориентированной маршрутизации в ядре.

Вы можете настроить демон charon таким образом, чтобы он устанавливал маршруты в любую таблицу по вашему выбору, или же полностью отключить их. Для этой цели можно использовать параметры charon.install_routes, charon.routing_table и charon.routing_table_prio в файле strongswan.conf. Когда между двумя подсетями устанавливается туннель, charon пытается найти локальные IP-адреса в туннелированных локальных подсетях. Чтобы такой IP-адрес можно было найти и идентифицировать, в его настройках должен быть параметр «глобальная область видимости» (scope global). Если действительный IP-адрес будет найден, charon установит маршрут, указывающий на удалённую подсеть, в котором в качестве адреса отправителя (исходного IP, или source IP) задан найденный адрес. Это приводит к созданию маршрутов следующего вида:

В этом примере локальный IP-адрес – 10.2.0.2, а адрес удалённой подсети – 10.1.0.0/24. Оба адреса идентифицированы, поэтому пакеты, направляемые в удалённую подсеть, будут оправляться с корректного адреса отправителя (исходного IP, или source IP). Таким образом, политики IPsec будут совпадать, и трафик с локального устройства, направленный в удалённую подсеть, будет защищён с помощью IPsec.

Следующая страница: Варианты конфигурации и сценарии настройки strongSwan.