IPsec-туннель для офиса: настройка strongSwan site-to-site

Сети и VPN
IPsec-туннель для офиса: настройка strongSwan site-to-site

IPsec-туннель между офисами — классический способ объединить локальные сети нескольких площадок в одну защищённую инфраструктуру: бухгалтерия в филиале видит сервер 1С в головном офисе, принтеры и файловые шары доступны отовсюду, а весь трафик между площадками шифруется. Проблема в том, что напрямую офисы соединить часто нельзя: провайдеры выдают серые IP за NAT, а статический белый адрес стоит денег и есть не везде. Решение — арендовать недорогой VPS с выделенным IPv4 и сделать его центральным узлом (hub), к которому офисы подключаются сами. В этой инструкции настроим site-to-site IPsec на strongSwan под Ubuntu 24.04 LTS.

Схема: VPS как центр звезды

Топология hub-and-spoke выглядит так:

  • VPS (hub) — публичный IPv4, например 203.0.113.10. Принимает подключения и маршрутизирует трафик между офисами.
  • Офис A (spoke) — сеть 192.168.10.0/24, шлюз — Linux-машина или роутер с поддержкой IKEv2.
  • Офис Б (spoke) — сеть 192.168.20.0/24, аналогичный шлюз.

Оба офиса инициируют IKEv2-подключение к VPS. Благодаря NAT-Traversal (UDP 4500) туннели работают, даже если офисы сидят за провайдерским NAT. Пакет из сети A в сеть Б проходит через VPS в зашифрованном виде: ESP-туннель A→VPS, затем VPS→Б.

Важное условие: подсети офисов не должны пересекаться. Если в обоих офисах стоит стандартная 192.168.1.0/24 — перенумеруйте одну из сетей заранее, иначе маршрутизация не заработает.

Что понадобится

  1. VPS с Ubuntu 24.04 и выделенным IPv4. Подойдёт тариф Pro у Cheap-Host (750 ₽/мес: 12 vCPU, 16 ГБ RAM, NVMe, безлимитный трафик) — Intel Xeon с AES-NI шифрует IPsec-трафик практически без нагрузки на CPU, а канала 100 Мбит/с хватает для файловых шар и 1С нескольких офисов. Сервер выдаётся за 45–60 секунд, IP — сразу.
  2. По одной Linux-машине (или роутеру с IKEv2) в каждом офисе в роли шлюза.
  3. Root-доступ везде и 30–40 минут времени.

Базовую подготовку сервера — SSH-ключи, обновления, файрвол — мы разбирали в статьях «Первые 10 шагов после покупки VPS» и «Настройка файрвола UFW». Здесь считаем, что сервер уже обновлён и защищён.

Шаг 1. Установка strongSwan на Ubuntu 24.04

На VPS и на обоих офисных шлюзах ставим strongSwan с современным интерфейсом управления swanctl:

sudo apt update
sudo apt install -y strongswan strongswan-swanctl charon-systemd
sudo systemctl enable --now strongswan

В Ubuntu 24.04 демон работает как systemd-служба strongswan.service, а конфигурация живёт в /etc/swanctl/. Старый формат ipsec.conf считается устаревшим — используем только swanctl.

Шаг 2. Форвардинг и firewall

VPS должен пересылать пакеты между туннелями. Включаем форвардинг постоянно:

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-ipsec.conf
sudo sysctl -p /etc/sysctl.d/99-ipsec.conf

IPsec использует UDP 500 (IKE) и UDP 4500 (NAT-Traversal). Открываем их в UFW на VPS:

sudo ufw allow 500/udp
sudo ufw allow 4500/udp

Если UFW включён, разрешите также форвардинг между офисными подсетями:

sudo ufw route allow from 192.168.10.0/24 to 192.168.20.0/24
sudo ufw route allow from 192.168.20.0/24 to 192.168.10.0/24

На офисных шлюзах открывать входящие порты не нужно — они сами инициируют соединение наружу.

Шаг 3. Конфигурация hub на VPS

Создаём файл /etc/swanctl/conf.d/offices.conf. Для каждого офиса — своё соединение и свой PSK:

connections {
    office-a {
        version = 2
        local_addrs = 203.0.113.10
        proposals = aes256-sha256-modp2048
        local {
            auth = psk
            id = hub
        }
        remote {
            auth = psk
            id = office-a
        }
        children {
            to-office-a {
                local_ts = 192.168.20.0/24
                remote_ts = 192.168.10.0/24
                esp_proposals = aes256gcm16
                start_action = trap
                dpd_action = clear
            }
        }
    }
    office-b {
        version = 2
        local_addrs = 203.0.113.10
        proposals = aes256-sha256-modp2048
        local {
            auth = psk
            id = hub
        }
        remote {
            auth = psk
            id = office-b
        }
        children {
            to-office-b {
                local_ts = 192.168.10.0/24
                remote_ts = 192.168.20.0/24
                esp_proposals = aes256gcm16
                start_action = trap
                dpd_action = clear
            }
        }
    }
}

secrets {
    ike-office-a {
        id = office-a
        secret = "ДЛИННЫЙ_СЛУЧАЙНЫЙ_КЛЮЧ_ОФИСА_A"
    }
    ike-office-b {
        id = office-b
        secret = "ДРУГОЙ_ДЛИННЫЙ_КЛЮЧ_ОФИСА_Б"
    }
}

Обратите внимание на трафик-селекторы: в соединении с офисом A локальной сетью хаба объявлена сеть офиса Б (local_ts = 192.168.20.0/24) и наоборот. Именно это позволяет офисам ходить друг к другу через VPS. Ключи генерируйте командой openssl rand -base64 32 — отдельный для каждой площадки.

Применяем конфигурацию:

sudo swanctl --load-all

Шаг 4. Конфигурация офисных шлюзов

На шлюзе офиса A создаём /etc/swanctl/conf.d/tunnel.conf:

connections {
    to-hub {
        version = 2
        remote_addrs = 203.0.113.10
        proposals = aes256-sha256-modp2048
        local {
            auth = psk
            id = office-a
        }
        remote {
            auth = psk
            id = hub
        }
        children {
            office-net {
                local_ts = 192.168.10.0/24
                remote_ts = 192.168.20.0/24
                esp_proposals = aes256gcm16
                start_action = start
                dpd_action = restart
                close_action = start
            }
        }
    }
}

secrets {
    ike-hub {
        id = office-a
        secret = "ДЛИННЫЙ_СЛУЧАЙНЫЙ_КЛЮЧ_ОФИСА_A"
    }
}

start_action = start поднимает туннель сразу при загрузке, dpd_action = restart и close_action = start автоматически переподключают его после обрывов связи. На шлюзе офиса Б конфигурация зеркальная: id = office-b, local_ts = 192.168.20.0/24, remote_ts = 192.168.10.0/24 и свой PSK.

Не забудьте включить ip_forward и на офисных шлюзах, а на остальных компьютерах офиса прописать маршрут к чужой подсети через шлюз (или сделать шлюз default gateway). Загружаем: sudo swanctl --load-all.

Шаг 5. Проверка и отладка

Смотрим активные соединения на VPS:

sudo swanctl --list-sas

В выводе должны быть оба туннеля в состоянии ESTABLISHED с установленными CHILD_SA. Проверяем связность из офиса A (с машины в сети 192.168.10.0/24):

ping 192.168.20.1

Если пинг не идёт, диагностируем по порядку:

  • Туннель не поднимается — смотрите журнал: sudo journalctl -u strongswan -f. Ошибка AUTHENTICATION_FAILED почти всегда означает несовпадение PSK или id.
  • SA есть, пинга нет — проверьте ip_forward на VPS и правила UFW route. Счётчики пакетов видны в swanctl --list-sas: если байты растут только в одну сторону, проблема на обратном пути.
  • Туннель падает через минуты — за NAT провайдера включите keepalive: параметр keyingtries = 0 в connections и проверьте, что UDP 4500 не режется.
  • Пингуется шлюз, но не компьютеры за ним — на машинах офиса нет маршрута в удалённую подсеть, либо мешает локальный файрвол Windows.

Производительность и ресурсы

IKEv2 с aes256gcm16 использует аппаратные инструкции AES-NI, поэтому даже поток в 100 Мбит/с загружает одно ядро Xeon на единицы процентов. Реальные ограничители — канал и задержка до VPS. Для офисов в России логично взять сервер в Москве: пинг 5–30 мс по стране против 40–80 мс до Европы. Как измерить задержку заранее, мы разбирали в статье «Как проверить пинг и скорость VPS».

Тот же VPS-хаб можно использовать шире: поднять на нём WireGuard для удалённых сотрудников — они получат доступ в обе офисные сети через уже настроенную маршрутизацию. Благодаря безлимитному трафику у Cheap-Host считать гигабайты между офисами не придётся, а при росте нагрузки CPU и RAM апгрейдятся без переустановки и потери данных.

FAQ

Почему туннель через VPS, а не напрямую между офисами?

У офисов часто нет статических белых IP — провайдеры выдают серые адреса за NAT. VPS с выделенным IPv4 становится стабильной точкой встречи: офисы сами инициируют подключение к нему, и белые адреса в офисах не нужны.

Какой VPS нужен для IPsec-туннеля на 2–3 офиса?

Шифрование AES-GCM аппаратно ускоряется на Intel Xeon, поэтому хватит среднего тарифа: Pro у Cheap-Host — 12 vCPU, 16 ГБ RAM, безлимитный трафик за 750 ₽/мес. Запас ресурсов пригодится под мониторинг или VPN для сотрудников.

PSK или сертификаты — что выбрать?

Для 2–5 площадок PSK проще и достаточно надёжен при длинном случайном ключе (32+ символа, отдельный на каждый офис). Сертификаты оправданы при десятках площадок или требованиях регуляторов.

Чем IPsec лучше WireGuard для связи офисов?

IPsec — отраслевой стандарт, который понимают аппаратные роутеры (MikroTik, Keenetic, Cisco), часто уже стоящие в офисах. Если обе стороны — Linux-серверы и совместимость с железом не нужна, WireGuard проще; сравните сами по нашей инструкции по OpenVPN и WireGuard.

Вывод

Site-to-site IPsec через VPS решает задачу объединения офисов без статических IP на площадках: strongSwan ставится за пару минут, вся логика — два конфига swanctl, а обрывы связи туннель переживает автоматически. Если для этой задачи вам нужен сервер — у Cheap-Host тариф Pro от 750 ₽/мес: KVM с полным root, NVMe, выделенный IPv4, безлимитный трафик и выдача сервера за минуту. Вопросы по настройке можно задать поддержке 24/7 — support@cheap-host.onl.

Читайте также