Введение #
В предыдущей статье мы подробно рассмотрели, как настроить policy‑based VPN через классическую конфигурацию strongswan использовав файлы /etc/ipsec.conf и /etc/ipsec.secrets:
Настройка IPSec между серверами Ubuntu (AWS) и Ubuntu (Azure)
Это надёжный способ, но с переходом на более современный стек strongSwan с swanctl меняются некоторые подходы в конфигурации и управлении туннелями.
В этой статье я покажу:
- чем отличается policy‑based VPN через
swanctl(/etc/swanctl/swanctl.conf) от policy‑based VPN черезstrongswan-starter(/etc/ipsec.conf) - как настроить policy‑based VPN через
swanctl - как перейти от policy‑based к более гибкому route‑based VPN через
XFRM interface - готовые примеры конфигураций для обоих случаев
Почему swanctl, а не ipsec.conf #
С подходом swanctl:
✔️ Чёткое разделение конфигурации и секретов (swanctl.conf / secrets)
✔️ Упрощённое управление туннелями (swanctl --load-all, --list-sas)
✔️ Поддержка современных IKEv2 возможностей
✔️ Легко интегрируется с route‑based VPN (через if_id и виртуальный интерфейс ipsec0)
✔️ Становится стандартом для современных Debian/Ubuntu
В то время как классический ipsec.conf:
- исторически ориентирован на policy‑based подход
- требует ручной разметки политик
- меньше подходит для динамичного сетевого окружения
Предварительные требования #
- Сервер Ubuntu в AWS и сервер Ubuntu в OVH:
- Server1 vm-aws-ubuntu2404 (LAN IP 10.130.0.5, WAN IP XX.XX.XX.XX)
- Server2 vm-ovh-ubuntu2404 (Loopback0 IP 10.128.0.7, WAN IP YY.YY.YY.YY)
- В AWS инстанс за NAT Gateway, а в OVH публичный IP адрес на самом инстансе без NAT Gateway
Установка strongswan + swanctl + charon #
# Server1 vm-aws-ubuntu2404
# Server2 vm-ovh-ubuntu2404
# Если включен старый strongswan-starter, отключаем
systemctl status strongswan-starter
systemctl stop strongswan-starter
systemctl disable strongswan-starter
apt install strongswan strongswan-swanctl charon-systemd
mv /etc/swanctl/swanctl.conf /etc/swanctl/swanctl.conf.default
# Опционально
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
# Server2 vm-ovh-ubuntu2404
# Временно назначим доп. IP-адрес 10.128.0.7 на интерфейс lo
ip addr add 10.128.0.7/32 dev lo
Policy‑based VPN через swanctl #
nano /etc/swanctl/swanctl.conf
# Server1 vm-aws-ubuntu2404
connections {
s2 {
version = 2
local_addrs = 10.130.0.5
remote_addrs = YY.YY.YY.YY
proposals = aes256-sha256-modp2048
encap = yes
local {
auth = psk
id = XX.XX.XX.XX
}
remote {
auth = psk
id = YY.YY.YY.YY
}
children {
net {
local_ts = 10.130.0.5/32
remote_ts = 10.128.0.7/32
mode = tunnel
start_action = start
dpd_action = restart
}
}
}
}
secrets {
ike-psk {
secret = "StrongPSK@"
}
}
# Server2 vm-ovh-ubuntu2404
connections {
s1 {
version = 2
local_addrs = YY.YY.YY.YY # OVH WAN IP
remote_addrs = XX.XX.XX.XX
proposals = aes256-sha256-modp2048
encap = yes
local {
auth = psk
id = YY.YY.YY.YY
}
remote {
auth = psk
id = XX.XX.XX.XX
}
children {
net {
local_ts = 10.128.0.7/32
remote_ts = 10.130.0.5/32
mode = tunnel
start_action = start
dpd_action = restart
}
}
}
}
secrets {
ike-psk {
secret = "StrongPSK@"
}
}
Запускаем и проверяем
# Server1 vm-aws-ubuntu2404
# Server2 vm-ovh-ubuntu2404
systemctl start strongswan
systemctl status strongswan
swanctl --list-sas
ip xfrm policy
ip xfrm state
ls -l /var/run/charon.vici
# Пинг через туннель
ping 10.128.0.7 # с server1
ping 10.130.0.5 # с server2
Route‑based VPN через swanctl #
nano /etc/swanctl/swanctl.conf
# Server1 vm-aws-ubuntu2404
connections {
s2 {
version = 2
local_addrs = 10.130.0.5
remote_addrs = YY.YY.YY.YY
proposals = aes256-sha256-modp2048
encap = yes
local {
auth = psk
id = XX.XX.XX.XX
}
remote {
auth = psk
id = YY.YY.YY.YY
}
children {
net {
local_ts = 0.0.0.0/0
remote_ts = 0.0.0.0/0
mode = tunnel
if_id_in = 42
if_id_out = 42
start_action = start
dpd_action = restart
}
}
}
}
secrets {
ike-psk {
secret = "StrongPSK@"
}
}
# Server2 vm-ovh-ubuntu2404
connections {
s1 {
version = 2
local_addrs = YY.YY.YY.YY # OVH WAN IP
remote_addrs = XX.XX.XX.XX
proposals = aes256-sha256-modp2048
encap = yes
local {
auth = psk
id = YY.YY.YY.YY
}
remote {
auth = psk
id = XX.XX.XX.XX
}
children {
net {
local_ts = 0.0.0.0/0
remote_ts = 0.0.0.0/0
mode = tunnel
if_id_in = 42
if_id_out = 42
start_action = start
dpd_action = restart
}
}
}
}
secrets {
ike-psk {
secret = "StrongPSK@"
}
}
Настройка интерфейсов XFRM (ipsec0) и маршрутов #
Используется XFRM interface — виртуальный интерфейс Linux, привязанный к IPsec-туннелю. Это современная альтернатива VTI.
# Server1 vm-aws-ubuntu2404
ip link add ipsec0 type xfrm dev eth0 if_id 42
ip addr add 169.254.100.1/30 dev ipsec0
ip link set ipsec0 up
ip route add 10.128.0.7 via 169.254.100.2 dev ipsec0
# Server2 vm-ovh-ubuntu2404
ip link add ipsec0 type xfrm dev ens3 if_id 42
ip addr add 169.254.100.2/30 dev ipsec0
ip link set ipsec0 up
ip route add 10.130.0.5 via 169.254.100.1 dev ipsec0
Перезапускаем и проверяем
# Server1 vm-aws-ubuntu2404
# Server2 vm-ovh-ubuntu2404
systemctl restart strongswan
systemctl status strongswan
swanctl --list-sas
ip xfrm policy
ip xfrm state
ls -l /var/run/charon.vici
# Пинг через туннель
ping 169.254.100.2 # с server1
ping 10.128.0.7 # с server1
ping 169.254.100.1 # с server2
ping 10.130.0.5 # с server2
✅ Вывод
- Policy-based VPN подходит для простых связей “сервер ↔ сервер”.
- Route-based VPN подходит для сетевых инфраструктур, когда нужно гибко маршрутизировать, подключать несколько подсетей и использовать динамические маршруты.
Используя
swanctlиif_idсipsec0, мы получаем полноценный route-based VPN без привязки к конкретным IP-адресам.