Ipsec vs tls/srtp в обеспечении безопасности voip

Введение в IPsec

Протокол IPsec — один из наиболее важных протоколов безопасности, который широко используется в компаниях, а также среди домашних пользователей. В последнее время такие производители, как ASUS, AVM и даже D-Link интегрируют VPN в свои домашние маршрутизаторы на основе протокола IPsec. Этот протокол предоставляет услуги безопасности для уровня IP и для всех протоколов более высокого уровня, таких как TCP и UDP (транспортный уровень Интернета). Благодаря IPsec мы можем безопасно обмениваться данными между различными точками Интернета, такими как две или более компаний друг с другом или пользователь у своего дома, IPsec идеально подходит для нужд VPN обоих «миров».

Очень важной особенностью IPsec является то, что он работает на уровне 3 OSI (сетевой уровень), другие протоколы VPN, такие как OpenVPN или WireGuard работают на уровне 4 (транспортный уровень), поскольку последние два основывают свою безопасность на TLS и DTLS соответственно. IPsec в сетях IPv4 находится чуть выше заголовка IP, однако в сетях IPv6 он интегрирован (ESP) в самом заголовке в разделе «Расширения»

IPsec предоставляет все службы, необходимые для обеспечения безопасности связи, как мы объясняли ранее, эти службы аутентификация, конфиденциальность, целостность и неотказуемость . Благодаря этим сервисам безопасность связи гарантирована. Конечно, у нас также есть контроль доступа, качество обслуживания и журнал активности.

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

В зависимости от используемого заголовка IPsec (AH или ESP) мы можем только проверить подлинность пакета или зашифровать полезную нагрузку всего IP-пакета, а также проверить его подлинность.

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

Некоторые преимущества IPsec заключаются в том, что он поддерживается всеми стандартами IETF и предоставляет «стандарт» VPN, поэтому все устройства должны быть совместимы. IPSec получает очень важную поддержку со стороны всего коммуникационного оборудования, так как это «стандарт» для VPN, который используется гораздо шире, чем OpenVPN или WireGuard. Все версии операционных систем ПК, такие как Windows or Linux, MacOS для Apple компьютеры, а также Android и Ios поддерживают протокол IPsec

Кроме того, еще одной очень важной характеристикой является то, что, будучи стандартом, существует возможность взаимодействия между производителями, что является гарантией для пользователей. Еще одна замечательная особенность IPSec — это его природа как открытого стандарта, и он прекрасно дополняется технологией PKI (Public Key Infrastructure)

IPsec сочетает в себе технологии открытого ключа (RSA или Elliptical Curves), алгоритмы симметричного шифрования (в основном AES, хотя он также поддерживает другие, такие как Blowfish или 3DES) и алгоритмы хеширования (SHA256, SHA512 и т. Д.), А также цифровые сертификаты на основе X509v3.

IKE: что это такое и для чего

Этот протокол IKE (Internet Key Exchange) используется для генерации и управления ключами, необходимыми для установления AH (заголовок аутентификации) и Соединения ESP (Encapsulated Security Payload) . Два или более участников соединения IPsec должны каким-то образом согласовать типы шифрования и алгоритмы аутентификации, чтобы иметь возможность установить соединение безопасным способом. Эта конфигурация может быть выполнена вручную на обоих концах канала или через протокол ( Протокол IKE ), чтобы обеспечить автоматическое согласование участников (SA = Security Association).

Протокол IKE отвечает не только за управление ключами и их администрирование, но и за установление соединения между соответствующими участниками. IKE входит не только в IPsec, но и может использоваться в различных алгоритмах маршрутизации, таких как OSPF или RIP.

Фазы согласования IKE

Установление безопасного канала будет выполнено с использованием алгоритма обмена ключами, такого как Diffie-Hellman, для шифрования обмена данными IKE. Это согласование выполняется через единую двунаправленную SA. Аутентификация может осуществляться через PSK (общий ключ) или другими методами, такими как сертификаты RSA. Используя созданный защищенный канал, будет согласовано соответствие безопасности IPsec (или других служб).

Некоторые особенности IKE

IKE поддерживает NAT обход даже если один или оба участника находятся за NAT, соединение может быть выполнено без особых проблем, хотя нам придется открывать порты на сервере VPN, если он находится за NAT. Порядковые номера и ACK используются для обеспечения надежности, а также включают систему обработки ошибок. IKE устойчив к атакам типа «отказ в обслуживании», и IKE не предпринимает никаких действий до тех пор, пока не определит, действительно ли существует запрашивающая конечная точка, тем самым защищая от атак с поддельных IP-адресов.

В настоящее время IKEv2 широко применяется во всех профессиональных межсетевых экранах и маршрутизаторах, однако он еще не полностью распространен в мире Android или iOS, только Samsung Пользователи смартфонов поддерживают IPsec с IKEv2. Операционные системы Windows, Linux и macOS поддерживают этот протокол.

IKEv2: что изменилось

IKEv2 — вторая версия этого популярного протокола обмена ключами в Интернете, в него включены улучшения для обхода NAT, что упрощает взаимодействие и прохождение через брандмауэры в целом. Он также поддерживает новый стандарт мобильности, который позволяет очень быстро переподключить связь, кроме того, он также поддерживает множественную адресацию (multi-origin), что идеально подходит для пользователей смартфонов, планшетов или ноутбуков. IKEv2 позволяет использовать SCTP, который используется в VoIP, он также имеет более простой обмен сообщениями, он имеет меньше криптографических механизмов, позволяя использовать только самые безопасные. Какой смысл использовать VPN с небезопасными шифрами? IKEv2 позволяет использовать только самые безопасные

Конфигурация протокола IPsec

Чтобы настроить протокол IPsec вместе с протоколом L2TP, нам нужно будет выполнить всего три действия. Первый — включить «Мобильных клиентов», то есть VPN удаленного доступа. Второй — включить фазу 1 IPsec, а затем настроить фазу 2 IPsec.

Настроить «Мобильные клиенты»

Это одна из наиболее важных частей, потому что если мы перейдем в раздел «Туннели», мы создадим VPN-туннель типа «сеть-сеть», а то, что мы хотим сделать с IPsec, — это настроить VPN для удаленного доступа, чтобы разные клиенты.

В этом меню мы включаем «Включить поддержку мобильного клиента IPsec» и выбираем «Локальная база данных», хотя мы будем использовать ее, потому что это для аутентификации xAuth. Нажимаем на сохранить.

Как только мы нажмем «Сохранить», нам также нужно будет нажать «Применить изменения», а затем нажать зеленую кнопку, обозначающую «Создать фазу1».

Настроить IPsec Phase 1

В этом меню нам нужно будет правильно настроить протокол IPsec, чтобы использовать его с L2TP, не все конфигурации будут работать, кроме того, в зависимости от используемого VPN-клиента (Android, Ios, Windows …) Конфигурация безопасности может измениться, поскольку не все операционные системы поддерживают лучшие шифры VPN. По умолчанию мы увидим следующее меню, в котором мы выбрали IKEv2, который несовместим с протоколом L2TP / IPsec, который мы хотим настроить.

Для правильной работы мы должны настроить следующие параметры:

  • Главная Информация
    • Версия обмена ключами: IKEv1, если выберем любую другую, работать не будет.
    • Интернет-протокол: IPv4 или IPv6
    • Интерфейс: Интернет WAN
    • Описание: ставим описание.
  • Предложение этапа 1 (аутентификация)
    • Метод аутентификации: взаимный PSK
    • Режим переговоров: агрессивный; если мы выберем «Основной», это будет более безопасно, но менее гибко, и мы можем помешать правильному подключению VPN-клиента. Позже, если все работает с «Aggresive», мы можем проверить, работает ли и с «Main».
    • Мой идентификатор: Отличительное имя пользователя — redeszone@redeszone.net или как хотите.
  • Предложение этапа 1 (Шифрование

    Алгоритм шифрования: 128-битный AES, SHA1, DH Group 2 (1024-битный).

    )

pfSense поддерживает более надежное шифрование, чем это, которое мы настроили, но проблема в том, что VPN-клиенты, которые будут подключаться, не поддерживают более высокий уровень безопасности. Чтобы настроить его с максимальной безопасностью, мы можем пройти тестирование на основе «полученных предложений» IPsec, которые мы получаем от клиента, таким образом, мы выберем наиболее безопасный из всех.

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

По завершении мы нажимаем «Сохранить», и теперь мы попадаем в главное меню, где у нас есть все VPN-туннели с IPsec, нам нужно будет нажать на единственный созданный и на «Показать записи фазы 2», а затем на «Create Phase 2», чтобы продолжить.

Настроить IPsec Phase 2

В этом меню конфигурации мы должны поместить следующее:

  • Главная Информация
    • Режим: транспорт
    • Описание: описание, которое мы хотим.
  • Предложение этапа 2 (SA / Обмен ключами)
    • Протокол: ESP
    • Алгоритмы шифрования: 128-битный AES
    • Алгоритмы хеширования: выбираем SHA-1 и SHA-256
    • Группа ключей PFS: выключена, протоколом не поддерживается.

Остальные параметры конфигурации можно оставить по умолчанию.

В главном меню «IPsec / Tunnels» мы можем увидеть сводку всего, что мы настроили.

Теперь нам нужно перейти в раздел «IPsec / Pre-Shared Keys» и добавить новый идентификатор.

Этот новый идентификатор должен быть:

  • Идентификатор: allusers (должен быть таким, без заглавных букв и без другого имени)
  • Тип секрета: PSK
  • Pre-Shared Key: пароль, который мы хотим, предоставляется всем пользователям, которые собираются подключиться.

Как только это будет сделано, у нас будет сервер L2TP / IPsec, готовый принимать соединения, но сначала мы должны создать соответствующие правила в брандмауэре.

SIGMA

  • конфиденциальность передаваемых сообщений;
  • аутентичность и целостность передаваемых сообщений — их изменение должно быть обнаружено;
  • защиту от атак перепроигрывания (replay attack) — факт пропажи или повтора сообщений должен быть обнаружен;
  • двустороннюю идентификацию и аутентификацию собеседников;
    наличие perfect forward secrecy свойства (PFS) — компрометация нашего долгоживущего PSK или ключа подписи не должна приводить к возможности чтения предыдущих сообщений (а IKE сообщения могут содержать ключевой материал ESP SA). Запись перехваченного трафика становится бесполезной;
    действительность/валидность сообщений (транспортных и рукопожатия) только в пределах одной IKE сессии. Вставка корректно подписанных/аутентифицированных сообщений из другой сессии (даже с этим же собеседником) не должна быть возможной;
    пассивный наблюдатель не должен видеть ни идентификаторов сторон, ни передаваемых долгоживущих публичных ключей, ни хэшей от них. Некая анонимность от пассивного наблюдателя.

IKE_SA_INITSPIi+SPIrDHENCRPRFTLS 1.3

Туннельный и транспортный режимы

payloadтранспортномтуннельном

---------------------------------------
| orig IP hdr || TCP | Data |
---------------------------------------
---------------------------------------------------------
| orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
                             |<--- encryption ---->|
                         |<---- authenticity ----->|
----------------------------------------------------------
| new* |new ext|   | orig*|orig ext|   |    | ESP   | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
----------------------------------------------------------
                   |<--------- encryption --------->|
               |<---------- authenticity ---------->|

setkey2001:ac::/642001:dc::/642001::1232001::321

spdadd 2001:ac::/64 2001:dc::/64 any -P out ipsec esp/tunnel/2001::123-2001::321/require ;
spdadd 2001:dc::/64 2001:ac::/64 any -P in  ipsec esp/tunnel/2001::321-2001::123/require ;

L2TP / IPsec — что это?

L2TP (Layer 2 Tunneling Protocol) — это протокол, используемый для VPN, который был разработан рабочей группой IETF как наследник PPTP, и был создан для исправления недостатков этого протокола и установления его в качестве стандарта. L2TP использует PPP для предоставления коммутируемого доступа, который может быть туннелирован через Интернет до указанной точки. L2TP включает в себя механизмы аутентификации PPP, PAP и CHAP, кроме того, как и PPTP, он поддерживает использование этих протоколов аутентификации, таких как RADIUS.

Хотя L2TP предлагает доступ с поддержкой нескольких протоколов и доступ к удаленным локальным сетям, он не имеет особо надежных криптографических характеристик. Операция аутентификации выполняется только между конечными точками туннеля, но не для каждого из пакетов, проходящих через него. Это может привести к подделке где-то внутри туннеля. Без проверки целостности каждого пакета можно было бы выполнить атаку типа «отказ в обслуживании» с использованием ложных управляющих сообщений, которые завершают основной туннель L2TP или соединение PPP.

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

Это может дать тому, кто прослушивает сеть и обнаруживает единственный ключ, получить доступ ко всем передаваемым данным.

Принимая во внимание все эти недостатки L2TP, IETF приняла решение использовать протоколы самого протокола IPsec для защиты данных, проходящих через туннель L2TP. По этой причине они всегда пишутся «L2TP / IPsec», потому что оба протокола используются одновременно, и этот совместный протокол широко используется

Можно сказать, что L2TP является протоколом на уровне «канального» уровня и что он не имеет защиты, однако IPSec обеспечивает безопасность на сетевом уровне, так что использование этого протокола является безопасным.

По этой причине мы всегда будем находить номенклатуру L2TP / IPSec вместе, потому что оба протокола используются для безопасного соединения VPN.

User/password authentication for XAUTH on the server

Libreswan has three options for the user/password authentication. This is specified using the xauthby= option. If using X.509 certificates, which are issued to individual devices/users and which can be revoked, there is no real need to have an additional username/password layer. In that case, xauthby=alwaysok can be used. This should not be used when using a PSK.

If there are only a handful of users that need to be authenticated, xauthby=file can be used. The format of this file is similar to the Apache htpasswd file, but the htpasswd command can not be used to create the file. The differences to htpasswd format is pluto uses standard crypt hashing which is same as /etc/shadow format so sha2_512 can be used. Additional third column specifying the connection name. An example of an /etc/ipsec.d/passwd file for the above example connection (using xauthby=file) would be:

john:$1$5h/bAg4p$Q5/c2XjwSzYy3sh/1j8Bp/:xauth-psk
paul:$1$YiVSo114$um2oIM6AqucFuMeXl/1ab0:xauth-psk

The last method that can be used is xauthby=pam. Using this configuration, libreswan uses the /etc/pam.d/pluto pam configuration file to authenticate users. An /etc/pam.d/pluto example file:

#%PAM-1.0
# Regular System auth
auth include system-auth
#
# Google Authenticator with Regular System auth in combined prompt mode
# (OTP is added to the password at the password prompt without separator)
# auth required pam_google_authenticator.so forward_pass
# auth include system-auth use_first_pass
#
# Common
account required pam_nologin.so
account include system-auth
password include system-auth
session optional pam_keyinit.so force revoke
session include system-auth
session required pam_loginuid.so

Конфигурация

Изначально нам нужно убедиться, что обе наши стороны имеют «белый» маршрутизируемый ip адрес. Теоретически, все это можно прокинуть через NAT, если устройство находится внутри сети, но это осложняет конфигурацию, а еще далеко не все провайдеры позволяют one-to-one NAT в наше время.

Начнем со стороны Mikrotik. Предполагаю, что на нем стоит свежая прошивка (в моем случае это 6.48.4), и он уже настроен как роутер «белым» адресом наружу.

Локальная сеть Mikrotik в нашем случае:

Сети со стороны Cisco это множество локальных подсетей:

Маршрутизируемый адрес в примере для Mikrotik будет:

Маршрутизируемый адрес для Cisco:

Что должна гарантировать безопасность VPN?

Чтобы обеспечить безопасность соединения через виртуальную частную сеть (VPN), необходимо гарантировать определенные функции, иначе мы можем столкнуться с ненадежной VPN. Мы уже предполагаем, что протокол IPsec будет соответствовать всем из них, поскольку это безопасный протокол VPN, который широко используется в компаниях.

Аутентификация

Аутентификация — один из самых важных процессов в VPN, эта функция позволяет показать пользователю, что он действительно такой, каким он себя называет. Чтобы доказать это, введите пароль, используйте цифровой сертификат или комбинацию обеих форм аутентификации. Когда хост получает дейтаграмму IPsec от источника, он уверен, что исходный IP-адрес дейтаграммы является фактическим источником дейтаграммы, потому что он ранее был успешно аутентифицирован.

Конфиденциальность

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

Целостность

Аутентификация и конфиденциальность так же важны, как и целостность. Целостность означает, что можно гарантировать, что информация не была изменена между источником сообщения и получателем. Все коммуникации в VPN включают коды обнаружения ошибок и информацию о том, что информация не изменяется. В случае изменения пакет автоматически отбрасывается, и это может даже вызвать сбой VPN-туннеля по соображениям безопасности. Протокол IPsec позволяет принимающему узлу проверять, что поля заголовка дейтаграммы и зашифрованная полезная нагрузка не были изменены, пока дейтаграмма была на пути к месту назначения.

Представим, что у нас есть аутентификация и конфиденциальность в VPN, но нет целостности. Если пользователь в середине сеанса связи изменяет некоторые значения, вместо отправки денежного перевода на сумму 10 евро он может преобразовать его в 1,000 евро. Благодаря функции целостности, как только бит изменен, пакет отбрасывается и будет ждать его повторной отправки.

Я не отрицаю

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

Контроль доступа (авторизация)

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

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

Регистр активности

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

Качество обслуживания

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

Open ports in the pfSense firewall

In this VPN it is also necessary to open ports on the Internet WAN, specifically we will have to open port 500 UDP and port 4500 UDP. Next, you have all the details to open both ports.

We will have to create a rule in the “Firewall / Rules / WAN” section with the following information:

  • Action: Pass
  • Interface: WAN
  • Address Family: IPv4
  • Protocol: UDP
  • Source: any
  • Destination: WAN Address on port 500

The second rule would be:

  • Action: Pass
  • Interface: WAN
  • Address Family: IPv4
  • Protocol: UDP
  • Source: any
  • Destination: WAN Address on port 4500

As you can see, we have the two rules to accept to allow traffic.

We save and apply changes, ensuring that this rule will be followed. Now we go to the “IPsec” section where we will do a “allow all”. Then when we connect, if we want to limit access, we can do so by putting the corresponding rules here.

  • Action: Pass
  • Interface: IPsec
  • Address Family: IPv4
  • Protocol: any
  • Source: any
  • Destination: any

Next, you can see the newly created rule, which is the only one we have.

Now that we have the IPsec VPN server configured, we have created the user with the corresponding permissions, and we also have it open in the firewall, we are going to perform a connection test with Android.

Aggressive Mode

The difference between using the regular Main Mode or Aggressive Mode for the client is usually determined by whether or not the «Group Name» is set. On Android, this option is called «IPSec identifier». On iOS/OSX and NetworkManager this fiels is called «Group Name». When these fields are blank, Main Mode (preferred) is used. When these are not blank, Aggressive Mode is used. On the serverside, the Group Name is the value of the rightid=@String (the remote end, not the server end). Unfortunately, iOS/OSX sends these as hex, which can be matched using rightid=@ but then it no longer works for Android. With NetworkManager you can specify «String» or «». These values are best left unset when using libreswan as a server, so that Main Mode is used. When connecting to a Cisco with libreswan as a client, you will need to use rightid=@String and aggrmode=yes.

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

PPTPL2TPWireguardOpenVPN

  • Поддержка множества платформ — Windows, Linux, OpenWRT и её производные, Android
  • Стойкое шифрование и поддержка сертификатов.
  • Гибкость настройки.
  • Работа целиком и полностью в user-space.
  • Ограниченная поддержка со стороны домашних машрутизаторов — кривенько-косенько на Mikrotik (не умаляя остальных достоинств железок) и нормально в OpenWRT.
  • Сложности с настройкой мобильных клиентов: нужно скачивать, либо создавать свой инсталлятор, копировать куда-то конфиги.
  • В случае наличия нескольких туннелей ждут танцы с правкой systemd-юнитов на сервере.

OpenConnect (open-source реализация протокола Cisco Anyconnect)

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

IKEv2 IPSEC

  • С появлением IKEv2 сам протокол стал проще в настройке, в сравнении с предыдущей версией, правда ценой потери обратной совместимости.
  • Благодаря стандартизации обеспечивается работа где угодно и на чём угодно — список можно вести до бесконечности. Linux, Mikrotik (в последних версиях RouterOS), OpenWRT, Android, iPhone. В Windows также есть нативная поддержка начиная с Windows 7.
  • Высокая скорость: обработка трафика полностью в kernel-space. User-space часть нужна только для установки параметров соединения и контроля работоспособности канала.
  • Возможность использовать несколько методов аутентификации: используя как PSK, так и сертификаты, причем в любых сочетаниях.
  • Несколько режимов работы: туннельный и транспортный. Чем они отличаются можно почитать в том числе и на Хабре.
  • Нетребовательность к настройкам промежуточных узлов: если в первой версии IKE были проблемы, вызванные NAT, то в IKEv2 есть встроенные механизмы для преодоления NAT и нативная фрагментация IKE-сообщений, позволяющая установить соединение на каналах с кривым MTU. Забегая вперед скажу, что на практике я еще ни разу не сталкивался с WiFi сетью, где бы клиенту не удалось установить соединение.
  • Необходимо потратить немного времени на изучение и понять как это работает
  • Особенность, которая может сбить с толку новичка: IPSec, в отличие от привычных VPN решений, не создает сетевые интерфейсы. Задаются только политики обработки трафика, всё остальное разруливается средствами firewall.

Установление связи

Согласование туннеля IPsec осуществляется через протокол IKE, который обеспечивает зашифрованное и аутентифицированное соединение между двумя сторонами связи. В процедуре подключения будут согласованы ключи и безопасность, используемые для установления соединения IPsec. Процедура подключения состоит из двух отдельных частей. Мы объясним эти две части ниже.

1. Обеспечьте аутентификацию и безопасность соединения.

Для защиты соединения будет использоваться алгоритм симметричного шифрования и подпись HMAC. Обмен ключами осуществляется с использованием алгоритма обмена ключами, такого как Diffie-Hellman. Этот метод не гарантирует, что участники являются теми, кем они являются, поэтому мы будем использовать предварительный общий ключ или цифровые сертификаты.

Первая часть связи заканчивается, когда параметры безопасности согласованы, и канал связи защищен.

2. Обеспечить конфиденциальность данных.

Установленный нами защищенный канал IKE используется для согласования определенных параметров безопасности IPsec (заголовок AH или ESP, алгоритмы аутентификации и т. Д.). Эти конкретные параметры могут включать новые ключи Диффи-Хеллмана для обеспечения большей безопасности, если мы настроили PFS (Perfect Direct Confidentiality), что настоятельно рекомендуется для повышения надежности VPN.

CP

CPCFG_REQUESTCFG_REPLYCFG_SETCFG_ACKIKE_AUTH

    SK{IDi, , AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -->
<-- SK{IDr,        AUTH, CP(CFG_REPLY),   SAr2, TSi, TSr}

CP(CFG_REQUEST) =
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
TSi = (proto=0, port=0-65535, :: - ffff:...:ffff)
TSr = (proto=0, port=0-65535, :: - ffff:...:ffff)

CP(CFG_REPLY) =
  INTERNAL_IP6_ADDRESS(2001:db8::5/64)
  INTERNAL_IP6_DNS(2001:db8::1)
  INTERNAL_IP6_SUBNET(2001:db8:abcd::/64)
TSi = (proto=0, port=0-65535, 2001:db8::5 - 2001:db8::5)
TSr = (proto=0, port=0-65535, 2001:db8::0 - 2001:db8::ffff:ffff:ffff:ffff)
  • Инициатору выделяется 2001:db8::5 адрес.
  • По установленному ESP SA туннелю он может ходить в 2001:db8::/64 сеть.
  • При этом в ней есть 2001:db8::1 DNS сервер.
  • А также известно что на стороне ответчика есть и 2001:db8:abcd::/64 сеть, и если в неё хочется попасть, то надо создать отдельный ESP SA, или возможно настроить маршрутизацию через хост в 2001:db8:: сети.

IKE ключевой материал

IKE_SA_INITSKEYSEED

SKEYSEED = PRF(Ni || Nr, DH-KEY)

DH-KEYextractDH-KEYSKEYSEEDexpand

PRF+(SKEYSEED, Ni || Nr || SPIi || SPIr) ->
    SK_d || SK_ai || SK_ar || SK_ei || SK_er || SK_pi || SK_pr

PRF+(K,S) = T1 || T2 || T3 || T4 || ...
T1 = PRF(K,       S || 0x01)
T2 = PRF(K, T1 || S || 0x02)
T3 = PRF(K, T2 || S || 0x03)
T4 = PRF(K, T3 || S || 0x04)

extractexpand

  • SK_d ключ для выработки ключей дочерних ESP SA.
  • SK_a ключи для аутентификации IKE сообщений. Не вырабатывается/не используется если согласован AEAD алгоритм (AES-GCM, Кузнечик/Магма-MGM, ChaCha20-Poly1305, и т.д.).
  • SK_e ключи шифрования IKE сообщений.
  • SK_p ключи используемые при вычислении аутентификаторов AUTH.

TLS 1.3

Precautions

  • The following RFC is supported. As for supported “attribute”, refer to .
  • The XAUTH authentication implementation is based on the following Internet-Draft (now deprecated). However, there are different parts for each implementation vendor, and we make no guarantee for connections to all of the devices implemented based on the following drafts.
  • The ISAKMP Configuration Method (mode-cfg) implementation is based on the following Internet-Draft (now deprecated).However, there are different parts for each implementation vendor, and we make no guarantee for connections to all of the devices implemented based on the following drafts.