IPsec VPN: архитектура, протоколы и настройка
С ростом числа кибератак и угроз утечки данных надежное шифрование и безопасные соединения становятся необходимостью. Для обеспечения конфиденциальности и защиты от перехвата все больше пользователей и компаний обращаются к VPN. Среди множества решений IPsec (Internet Protocol Security) остается одним из наиболее надежных и распространенных стандартов.
IPsec обеспечивает шифрование, аутентификацию и целостность передаваемых данных, работая на сетевом уровне. Это делает его особенно полезным для защиты корпоративных сетей, облачных инфраструктур и мобильных соединений.
В этой статье мы подробно рассмотрим ключевые компоненты и принципы работы IPsec, его архитектуру и протоколы, а также настройку IPsec VPN с помощью инфраструктуры Servercore, проверку туннеля и решение частых проблем.
Что такое IPsec
IPsec (Internet Protocol Security) — это набор протоколов, обеспечивающих безопасную передачу данных в IP-сетях. Он работает на сетевом уровне модели OSI (L3), обеспечивая аутентификацию, целостность и шифрование данных между узлами. В отличие от других методов защиты, IPsec может шифровать весь IP-трафик, что делает его популярным выбором для VPN-соединений.
Первый стандарт IPsec был опубликован в 1995 году, его разрабатывали параллельно IPv6. В 1998 году IETF утвердил его как универсальный протокол для защиты сетевых соединений. Сегодня IPsec широко используется в корпоративных сетях, дата-центрах и облачных средах для защиты трафика.
Для чего нужен IPsec? Его основное назначение — обеспечение безопасности данных, передаваемых по сети. Набор протоколов выполняет шифрование, проверяет подлинность отправителей и обеспечивает целостность данных, защищая их от изменений во время передачи. Также IPsec защищает от повторного использования перехваченных пакетов благодаря механизму anti-replay.
Функции IPSec
IPsec обеспечивает защиту передаваемых данных с помощью механизмов аутентификации, шифрования и управления ключами.
Аутентификация помогает проверить источник данных. Для этого стороны используют общий ключ (IPsec PSK, Pre-Shared Key) или цифровые сертификаты с подписями RSA или ECDSA. PSK проще настроить, но цифровые сертификаты, основанные на инфраструктуре открытых ключей (PKI), предлагают более высокий уровень защиты: каждой стороне выдается собственный сертификат, и его можно отозвать, не меняя настройки остальных участников. IPsec также реализует механизмы защиты от атак типа «человек посередине» (MITM), предотвращая возможность перехвата и подмены данных.
Шифрование в IPsec защищает передаваемую информацию от несанкционированного доступа. Симметричные алгоритмы, такие как AES, обеспечивают высокую скорость шифрования данных. Асимметричные алгоритмы (RSA, ECDSA) и обмен ключами Диффи — Хеллмана применяются в протоколе IKE (Internet Key Exchange) для аутентификации сторон и защиты процесса обмена симметричными ключами, которые используются для безопасной передачи информации.
Управление ключами в IPsec играет ключевую роль в поддержании безопасности соединения. Протокол IKE создает защищенный канал между участниками и настраивает параметры шифрования данных. Для повышения безопасности IKE использует PFS (Perfect Forward Secrecy), который гарантирует, что компрометация одного ключа не затронет другие сессии.
Что такое IPSec VPN и как он устроен
IPsec VPN — это технология, которая использует IPsec для создания защищенного VPN-туннеля между устройствами или сетями. VPN на базе IPsec может работать в двух режимах:
- Транспортный режим — защищает только полезную нагрузку (данные внутри IP-пакетов), оставляя заголовки без изменений. Используется для шифрования соединений между двумя узлами.
- Туннельный режим — шифрует весь IP-пакет, инкапсулируя его в новый IP-заголовок. Этот режим применяют в корпоративных VPN и межсетевых соединениях.
При выборе технологии для защиты сетевых соединений важно понимать различия между IPsec VPN и SSL VPN. Оба решения обеспечивают безопасную передачу данных, но отличаются по принципу работы, уровню защиты и сценариям использования. IPsec VPN работает на сетевом уровне и обеспечивает полное шифрование всего трафика, тогда как SSL VPN защищает только соединения на уровне приложений. В таблице ниже представлены основные различия между этими протоколами.
| Параметр | IPsec VPN | SSL VPN |
| Уровень работы | Сетевой (L3) | Транспортный (L4) или прикладной (L7) |
| Шифрование | ESP (Encapsulating Security Payload) | TLS (Transport Layer Security) |
| Применение | Подключает всю сеть или устройство | Работает через браузер или клиент |
| Гибкость | Требует настройки на стороне клиента и сервера | Прост в использовании, работает через веб-интерфейс |
IPsec VPN лучше подходит для защиты всего сетевого трафика, а SSL VPN чаще используется для удаленного доступа через браузер.
Как работает IPsec
IPsec обеспечивает защищенную передачу данных на уровне сети (L3 модели OSI). В отличие от VPN-протоколов, которые работают на транспортном уровне (L4), IPsec интегрирован в IP-протокол, что делает его более универсальным для построения безопасных туннелей между устройствами, серверами и корпоративными сетями.
Как работает IPsec VPN
Работа IPsec строится на двух основных механизмах: аутентификации и шифровании трафика. Соединение устанавливается в несколько этапов:
- Инициализация соединения — выполняется через протокол IKE. Сегодня используют его вторую версию, поэтому связку часто обозначают как IKEv2/IPsec. IKE создает защищенный канал и согласует параметры безопасности для данных — IPsec SA (Security Association).
- Аутентификация сторон — используется цифровая подпись, сертификаты или предварительно согласованные ключи (Pre-Shared Keys, PSK) для подтверждения подлинности узлов.
- Шифрование и защита данных — весь сетевой трафик, проходящий через туннель, шифруется с помощью симметричных алгоритмов (AES, ChaCha20).
- Контроль целостности данных — реализуется через ESP (шифрование и аутентификация) или AH (только аутентификация и проверка целостности).
- Передача данных через туннель — пакеты передаются через зашифрованный канал, а на стороне получателя расшифровываются и проверяются на целостность.
- Обновление и закрытие соединения — по истечении времени жизни SA или после передачи заданного объема данных стороны обновляют ключи (rekeying) без разрыва туннеля. Туннель закрывается, когда одна из сторон завершает соединение или перестает отвечать.
Как IPsec влияет на MSS и MTU: фрагментация VPN
Использование IPsec влияет на параметры MSS (Maximum Segment Size) и MTU (Maximum Transmission Unit) из-за дополнительной нагрузки, связанной с шифрованием и аутентификацией данных. При инкапсуляции пакетов IPsec добавляет заголовки ESP или AH, а в туннельном режиме — еще и новый IP-заголовок. В зависимости от алгоритмов и использования NAT-T пакет вырастает примерно на 50–80 байт. Это может привести к превышению допустимого размера MTU, вызывая фрагментацию и снижая производительность сети.
Фрагментирование VPN — это разделение пакета, который после инкапсуляции стал больше MTU канала, на несколько частей. Принимающая сторона собирает фрагменты обратно, но это добавляет задержку и нагрузку. Если же промежуточное оборудование отбрасывает фрагменты, проблема проявляется характерно: туннель поднят, ping проходит, а крупные пакеты теряются — например, не открываются сайты или обрываются загрузки файлов.
Чтобы избежать фрагментации, MSS уменьшают на уровне TCP с учетом накладных расходов IPsec. На Linux-шлюзе это делается правилом iptables для трафика, уходящего в туннель:
sudo iptables -t mangle -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 \ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Отдельно фрагментация касается самого протокола IKE: сообщения с сертификатами могут не помещаться в MTU. Для этого в IKEv2 есть собственный механизм фрагментации (RFC 7383), в strongSwan он включается параметром fragmentation и по умолчанию активен.
Преимущества IPsec
IPsec остается одним из самых надежных протоколов для организации VPN благодаря нескольким ключевым преимуществам:
- Высокий уровень безопасности — поддерживает современные алгоритмы шифрования (AES-256, ChaCha20), аутентификации (RSA, ECDSA) и защиты данных.
- Гибкость и масштабируемость — работает на уровне IP, организовывает VPN-туннели между разными типами устройств и сетей, включая облачные решения.
- Защита от атак MITM и перехвата данных — обеспечивает целостность трафика и защищает от изменений данных в процессе передачи.
- Поддержка различных способов аутентификации — общие ключи (PSK) и цифровые сертификаты повышают надежность подключения.
- Интеграция с другими системами безопасности — IPsec можно использовать в сочетании с файрволами, IDS/IPS и другими средствами защиты сети.
- Совместимость с большинством ОС и устройств — поддерживается Windows, Linux, macOS, мобильными платформами и маршрутизаторами.
Как IPsec помогает бизнесу
IPsec защищает корпоративные сети, мобильные соединения и облачные сервисы. Для корпоративных сетей набор протоколов позволяет организовать защищенные соединения между офисами, удаленными филиалами и дата-центрами. Организация VPN-канала между офисами — один из самых частых сценариев: VPN-туннель для офиса объединяет локальные сети так, будто они находятся в одном здании. Туннельный режим шифрует весь сетевой трафик, предотвращая утечки данных и атаки. Это особенно важно для организаций, работающих с конфиденциальной информацией, такой как финансовые данные, медицинские записи или интеллектуальная собственность.
В условиях удаленной работы IPsec обеспечивает безопасный доступ сотрудников к корпоративным ресурсам. При подключении к публичным Wi-Fi-сетям зашифрованное соединение защищает данные от перехвата.
Компании все чаще размещают свою IT-инфраструктуру в облаке, что требует надежных механизмов защиты данных при передаче между облачными сервисами и локальными сетями. IPsec часто используют для защиты трафика между корпоративными сетями и облаком (site-to-site), внутри облака преобладают прикладные протоколы (HTTPS, TLS). Это снижает риски утечек данных и повышает надежность взаимодействия между сервисами.
Архитектура и протоколы IPsec
Архитектура IPsec включает несколько уровней, каждый из которых выполняет свою роль в обеспечении безопасности передачи данных.
Первый уровень архитектуры IPsec составляют протоколы защиты данных. Протокол ESP (Encapsulating Security Payload) отвечает за конфиденциальность, целостность и аутентификацию данных. Он использует шифрование для защиты передаваемой информации и поддерживает транспортный и туннельный режимы работы — поэтому, когда говорят про ESP VPN, обычно имеют в виду IPsec ESP в туннельном режиме. Протокол AH (Authentication Header) выполняет аутентификацию отправителя и контроль целостности данных. В отличие от ESP, он не шифрует передаваемые данные, но защищает их от подмены. На практике AH почти не используют: он несовместим с NAT, а ESP закрывает те же задачи.
Второй уровень обеспечивает механизмы аутентификации и шифрования. Для подтверждения подлинности применяются общий ключ (Pre-Shared Key) и цифровые сертификаты X.509. Шифрование выполняется с применением симметричных алгоритмов — AES (в том числе в режиме GCM) и ChaCha20. Устаревшие алгоритмы, такие как 3DES, для новых конфигураций не используют.
Третий уровень определяет правила взаимодействия между различными реализациями IPsec через стандартизированные параметры безопасности. Этот компонент регламентирует использование алгоритмов шифрования, аутентификации и управления ключами, обеспечивая совместимость между разными IPsec-решениями. Каждая согласованная SA получает идентификатор SPI (Security Parameter Index): по нему принимающая сторона понимает, какими ключами и алгоритмами обрабатывать пакет.
Четвертый уровень включает IKE (Internet Key Exchange), который играет ключевую роль в установке защищенных соединений между узлами. Он управляет процессом генерации и обмена ключами для шифрования трафика, а также поддерживает динамическое обновление параметров безопасности без прерывания активных соединений.
Какие порты и протоколы использует IPsec
IPsec работает на сетевом уровне, поэтому часть его компонентов — это не порты, а отдельные IP-протоколы. Чтобы туннель поднялся, файрволы с обеих сторон должны пропускать следующий трафик:
| Компонент | Протокол / порт | Назначение |
|---|---|---|
| IKE | UDP 500 | Согласование параметров и обмен ключами |
| NAT-T | UDP 4500 | IKE и ESP, если между сторонами есть NAT |
| ESP | IP-протокол 50 | Передача зашифрованных данных |
| AH | IP-протокол 51 | Аутентификация без шифрования (используется редко) |
Если хотя бы одна сторона находится за NAT, IKE автоматически переходит с порта 500 на 4500, а ESP-пакеты упаковываются в UDP. Поэтому на практике для IPsec открывают порты UDP 500 и 4500 и протокол ESP.
Настройка IPsec VPN в Servercore
strongSwan — это open-source реализация IPsec для Linux. Она поддерживает IKEv1 и IKEv2, туннели сеть—сеть (site-to-site) и удаленный доступ для пользователей. В этой главе рассмотрим запуск виртуальной машины Servercore со strongSwan для IPsec-подключения сеть—сеть: маршрутизации трафика между облачной сетью и удаленной точкой подключения. А также разберем отказоустойчивую схему с двумя VPN-серверами.
Исходные данные
Для правильной работы IPsec необходимо убедиться, что виртуальная машина имеет доступ к обеим сетям и корректно маршрутизирует трафик. Для установления соединения потребуется:
- ВМ, запущенная на образе Ubuntu 22.04 или 24.04 с двумя портами;
- первый порт виртуальной машины подключен к публичной сети и используется как default route;
- второй порт подключен к приватной сети, которую необходимо маршрутизировать.
Важно учитывать, что файрвол и правила маршрутизации должны быть настроены так, чтобы обеспечивать беспрепятственный обмен данными между интерфейсами, а с удаленного адреса должны быть разрешены UDP 500, UDP 4500 и ESP.
У виртуальной машины для IPsec настроено два порта с адресами 188.68.206.154 и 192.168.10.10 для публичной и приватной сети соответственно. На удаленной стороне — шлюз с публичным адресом 51.250.46.166 и приватной сетью 192.168.20.0/24. Его настраивают зеркально: параметры left и right меняются местами.
Настройка VPN с одним инстансом
Подключаемся к ВМ по SSH и начинаем настройку. Сначала необходимо установить демон strongSwan и включить его в автозагрузку:
sudo apt update sudo apt install -y strongswan sudo systemctl enable strongswan-starter
Далее нужно включить маршрутизацию пакетов между интерфейсами, поскольку наша ВМ будет служить шлюзом для приватной сети и отправлять трафик через публичную сеть с шифрованием.
sudo tee /etc/sysctl.d/99-vpn-ipsec.conf > /dev/null << 'EOF' net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 EOF sudo sysctl -p /etc/sysctl.d/99-vpn-ipsec.conf
Эти команды создают конфигурационный файл sysctl и применяют его. Файлы в /etc записываем через sudo tee: в варианте sudo cat << EOF > файл перенаправление выполняется без прав root, и команда завершится ошибкой. Далее создаем основной конфигурационный файл IPsec для strongSwan:
sudo tee /etc/ipsec.conf > /dev/null << 'EOF'
config setup
uniqueids=yes
strictcrlpolicy=no
conn site-to-site-vpn
type=tunnel
keyexchange=ikev2
authby=secret
left=%defaultroute
leftid=188.68.206.154
leftsubnet=192.168.10.0/24
right=51.250.46.166
rightsubnet=192.168.20.0/24
ike=aes256-sha256-ecp256!
esp=aes256gcm16-ecp256!
keyingtries=0
ikelifetime=8h
lifetime=1h
dpddelay=30s
dpdaction=restart
auto=start
EOF
Важные опции, которые требуют настройки в зависимости от вашего окружения и используемых адресов:
- leftid — публичный адрес самой ВМ IPsec;
- leftsubnet — приватная сеть, созданная в облаке Servercore для других ВМ. Из нее необходимо иметь доступ к ВМ в другом облаке;
- right — публичный адрес удаленной ВМ, то есть в нашем случае 51.250.46.166;
- rightsubnet — удаленная приватная сеть, которая была создана в другом облаке и используется там для ВМ.
Как выбрать параметры IKE и ESP
Параметры шифрования в примере подобраны под современные рекомендации, но главное правило — наборы алгоритмов должны совпадать на обеих сторонах туннеля и поддерживаться используемой версией strongSwan или оборудования на удаленной стороне. Если стороны не договорятся, туннель не поднимется, а в логах появится ошибка NO_PROPOSAL_CHOSEN.
- keyexchange=ikev2 — используем IKEv2: он быстрее устанавливает соединение, поддерживает NAT-T и фрагментацию IKE. IKEv1 стоит выбирать, только если удаленная сторона — старый VPN-сервер IKEv1/IPsec без поддержки второй версии.
- ike=aes256-sha256-ecp256! — параметры для IKE SA: шифрование AES-256, контроль целостности SHA-256 и обмен ключами Диффи — Хеллмана на эллиптической кривой (группа 19). Восклицательный знак означает, что strongSwan не будет предлагать другие алгоритмы, кроме перечисленных.
- esp=aes256gcm16-ecp256! — параметры для защиты данных: AES-256 в режиме GCM сразу обеспечивает шифрование и контроль целостности. Группа Диффи — Хеллмана в строке ESP включает PFS при обновлении ключей.
- Если удаленная сторона не поддерживает эллиптические кривые, используйте modp2048 (группа 14) или выше, а если не поддерживает GCM — aes256-sha256. Группы modp1024 и ниже, а также 3DES, MD5 и SHA-1 для новых конфигураций использовать не стоит.
- ikelifetime=8h и lifetime=1h — время жизни IKE SA и SA для данных. Ключи обновляются до истечения срока, туннель при этом не разрывается.
- dpddelay=30s и dpdaction=restart — механизм Dead Peer Detection: если удаленная сторона перестала отвечать, strongSwan переустановит туннель. В IKEv2 таймаут определяется повторными отправками запросов, поэтому параметр dpdtimeout не нужен.
- leftid и rightid — идентификатор IPsec, под которым сторона представляется при аутентификации. При авторизации по PSK обычно используют IP-адрес. Если rightid не задан, strongSwan ожидает, что идентификатор удаленной стороны совпадает с адресом из right.
После создания основного файла конфигурации нужно создать файл с секретом, который будет содержать пароль для подключения:
sudo tee /etc/ipsec.secrets > /dev/null << 'EOF' 188.68.206.154 51.250.46.166 : PSK "<SECRET>" EOF
Где <SECRET> — пароль, указанный с обеих сторон туннеля, то есть на обеих виртуальных машинах VPN IPsec. Для PSK лучше использовать длинную случайную строку, например сгенерированную командой openssl rand -base64 32.
Перезагружаем IPsec демон и проверяем статус подключения:
sudo systemctl restart strongswan-starter sudo ipsec status
Настройка отказоустойчивой схемы
В отличие от предыдущей схемы, в качестве IP-адреса шлюза в приватной сети и в качестве основного адреса для VPN-туннеля будут использоваться VIP-адреса. Они будут перемещаться между ВМ с помощью VRRP.
Чтобы настроить отказоустойчивую схему, необходимо запустить еще одну такую же ВМ для VPN. Будем ее называть vpn2, а первую ВМ — vpn1.
Далее на второй ВМ воспроизводятся аналогичные первой базовые настройки:
sudo apt update sudo apt install -y strongswan sudo systemctl enable strongswan-starter sudo tee /etc/sysctl.d/99-vpn-ipsec.conf > /dev/null << 'EOF' net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 EOF sudo sysctl -p /etc/sysctl.d/99-vpn-ipsec.conf
Перед IPsec необходимо настроить VRRP с помощью демона keepalived. Устанавливаем службу:
sudo apt install -y keepalived
Настраиваем VRRP-конфигурацию так, чтобы оба VIP перемещались одновременно и находились в одной группе. При смене статуса инстанса с MASTER на BACKUP и обратно необходимо, чтобы IPsec включался и выключался соответственно, так как туннель должен быть построен только от одной ВМ в один момент времени.
Настраиваем VRRP на виртуальной машине vpn2:
sudo tee /usr/local/sbin/notify-ipsec.sh > /dev/null << 'EOF'
#!/bin/bash
TYPE=$1
NAME=$2
STATE=$3
case $STATE in
"MASTER") /usr/sbin/ipsec restart
;;
"BACKUP") /usr/sbin/ipsec stop
;;
"FAULT") /usr/sbin/ipsec stop
exit 0
;;
*) /usr/bin/logger "ipsec unknown state"
exit 1
;;
esac
EOF
sudo chmod a+x /usr/local/sbin/notify-ipsec.sh
sudo tee /etc/keepalived/keepalived.conf > /dev/null << 'EOF'
vrrp_sync_group G1 {
group {
EXT
INT
}
notify "/usr/local/sbin/notify-ipsec.sh"
}
vrrp_instance INT {
state BACKUP
interface eth1
virtual_router_id 11
priority 25
advert_int 1
authentication {
auth_type PASS
auth_pass <SECRET>
}
virtual_ipaddress {
192.168.10.100/24
}
garp_master_delay 1
}
vrrp_instance EXT {
state BACKUP
interface eth0
virtual_router_id 22
priority 25
advert_int 1
authentication {
auth_type PASS
auth_pass <SECRET>
}
virtual_ipaddress {
188.68.206.158/29
}
garp_master_delay 1
}
EOF
Эти команды создают два файла:
- /usr/local/sbin/notify-ipsec.sh — скрипт, который будет вызываться при смене статуса VRRP и будет выключать/включать IPsec;
- /etc/keepalived/keepalived.conf — файл конфигурации keepalived для двух групп.
Учитывайте, что keepalived использует только первые 8 символов из auth_pass.
Далее необходимо перезагрузить keepalived и включить его в автозапуске:
sudo systemctl restart keepalived sudo systemctl enable keepalived
Затем можно приступать к настройке IPsec на vpn2. Конфигурационный файл теперь будет немного другим, так как туннель должен строиться с VIP-адреса, а не с адреса на интерфейсе.
sudo tee /etc/ipsec.conf > /dev/null << 'EOF'
config setup
uniqueids=yes
strictcrlpolicy=no
conn site-to-site-vpn
type=tunnel
keyexchange=ikev2
authby=secret
left=188.68.206.158
leftid=188.68.206.158
leftsubnet=192.168.10.0/24
right=51.250.46.166
rightsubnet=192.168.20.0/24
ike=aes256-sha256-ecp256!
esp=aes256gcm16-ecp256!
keyingtries=0
ikelifetime=8h
lifetime=1h
dpddelay=30s
dpdaction=restart
auto=start
EOF
Файл с секретом создается тоже с VIP-адресом:
sudo tee /etc/ipsec.secrets > /dev/null << 'EOF' 188.68.206.158 51.250.46.166 : PSK "<SECRET>" EOF
Настройка vpn2 окончена. Приступаем к настройке vpn1, так как на первой ВМ тоже надо запустить VRRP и подправить конфигурацию IPsec.
Так как эта схема строится для отказоустойчивости, большинство конфигурационных файлов будут точно такими же, как и на vpn2. Исключение — роль VRRP у этого инстанса будет MASTER. Устанавливаем keepalived, создаем конфигурацию и скрипт контроля IPsec:
sudo apt install -y keepalived
sudo tee /usr/local/sbin/notify-ipsec.sh > /dev/null << 'EOF'
#!/bin/bash
TYPE=$1
NAME=$2
STATE=$3
case $STATE in
"MASTER") /usr/sbin/ipsec restart
;;
"BACKUP") /usr/sbin/ipsec stop
;;
"FAULT") /usr/sbin/ipsec stop
exit 0
;;
*) /usr/bin/logger "ipsec unknown state"
exit 1
;;
esac
EOF
sudo chmod a+x /usr/local/sbin/notify-ipsec.sh
sudo tee /etc/keepalived/keepalived.conf > /dev/null << 'EOF'
vrrp_sync_group G1 {
group {
EXT
INT
}
notify "/usr/local/sbin/notify-ipsec.sh"
}
vrrp_instance INT {
state MASTER
interface eth1
virtual_router_id 11
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass <SECRET>
}
virtual_ipaddress {
192.168.10.100/24
}
garp_master_delay 1
}
vrrp_instance EXT {
state MASTER
interface eth0
virtual_router_id 22
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass <SECRET>
}
virtual_ipaddress {
188.68.206.158/29
}
garp_master_delay 1
}
EOF
sudo systemctl enable keepalived
Пароль <SECRET>, указанный в конфигурации, должен быть одинаковым на обеих ВМ VPN.
Далее нужно обновить конфигурацию секрета и IPsec так, чтобы вместо основного адреса был указан VIP. То есть конфигурации IPsec и секрета на vpn1 и vpn2 будут идентичны.
sudo tee /etc/ipsec.conf > /dev/null << 'EOF'
config setup
uniqueids=yes
strictcrlpolicy=no
conn site-to-site-vpn
type=tunnel
keyexchange=ikev2
authby=secret
left=188.68.206.158
leftid=188.68.206.158
leftsubnet=192.168.10.0/24
right=51.250.46.166
rightsubnet=192.168.20.0/24
ike=aes256-sha256-ecp256!
esp=aes256gcm16-ecp256!
keyingtries=0
ikelifetime=8h
lifetime=1h
dpddelay=30s
dpdaction=restart
auto=start
EOF
sudo tee /etc/ipsec.secrets > /dev/null << 'EOF'
188.68.206.158 51.250.46.166 : PSK "<SECRET>"
EOF
Перезагружаем keepalived и проверяем статус IPsec:
sudo systemctl restart keepalived sudo ipsec status
На удаленной стороне в качестве адреса шлюза (right) теперь указывается VIP 188.68.206.158, а ВМ в приватной сети Servercore должны отправлять трафик в удаленную сеть через внутренний VIP 192.168.10.100.
Проверка и диагностика IPsec-туннеля
После настройки нужно убедиться, что туннель не только установлен, но и пропускает трафик.
- Проверьте статус соединения.
sudo ipsec statusall
В выводе должны быть две записи: IKE SA в состоянии ESTABLISHED и CHILD SA в состоянии INSTALLED с указанием подсетей обеих сторон. Счетчики bytes_i и bytes_o показывают, сколько данных прошло через туннель в каждую сторону.
- Проверьте прохождение трафика. Отправьте ping с ВМ в приватной сети 192.168.10.0/24 на адрес из сети 192.168.20.0/24 и посмотрите, растут ли счетчики в ipsec statusall. Установленные на уровне ядра SA и политики можно посмотреть командами sudo ip xfrm state и sudo ip xfrm policy.
- Посмотрите логи.
sudo journalctl -u strongswan-starter -f
Для подробной отладки временно добавьте в секцию config setup параметр charondebug=»ike 2, knl 2, cfg 2″ и перезапустите strongSwan. В рабочей конфигурации подробное логирование лучше отключить.
- Проверьте, доходят ли пакеты до шлюза.
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500 or esp'
Если пакеты IKE уходят, но ответов нет, проблема на пути до удаленной стороны: закрыты порты или неверен адрес.
Частые ошибки и их причины
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| NO_PROPOSAL_CHOSEN | Не совпадают алгоритмы IKE или ESP | Строки ike и esp на обеих сторонах |
| AUTHENTICATION_FAILED, no shared key found | Разные PSK или идентификаторы | ipsec.secrets, leftid и rightid |
| TS_UNACCEPTABLE | Не совпадают подсети | leftsubnet и rightsubnet должны зеркально совпадать на сторонах |
| Туннель не поднимается, ответов на IKE нет | Закрыты порты или есть NAT | UDP 500, UDP 4500 и ESP на файрволах обеих сторон |
| Туннель поднят, но трафик не проходит | Нет маршрутизации | net.ipv4.ip_forward, маршруты к удаленной подсети на ВМ в приватной сети, правила файрвола и NAT на шлюзе |
| Ping проходит, а сайты и файлы — нет | Фрагментация из-за MTU | MSS clamping, MTU интерфейсов |
Для отказоустойчивой схемы дополнительно проверьте переключение: остановите keepalived на vpn1 (sudo systemctl stop keepalived) и убедитесь, что оба VIP появились на vpn2 (ip addr), а sudo ipsec status на vpn2 показывает установленный туннель.
Частые вопросы об IPsec VPN
Что такое IPsec VPN простыми словами? Это зашифрованный канал между двумя устройствами или сетями через интернет. Например, IPsec VPN позволяет объединить сеть офиса и облачную инфраструктуру так, чтобы трафик между ними нельзя было прочитать или подменить по пути.
Чем отличаются IPsec и IKEv2? IPsec — это набор протоколов для защиты самих данных (ESP и AH). IKEv2 — протокол, с помощью которого стороны проверяют друг друга и договариваются о ключах и алгоритмах. Они работают в паре, поэтому такие VPN часто называют IKEv2/IPsec. Предыдущая версия, IKEv1, сегодня используется в основном для совместимости со старым оборудованием.
Чем отличаются ESP и AH в IPsec? ESP шифрует данные и проверяет их целостность, AH только проверяет подлинность и целостность без шифрования. AH несовместим с NAT, поэтому в современных VPN почти всегда используют ESP.
Чем отличаются туннельный и транспортный режимы IPsec? В транспортном режиме шифруется только содержимое пакета, а исходный IP-заголовок сохраняется — так защищают соединение между двумя узлами. В туннельном режиме весь пакет шифруется и упаковывается в новый, поэтому этот режим используют для соединения сетей.
Какие порты и протоколы использует IPsec VPN? UDP 500 для IKE, UDP 4500 для NAT-T, а также IP-протокол 50 (ESP). Протокол 51 (AH) нужен, только если используется AH.
Почему IPsec VPN подключается, но трафик не проходит? Чаще всего причина в маршрутизации или фильтрации: на шлюзе не включена пересылка пакетов, на серверах в приватной сети нет маршрута к удаленной подсети, трафик блокирует файрвол или попадает под правило NAT. Еще одна частая причина — проблемы с MTU. Порядок проверки описан в разделе о диагностике.
Как обеспечить отказоустойчивость IPsec VPN? Использовать два VPN-шлюза с общим VIP-адресом, который переключается между ними с помощью VRRP (keepalived), как в схеме выше. Также стоит включить Dead Peer Detection, чтобы туннель автоматически переустанавливался после сбоя на удаленной стороне.
Заключение
IPsec давно зарекомендовал себя как один из самых надежных инструментов для защиты передаваемых данных. Он широко используется в корпоративных и облачных сетях, обеспечивая безопасное соединение между узлами. Современные реализации IPsec позволяют адаптировать настройку под разные сценарии — от удаленного доступа сотрудников до защиты межсетевого взаимодействия.
На облачных серверах Servercore можно развернуть собственный IPsec-шлюз на strongSwan и связать облачную сеть с офисом или инфраструктурой на другой площадке. Для отказоустойчивости шлюзы можно объединить в пару с общим VIP-адресом, как в схеме из этой статьи.