MyCottage.cc

Объединение офисов
в одну сеть (StrongSwan)

Часть 1 · Site‑to‑Site + Road‑Warrior

Максимально подробный гайд с готовыми примерами конфигурации для 3 офисов, шаблонами добавления новых офисов и блоком по отладке.

Часть 2: Подключение офисных роутеров

Введение и схема сети (hub‑spoke + Road‑Warrior)

strongSwan — open‑source VPN‑решение на базе IPsec, предназначенное для построения защищённых соединений между узлами и сетями. Оно реализует IKEv2, который отвечает за установку защищённого канала и обмен ключами.

Ключевые возможности:

  • Поддержка IKEv2 (современный и безопасный протокол)
  • Работа в Linux (серверы, VPS, облака)
  • Поддержка: Site‑to‑Site и Road Warrior
  • Совместимость: Windows, macOS, iOS, Android

В этой статье мы настраиваем центральный узел (hub) на VPS и подключаем к нему офисы (spokes) как site‑to‑site, плюс даём вариант для удалённых сотрудников (Road‑Warrior).

Сценарии применения

Основные сценарии:

  • Site‑to‑Site (основной акцент) — объединение нескольких офисов/объектов в одну сеть. После настройки все сети “видят” друг друга как локальные, а IPsec шифрует трафик между ними.
  • Road Warrior — удалённые сотрудники подключаются к сети компании (дом/командировка/ноутбук/телефон).

Зачем объединять объекты в одну сеть

  • Централизованные сервисы: 1С/ERP, файловые серверы, CRM, базы данных — единая инфраструктура.
  • Упрощение администрирования: один домен/AD, политики, мониторинг.
  • Безопасность: весь трафик шифруется, меньше “дыр” через открытые порты.
  • Экономия: не нужны дорогие MPLS/каналы — работает через интернет.

Схема сети (3 офиса) — triangle topology

Пример подсетей:

  • Офис 1: 192.168.1.0/24
  • Офис 2: 192.168.2.0/24
  • Офис 3: 192.168.3.0/24
(схема ниже — для визуального понимания, без привязки к конкретным IP)

Установка strongSwan (VPS)

Для тестов и роли центрального узла (hub) удобно использовать VPS.

Рекомендованный VPS для strongSwan: AEZA
Быстро поднять сервер с белым IP и начать тестировать VPN можно на AEZA. Ссылка с поддержкой проекта: aeza.net
  • Ubuntu 22.04 / 24.04
  • 1 CPU / 1GB RAM достаточно
  • Белый IP обязателен

Требования к VPS

  • Публичный белый IPv4 (обязательно), желательно без CGNAT
  • Открытые UDP 500/4500 (и возможность управлять firewall)
  • Linux: Ubuntu 22.04/24.04 или Debian 12
  • Ресурсы: 1 vCPU / 1 GB RAM хватает для нескольких офисов и десятков Road‑Warrior клиентов
  • DNS‑имя (опционально): удобно для leftid и сертификатов

Установка и базовая подготовка

apt update && apt upgrade -y
apt install -y strongswan strongswan-pki strongswan-swanctl

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

ufw allow 500/udp
ufw allow 4500/udp
ufw reload

Рекомендуемые шифры (2026)

  • IKE: aes256gcm16-prfsha384-ecp384
  • ESP: aes256gcm16-ecp384

Порты и протоколы IKEv2/IPsec

Для IKEv2 обычно достаточно UDP 500/4500. В некоторых сетях может понадобиться ESP (50).

Полная конфигурация strongSwan (два варианта)

strongSwan можно настраивать двумя основными способами: через swanctl (современный вариант на базе VICI) или через классические файлы ipsec.conf/ipsec.secrets. Ниже приведены оба — выберите один, смешивать их не нужно.

PSK vs сертификаты
Для простоты примеры ниже используют PSK. Для продакшена рекомендуется перейти на сертификаты (X.509) или как минимум на уникальный PSK на каждый офис и регулярную ротацию.

Вариант A: swanctl (рекомендуемый)

Настройка site‑to‑site (3+ офисов) — swanctl

Ниже — пример для хаба (VPS). Локальные сети офисов: 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24. В примере hub “видит” суммарную сеть 192.168.0.0/16.

# /etc/swanctl/swanctl.conf
connections {
  office1 {
    version = 2
    proposals = aes256gcm16-prfsha384-ecp384
    local  { auth = psk; id = "hub.mycottage.cc"; }
    remote { auth = psk; id = "office1-router"; }
    children {
      office1 {
        local_ts = 192.168.0.0/16
        remote_ts = 192.168.1.0/24
        esp_proposals = aes256gcm16-ecp384
        start_action = start
        close_action = start
      }
    }
  }

  office2 {
    version = 2
    proposals = aes256gcm16-prfsha384-ecp384
    local  { auth = psk; id = "hub.mycottage.cc"; }
    remote { auth = psk; id = "office2-router"; }
    children {
      office2 {
        local_ts = 192.168.0.0/16
        remote_ts = 192.168.2.0/24
        esp_proposals = aes256gcm16-ecp384
        start_action = start
        close_action = start
      }
    }
  }

  office3 {
    version = 2
    proposals = aes256gcm16-prfsha384-ecp384
    local  { auth = psk; id = "hub.mycottage.cc"; }
    remote { auth = psk; id = "office3-router"; }
    children {
      office3 {
        local_ts = 192.168.0.0/16
        remote_ts = 192.168.3.0/24
        esp_proposals = aes256gcm16-ecp384
        start_action = start
        close_action = start
      }
    }
  }
}

Файл swanctl.secrets (PSK)

# /etc/swanctl/swanctl.secrets
secrets {
  ike-office1 { secret = "CHANGE_ME_LONG_RANDOM_PSK"; id = "office1-router"; }
  ike-office2 { secret = "CHANGE_ME_LONG_RANDOM_PSK"; id = "office2-router"; }
  ike-office3 { secret = "CHANGE_ME_LONG_RANDOM_PSK"; id = "office3-router"; }
}

Применение и проверка

swanctl --load-all
swanctl --list-sas

Пример успешного вывода:

office1: #1, ESTABLISHED, IKEv2
  local  'hub.mycottage.cc' @ 1.1.1.1
  remote 'office1-router' @ 2.2.2.2
  office1: #1, reqid 1, INSTALLED, TUNNEL

Маршрутизация между офисами

На роутерах и/или на VPS должны быть разрешены пересылка и маршруты между подсетями. Пример — для пары сетей.

# iptables
iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.2.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -d 192.168.1.0/24 -j ACCEPT

# nftables
nft add rule ip filter FORWARD ip saddr 192.168.1.0/24 ip daddr 192.168.2.0/24 accept

Как быстро добавить 4‑й офис (шаблон)

# Добавьте блок в /etc/swanctl/swanctl.conf
office4 {
  version = 2
  proposals = aes256gcm16-prfsha384-ecp384
  local  { auth = psk; id = "hub.mycottage.cc"; }
  remote { auth = psk; id = "office4-router"; }
  children {
    office4 {
      local_ts = 192.168.0.0/16
      remote_ts = 192.168.4.0/24
      esp_proposals = aes256gcm16-ecp384
      start_action = start
    }
  }
}

Не забудьте добавить секрет в /etc/swanctl/swanctl.secrets и правила маршрутизации/фильтрации.

  • Добавьте новый remote.id и уникальный PSK.
  • Добавьте новую LAN‑подсеть в список разрешённых traffic selectors.
  • Обновите удалённые подсети на уже подключённых роутерах, если им нужен доступ к новому офису.
  • Перезагрузите конфигурацию: swanctl --load-all, затем проверьте swanctl --list-sas.

Настройка Road‑Warrior (удалённый доступ)

Для Road‑Warrior обычно используют отдельный пул адресов (например 10.10.10.0/24) и выдают клиенту доступ к корпоративным подсетям (split‑tunnel) или ко всему интернету (full‑tunnel).

Вариант 1: сертификаты X.509 — рекомендуемый способ для рабочих установок.

# CA
pki --gen --type rsa --size 4096 --outform pem > ca-key.pem
pki --self --ca --lifetime 3650 --in ca-key.pem --type rsa \
  --dn "CN=VPN Root CA" --outform pem > ca-cert.pem

# Сертификат сервера
pki --gen --type rsa --size 3072 --outform pem > server-key.pem
pki --pub --in server-key.pem --type rsa | pki --issue --lifetime 825 \
  --cacert ca-cert.pem --cakey ca-key.pem \
  --dn "CN=hub.mycottage.cc" --san "hub.mycottage.cc" \
  --flag serverAuth --flag ikeIntermediate --outform pem > server-cert.pem

# Сертификат клиента
pki --gen --type rsa --size 3072 --outform pem > client-key.pem
pki --pub --in client-key.pem --type rsa | pki --issue --lifetime 825 \
  --cacert ca-cert.pem --cakey ca-key.pem \
  --dn "CN=user1" --san "user1" \
  --flag clientAuth --outform pem > client-cert.pem

Фрагмент swanctl.conf для сертификатов:

connections {
  rw-cert {
    version = 2
    proposals = aes256gcm16-prfsha384-ecp384
    pools = rw-pool
    local {
      auth = pubkey
      certs = server-cert.pem
      id = hub.mycottage.cc
    }
    remote {
      auth = pubkey
    }
    children {
      rw {
        local_ts = 192.168.0.0/16
        esp_proposals = aes256gcm16-ecp384
      }
    }
  }
}

pools {
  rw-pool {
    addrs = 10.10.10.0/24
    dns = 1.1.1.1
  }
}

Вариант 2: EAP/PSK — проще для теста, но слабее как долгосрочная модель доступа.

connections {
  rw-eap {
    version = 2
    proposals = aes256gcm16-prfsha384-ecp384
    pools = rw-pool
    local {
      auth = psk
      id = hub.mycottage.cc
    }
    remote {
      auth = eap-mschapv2
      eap_id = %any
    }
    children {
      rw {
        local_ts = 192.168.0.0/16
        esp_proposals = aes256gcm16-ecp384
      }
    }
  }
}

secrets {
  ike-rw { secret = "CHANGE_ME_LONG_RANDOM_PSK"; }
  eap-user1 { id = "user1"; secret = "CHANGE_ME_LONG_RANDOM_PASSWORD"; }
}

Split‑tunneling — в VPN уходит только доступ к офисным подсетям.

local_ts  = 192.168.0.0/16
remote_ts = 10.10.10.0/24

Full‑tunneling — весь трафик пользователя через VPN.

local_ts  = 0.0.0.0/0
remote_ts = 10.10.10.0/24

Практика: для iOS/macOS/Windows удобнее использовать сертификаты X.509 или EAP с длинными уникальными паролями. Для постоянного доступа сотрудников лучше вести учёт выданных сертификатов и иметь процедуру отзыва.

Вариант B: ipsec.conf / ipsec.secrets (классический)

Этот вариант удобен, если вы привыкли к ipsec.conf или переносите конфиги со старых установок. Логика та же: на хабе отдельный conn на каждый офис, а на роутере — “office‑to‑hub”.

# /etc/ipsec.conf (hub)
config setup
    uniqueids=no

conn %default
    keyexchange=ikev2
    type=tunnel
    left=1.1.1.1
    [email protected]
    leftsubnet=192.168.0.0/16
    authby=psk
    ike=aes256gcm16-prfsha384-ecp384
    esp=aes256gcm16-ecp384
    dpdaction=restart
    dpddelay=30s
    dpdtimeout=120s
    auto=add

conn office1
    right=%any
    rightid=@office1-router
    rightsubnet=192.168.1.0/24

conn office2
    right=%any
    rightid=@office2-router
    rightsubnet=192.168.2.0/24

conn office3
    right=%any
    rightid=@office3-router
    rightsubnet=192.168.3.0/24
# /etc/ipsec.secrets (hub)
@hub.mycottage.cc @office1-router : PSK "CHANGE_ME_LONG_RANDOM_PSK"
@hub.mycottage.cc @office2-router : PSK "CHANGE_ME_LONG_RANDOM_PSK"
@hub.mycottage.cc @office3-router : PSK "CHANGE_ME_LONG_RANDOM_PSK"

Применение и проверка (ipsec.conf):

systemctl restart strongswan
ipsec statusall
journalctl -u strongswan -f

Firewall на сервере (ufw/nftables)

Минимум для IKEv2: UDP 500/4500 на вход, и разрешить форвардинг между подсетями.

UFW (пример):

ufw allow 500/udp
ufw allow 4500/udp
ufw reload

# Разрешить маршрутизацию (пример: офисы 192.168.0.0/16)
ufw route allow in on eth0 out on eth0 from 192.168.0.0/16 to 192.168.0.0/16

nftables (пример FORWARD):

nft add table ip filter
nft 'add chain ip filter forward { type filter hook forward priority 0; policy drop; }'
nft add rule ip filter forward ip saddr 192.168.0.0/16 ip daddr 192.168.0.0/16 accept

Отладка и логи (команды + типичные ошибки)

  • swanctl --log — логи в реальном времени
  • journalctl -u strongswan -f
  • ip xfrm state и ip xfrm policy
  • swanctl --list-conns — список подключений
# Проверить загруженные подключения, секреты и сертификаты
swanctl --list-conns
swanctl --list-sas
swanctl --list-certs

# Смотреть события strongSwan
journalctl -u strongswan -n 200 --no-pager
journalctl -u strongswan -f

# Проверить XFRM policies/states в ядре Linux
ip -s xfrm state
ip -s xfrm policy

# Проверить UDP 500/4500 на хабе
ss -lunp | grep -E ':500|:4500'

# Быстрый tcpdump для IKE/NAT-T
tcpdump -ni any 'udp port 500 or udp port 4500'

Частые ошибки:

  • NO_PROPOSAL_CHOSEN — не совпали предложения IKE/ESP (Phase 1/2).
  • AUTHENTICATION_FAILED — неверный PSK или несовпадение ID (leftid/rightid).
  • TS_UNACCEPTABLE — не совпали подсети (traffic selectors / local_ts/remote_ts).
  • ESTABLISHED, но трафик не ходит — почти всегда firewall/маршруты/асимметрия.
  • INVALID_ID_INFORMATION — роутер ожидает другой Remote ID сервера.
  • CHILD_SA не создаётся — часто не совпадают local_ts/remote_ts или ESP proposals.
  • Туннель поднимается только после ping — проверьте start_action, DPD и auto-connect на роутере.

Чек‑лист перед запуском

  • UDP 500/4500 открыт на VPS и на офисных роутерах (если есть входящий firewall).
  • IP forwarding включён: net.ipv4.ip_forward=1.
  • Phase 1/2 совпадают на обеих сторонах (IKE/ESP proposals).
  • Подсети не пересекаются между офисами (иначе будет конфликт маршрутизации).
  • FORWARD разрешён между нужными подсетями.
  • DPD/keepalive включены, чтобы туннели поднимались после обрывов.
  • PSK длинный и уникальный (или используете сертификаты).

Ссылки на Часть 2

Когда хаб готов — переходите к настройке клиентов (роутеров) для site‑to‑site: Часть 2 → Подключение офисных роутеров.