IPsec VPN представляет собой не один протокол, а систему правил, ключей и защищённых соединений. IKEv2 аутентифицирует стороны и согласует параметры, ESP шифрует пользовательский трафик, а политики ядра определяют, какие пакеты должны попасть в туннель. Поэтому статус «подключено» ещё не доказывает, что нужные сети действительно обмениваются данными.
Мой главный тезис прост. IPsec ломается не столько из-за криптографии, сколько из-за несовпадающих сетей, идентификаторов, маршрутов, правил NAT и Traffic Selectors. Надёжная настройка требует рассматривать шифрование, маршрутизацию и межсетевой экран как одну систему.
Материал предназначен для легального администрирования собственных устройств и сетей. Соблюдайте законы своей страны, включая законодательство России, требования владельцев информационных систем и правила сервисов. Не применяйте инструкции для несанкционированного доступа, слежки, взлома или незаконного обхода ограничений.
Как IPsec разделяет управление и передачу данных
Архитектуру IPsec формализуют RFC 4301 и руководство NIST SP 800-77. IPsec работает на сетевом уровне и проверяет каждый подходящий IP-пакет по Security Policy Database. Политика может потребовать защитить пакет, пропустить без IPsec или отбросить.
| Компонент | Назначение |
|---|---|
| IKEv2 | Аутентифицирует стороны, согласует алгоритмы и создаёт ключи |
| IKE_SA | Защищает управляющий обмен между узлами |
| CHILD_SA | Описывает защиту пользовательского трафика через ESP |
| ESP | Шифрует пакеты, контролирует целостность и поддерживает anti-replay |
| SPD | Хранит правила обработки трафика |
| SAD | Хранит активные SA, ключи, SPI, счётчики и алгоритмы |
| Traffic Selectors | Задают локальные и удалённые адреса, протоколы и порты |
Во время IKE_SA_INIT стороны согласуют криптографические параметры и выполняют обмен Диффи-Хеллмана. На этапе IKE_AUTH шлюзы подтверждают личности с помощью сертификатов, PSK или EAP, после чего создают первый CHILD_SA. Последующие CHILD_SA и новые ключи создаются через CREATE_CHILD_SA. Такой порядок описывают RFC 7296 и документация strongSwan.
ESP добавляет к пакету SPI и номер последовательности, шифрует полезную нагрузку и проверяет её подлинность. Реализация ESP обязана поддерживать защиту от повторной передачи, однако принимающая сторона может отключить anti-replay для конкретной SA. Поэтому нельзя считать такую защиту безусловно активной на любом оборудовании. Детали приводят RFC 4303 и руководство NIST.
Для новых конфигураций я предпочитаю AES-GCM. Алгоритм относится к AEAD и одновременно шифрует данные и проверяет их подлинность, поэтому отдельный алгоритм целостности для ESP не задаётся. Современные требования к наборам алгоритмов содержат RFC 8221 и рекомендации strongSwan.
AH не шифрует данные и защищает части IP-заголовка от изменения. NAT меняет адреса и тем самым нарушает проверку AH, поэтому в обычных корпоративных VPN я использую ESP. Ограничения AH при работе через NAT описывают RFC 3948 и NIST SP 800-77.
В tunnel mode исходный IP-пакет целиком помещается внутрь нового пакета. Режим подходит для связи двух сетей и удалённого доступа. Transport mode сохраняет исходный IP-заголовок и защищает данные верхнего уровня. Такой режим чаще применяют между отдельными хостами или вместе с другими сетевыми механизмами. Различия закреплены в RFC 4301 и документации strongSwan.
Как пакет попадает в туннель и где возникает сбой
Пусть компьютер 10.10.1.25 обращается к серверу 10.20.4.50. Шлюз находит политику для сетей 10.10.0.0/16 и 10.20.0.0/16, выбирает подходящую CHILD_SA, шифрует исходный пакет и отправляет его удалённому шлюзу. Получатель находит SA по SPI, проверяет номер последовательности и целостность, расшифровывает пакет и передаёт его серверу. Такой путь следует модели из RFC 4301 и RFC 4303.
IKE начинает обмен через UDP 500. При обнаружении NAT стороны используют NAT Traversal и передают ESP внутри UDP 4500. Если UDP-инкапсуляция не применяется, межсетевой экран должен пропускать IP protocol 50. Механизм определяют RFC 3948 и документация strongSwan.
MOBIKE позволяет клиенту сменить внешний адрес без полной пересборки IKE_SA и CHILD_SA. Функция полезна при переходе телефона с Wi-Fi на мобильную сеть. Для стационарного site-to-site туннеля MOBIKE обычно не нужен, поэтому в примере ниже я отключаю его. Поведение описывают RFC 4555 и документация strongSwan.
Сертификаты и длинные списки алгоритмов могут сделать сообщения IKE крупнее доступного MTU. Если маршрутизатор отбрасывает IP-фрагменты, соединение часто застревает во время аутентификации. IKE fragmentation делит данные внутри протокола и снижает зависимость от обычной IP-фрагментации. Расширение описывают RFC 7383 и раздел strongSwan FAQ.
Policy-based VPN выбирает трафик преимущественно по политикам и Traffic Selectors. Route-based VPN добавляет VTI или XFRM-интерфейс и позволяет направлять пакеты обычными маршрутами. Route-based схема удобнее для BGP, нескольких туннелей и большого числа префиксов, но не отменяет XFRM state и policy, которые выполняют криптографическую обработку. Такой подход описывают strongSwan и руководство Cisco.
Настройка site-to-site VPN на strongSwan
В примере центральный офис использует внешний адрес 198.51.100.10 и внутреннюю сеть 10.10.0.0/16. Филиал использует адрес 203.0.113.20 и сеть 10.20.0.0/16. Внешние адреса взяты из диапазонов для документации и не подходят для реального подключения.
Конфигурация использует современный формат swanctl.conf, IKEv2 и PSK. Для крупной инфраструктуры я предпочёл бы сертификаты X.509 или отдельный случайный PSK для каждой пары шлюзов. Один общий пароль на десятках устройств сильно усложняет отзыв доступа. Синтаксис и модель конфигурации подтверждают документация swanctl.conf и пример NIST.
Центральный шлюз, файл /etc/swanctl/swanctl.conf
connections {
office-branch {
version = 2
local_addrs = 198.51.100.10
remote_addrs = 203.0.113.20
mobike = no
proposals = aes256gcm16-prfsha256-ecp256
local {
auth = psk
id = office.example.net
}
remote {
auth = psk
id = branch.example.net
}
children {
lan-lan {
local_ts = 10.10.0.0/16
remote_ts = 10.20.0.0/16
esp_proposals = aes256gcm16-ecp256
start_action = start
dpd_action = restart
}
}
dpd_delay = 30s
}
}
secrets {
ike-office-branch {
id-1 = office.example.net
id-2 = branch.example.net
secret = 0xREPLACE_WITH_64_HEX_CHARACTERS
}
}Шлюз филиала получает зеркальную конфигурацию.
connections {
branch-office {
version = 2
local_addrs = 203.0.113.20
remote_addrs = 198.51.100.10
mobike = no
proposals = aes256gcm16-prfsha256-ecp256
local {
auth = psk
id = branch.example.net
}
remote {
auth = psk
id = office.example.net
}
children {
lan-lan {
local_ts = 10.20.0.0/16
remote_ts = 10.10.0.0/16
esp_proposals = aes256gcm16-ecp256
start_action = start
dpd_action = restart
}
}
dpd_delay = 30s
}
}
secrets {
ike-office-branch {
id-1 = office.example.net
id-2 = branch.example.net
secret = 0xREPLACE_WITH_64_HEX_CHARACTERS
}
}Обе стороны должны получить одинаковый случайный ключ. Команда ниже создаёт 32 случайных байта в шестнадцатеричном формате. К результату нужно добавить префикс 0x. Рекомендации по случайным PSK приводят NIST и документация strongSwan.
openssl rand -hex 32Шлюзы должны пересылать IPv4-пакеты между интерфейсами.
sudo sysctl -w net.ipv4.ip_forward=1Постоянное значение можно сохранить в /etc/sysctl.d/90-ipsec.conf.
net.ipv4.ip_forward = 1После сохранения конфигурации я загружаю параметры, запускаю CHILD_SA и проверяю состояние IKE, ESP и политик ядра.
sudo swanctl --load-all
sudo swanctl --list-conns
sudo swanctl --initiate --child lan-lan
sudo swanctl --list-sas
sudo ip -s xfrm state
sudo ip -s xfrm policy
sudo cat /proc/net/xfrm_statНазвания команд и вывод SA описывает документация swanctl, а значения ошибок XFRM объясняет документация ядра Linux.
На публичных интерфейсах нужно разрешить UDP 500 и UDP 4500. IP protocol 50 потребуется, если ESP передаётся без UDP-инкапсуляции. Правила FORWARD должны пропускать трафик между 10.10.0.0/16 и 10.20.0.0/16 в обоих направлениях. Требования подтверждают RFC 3948 и руководство Red Hat.
Общее правило MASQUERADE может изменить исходный адрес до совпадения с IPsec-политикой. Для трафика между защищаемыми сетями обычно создают исключение из SNAT и ставят его выше общего правила маскарадинга. Порядок обработки разбирают документация strongSwan и руководство NIST.
Группа ecp256 внутри esp_proposals не создаёт отдельный обмен Диффи-Хеллмана для первого CHILD_SA, который появляется внутри IKE_AUTH. Отдельная группа применяется при последующем rekey или создании дополнительного CHILD_SA. Поэтому я обязательно проверяю повторное согласование.
sudo swanctl --rekey --child lan-lanБез такой проверки несовместимость PFS может проявиться только спустя несколько часов, когда шлюз попробует обновить ключи. Поведение объясняют документация strongSwan и спецификация IKEv2.
Ошибки, ограничения и возможности, о которых часто забывают
Самая частая ошибка связана с Traffic Selectors. Один шлюз предлагает 10.10.0.0/16, другой разрешает только 10.10.1.0/24. IKE_SA может установиться, но CHILD_SA будет отсутствовать либо защитит только часть адресов. Диагностировать проблему нужно по согласованным selectors и XFRM policy, а не по общему статусу VPN. Такой принцип следует из RFC 7296 и архитектуры IPsec.
Вторая типичная ошибка возникает на обратном маршруте. Сервер получает запрос через VPN, но отправляет ответ обычному маршрутизатору. Каждая внутренняя сеть должна знать путь к удалённому префиксу через соответствующий IPsec-шлюз. NAT может временно скрыть ошибку, но лишает журналы исходных адресов и усложняет контроль доступа. Маршрутизацию и пересылку рассматривают strongSwan и Cisco.
Третья проблема связана с MTU. ESP, внешний IP-заголовок и NAT-T увеличивают размер пакета. Небольшой ping работает, а крупные HTTPS-запросы или передача файлов зависают. Проверить максимальный размер можно без разрешения фрагментации.
ping -M do -s 1400 10.20.4.50
tracepath 10.20.4.50Причины потерь крупных пакетов и варианты настройки MTU описывают документация strongSwan и RFC 7383.
Пересекающиеся адресные пространства создают отдельную проблему. Если оба офиса используют одну сеть 192.168.1.0/24, обычная маршрутизация не сможет однозначно выбрать локальный или удалённый узел. Надёжнее перенумеровать одну сеть. Трансляция адресов внутри VPN возможна, но усложняет политики, журналирование и диагностику.
IKE ID не обязан совпадать с внешним IP-адресом. Я использовал FQDN-идентификаторы, чтобы не связывать личность шлюза с адресом провайдера. При сертификатной аутентификации идентификатор должен соответствовать Subject Alternative Name сертификата. Правила проверки личности содержат RFC 7296 и руководство NIST.
IKEv1 больше не следует выбирать для новых систем. IETF перевела связанные спецификации в исторический статус, а Libreswan отключает IKEv1 по умолчанию и рекомендует миграцию на IKEv2. Основания приводят RFC 9395 и документация Libreswan.
При подключении Windows нельзя полагаться на название «IKEv2» как на гарантию современных алгоритмов. Microsoft до сих пор документирует сценарии со стандартным набором 3DES, SHA-1 и DH2 и называет такой набор небезопасным. Политику нужно явно согласовать на клиенте и сервере. Требование подтверждают документы Microsoft и рекомендации strongSwan.
На высокоскоростных каналах стоит проверить поддержку Extended Sequence Numbers. Обычный ESP использует 32-битный счётчик пакетов, а ESN расширяет пространство последовательностей до 64 бит и снижает риск слишком частого обновления SA. Механизм определяет RFC 4304, настройку предложений описывает strongSwan.
Постквантовая миграция IPsec уже вышла за рамки теории, но совместимость пока требует проверки обеих сторон. IKEv2 получил стандарты для нескольких обменов ключами и дополнительных предварительно распределённых ключей. Один шлюз не сможет включить такую схему в одностороннем порядке. Архитектуру расширяют RFC 9370 и RFC 9867.
Ещё один редкий сценарий связан с IP-TFS. Механизм агрегирует небольшие пакеты и фрагментирует крупные до обработки ESP, что помогает каналам с чувствительностью к размеру пакетов. strongSwan поддерживает базовый режим AGGFRAG вместе с современными ядрами Linux, но полное сокрытие формы трафика через постоянную скорость отправки пока нельзя считать готовой универсальной функцией. Возможности и ограничения описывают RFC 9347 и документация strongSwan.
IPsec хорошо подходит для связи офисов, облачных сетей и оборудования разных производителей. Протокол выигрывает там, где нужны PKI, аппаратное ускорение, встроенные клиенты операционных систем, сложная маршрутизация и совместимость с корпоративными шлюзами. Для небольшой однородной сети более простой VPN может потребовать меньше настроек, но выбор зависит от инфраструктуры, а не от популярности протокола.
Перед запуском я фиксирую адресные планы, IKE ID, Traffic Selectors, алгоритмы, правила NAT, обратные маршруты и допустимый MTU. Затем проверяю установку IKE_SA, создание CHILD_SA, rekey, счётчики ESP и реальный трафик в обоих направлениях. Различия между подключением пользователя и связью двух сетей подробнее разобраны в материале SecurityLab про Remote Access и Site-to-Site VPN.
Современный шифр не спасёт конфигурацию с неверным маршрутом, общим PSK на всех устройствах или незаметным NAT. Надёжный IPsec VPN начинается не с выбора AES-256, а с точного описания того, кто подключается, какие сети нужно защитить и каким путём каждый ответный пакет должен вернуться обратно.
Частые вопросы об IPsec VPN
Что такое IPsec VPN простыми словами?
IPsec VPN создаёт защищённый канал на сетевом уровне и шифрует IP-пакеты между устройствами или целыми сетями. IKEv2 согласует ключи и подтверждает личности сторон, а ESP защищает передаваемый трафик. IPsec часто применяют для связи офисов, подключения сотрудников и объединения локальной сети с облачной инфраструктурой.
Чем IKEv2 отличается от IPsec?
IPsec отвечает за защиту IP-трафика, а IKEv2 управляет соединением. IKEv2 согласует алгоритмы, выполняет обмен ключами, проверяет подлинность сторон и создаёт Security Association. Пользовательские данные обычно передаёт ESP, поэтому выражение «IKEv2 VPN» чаще означает IPsec VPN с протоколом управления IKEv2.
Какие порты использует IPsec VPN?
IKE обычно использует UDP 500. При обнаружении NAT соединение переходит на UDP 4500 и передаёт ESP внутри UDP. Без NAT Traversal шлюз может отправлять ESP напрямую через IP protocol 50, который не является TCP- или UDP-портом. Межсетевой экран должен учитывать выбранный режим передачи.
Нужен ли белый IP-адрес для IPsec VPN?
Хотя бы одна сторона обычно должна иметь доступный снаружи адрес или DNS-имя, чтобы второй шлюз мог начать подключение. NAT-T позволяет клиенту или филиалу работать за NAT, включая многие мобильные и домашние подключения. Два шлюза за CGNAT без проброса портов или промежуточного сервера часто не смогут установить прямой site-to-site туннель.
Что лучше для IPsec VPN, сертификат или PSK?
PSK проще настроить в небольшом проекте, но каждому туннелю нужен отдельный длинный случайный ключ. Сертификаты лучше подходят для крупной инфраструктуры, поскольку позволяют централизованно выдавать, обновлять и отзывать доступ. Один общий PSK для множества шлюзов создаёт риск массовой компрометации после утечки секрета с одного устройства.
Почему IPsec VPN подключён, но интернет или локальная сеть не работают?
Работающая IKE_SA подтверждает только успешный управляющий обмен. Трафик может не проходить из-за отсутствующей CHILD_SA, неверных Traffic Selectors, ошибочного маршрута, блокировки ESP, правила NAT или отсутствия обратного маршрута. Диагностику нужно начинать с проверки
swanctl --list-sas,ip xfrm policy, таблицы маршрутизации и счётчиков межсетевого экрана.
Почему IPsec VPN работает для ping, но не открывает сайты?
Частая причина связана с MTU и Path MTU Discovery. ESP, внешний IP-заголовок и NAT-T увеличивают размер пакета, поэтому крупные TCP-пакеты могут теряться, хотя маленькие ICMP-пакеты проходят. Нужно проверить MTU командой
ping -M do, разрешить необходимые ICMP-сообщения и при необходимости настроить меньший MTU или TCP MSS.
Можно ли использовать IPsec VPN за NAT и CGNAT?
Обычный NAT поддерживается через NAT Traversal, который переносит ESP в UDP 4500. CGNAT сложнее, поскольку пользователь не управляет внешним адресом и не может настроить проброс портов. Клиент за CGNAT обычно подключается к публичному VPN-шлюзу, но принять входящее site-to-site соединение без дополнительных механизмов чаще всего не сможет.
Что лучше, IPsec, OpenVPN или WireGuard?
IPsec подходит для корпоративных шлюзов, облачных платформ, аппаратного ускорения и встроенных клиентов операционных систем. WireGuard проще по архитектуре и часто удобнее для небольших управляемых сетей. OpenVPN гибко работает поверх TCP или UDP и легче проходит через некоторые сетевые ограничения. Выбор зависит от совместимости, модели доступа, требований к PKI и возможностей администраторов.
Безопасно ли использовать AES-256 в IPsec VPN?
AES-256 остаётся надёжным выбором при корректном режиме работы и безопасном управлении ключами. Для новых конфигураций обычно применяют AES-256-GCM, который одновременно шифрует данные и проверяет их подлинность. Само название AES-256 не гарантирует безопасность, если шлюз использует слабую группу Диффи-Хеллмана, общий PSK, устаревший IKEv1 или ошибочные политики доступа.
