Как объединить дом
и офис в одну сеть

← К списку статей

Что такое Site-to-Site VPN

Site-to-Site VPN — это постоянный зашифрованный туннель между двумя или несколькими локальными сетями. Например, дом на 192.168.10.0/24 и другой объект на 192.168.11.0/24 начинают работать так, будто между ними есть частный защищённый канал.

В отличие от обычного “VPN-клиента на ноутбуке”, здесь подключается не один пользователь, а целая сеть за роутером. Пользователям не нужно запускать отдельную программу: шифрование делает VPN-шлюз — strongSwan, MikroTik, Keenetic, Omada, pfSense, OpenWRT или другой роутер.

Как работает туннель

1. Роутер объекта инициирует IKEv2-сессию к публичному адресу хаба или второго роутера.
2. Стороны проверяют идентификаторы: Local ID и Remote ID.
3. Происходит аутентификация: по PSK или сертификатам X.509.
4. Согласуются алгоритмы шифрования и traffic selectors: какие подсети разрешено передавать через туннель.
5. После установки CHILD SA трафик между LAN-сетями шифруется и идёт через IPsec.

Что происходит внутри IPsec

В site-to-site сценарии IPsec обычно работает в туннельном режиме: исходный IP-пакет целиком помещается внутрь нового защищённого пакета. Это режим для связи двух частных LAN через публичный интернет. Транспортный режим чаще используют для защиты связи между двумя конкретными узлами, а не между сетями.

В практической настройке чаще всего встречаются три термина:

• IKE — договаривается о параметрах, аутентифицирует стороны и создаёт служебный защищённый канал.
• ESP — шифрует полезный трафик и защищает его целостность. Для site-to-site это основной рабочий механизм.
• SA — Security Association, набор согласованных параметров: алгоритмы, ключи, время жизни и направление трафика.

AH тоже относится к IPsec, но в современных site-to-site VPN его используют редко: он не шифрует данные и хуже дружит с NAT. Для нашей схемы ориентируемся на IKEv2 + ESP.

IKEv2 по шагам: IKE_SA_INIT, IKE_AUTH, CHILD SA

1. IKE_SA_INIT — стороны выбирают криптографические параметры и выполняют обмен Diffie-Hellman. На этом этапе формируется базовый материал для будущих ключей.
2. IKE_AUTH — стороны подтверждают свою подлинность: по PSK, сертификатам или EAP. Если ID/PSK не совпали, в логах обычно появляется AUTH_FAILED.
3. CHILD SA — создаётся рабочая IPsec SA для передачи данных. Именно здесь важны local_ts и remote_ts, потому что они определяют, какие подсети реально пойдут в туннель.

Для NAT Traversal IKEv2 использует UDP 4500. Поэтому на VPS и роутерах важно открыть UDP 500 и UDP 4500, а не только web-порты 80/443.

Когда нужен Site-to-Site VPN

• Несколько домов или офисов: камеры, NAS, контроллеры умного дома, серверы и рабочие станции доступны между площадками.
• Центральный хаб: VPS принимает подключения от объектов и связывает подсети между собой.
• Безопасный удалённый доступ: не надо открывать web-интерфейсы устройств наружу.
• Инженерные системы: BMS, KNX, Wiren Board, NVR, IP-камеры и контроллеры работают через закрытый канал.

Hub-spoke или full mesh

Для двух объектов можно сделать прямой туннель “роутер-роутер”. Но когда объектов становится три, четыре, пять и больше, удобнее использовать hub-spoke: один центральный хаб на VPS и отдельный туннель от каждого объекта к хабу.

Какие параметры нужны заранее

Перед настройкой лучше собрать маленькую таблицу. Это экономит часы отладки.

• Название объекта: например Office 1.
• Remote ID объекта: тот же ID должен быть указан на роутере как Local ID.
• LAN-подсеть: например 192.168.10.0/24.
• Public IP или DDNS: если объект должен принимать входящие подключения. Для spoke-роутеров часто достаточно %any на хабе.
• PSK или сертификат: общий секрет для теста или X.509 для продакшена.
• Remote subnets на роутере: сети, куда объект должен ходить через VPN.

PSK удобен для теста. В продакшене рекомендуется переход на сертификаты X.509 или хотя бы уникальный длинный PSK для каждого объекта.

Traffic selectors: почему это важно

В IPsec есть понятие traffic selectors. В strongSwan/swanctl это параметры local_ts и remote_ts. Они говорят, какие подсети можно передавать через конкретный CHILD SA.

Пример для хаба:

connections {
  site-office1 {
    version = 2
    local_addrs = %any
    remote_addrs = %any
    local  { auth = psk; id = "vpn.example.com"; }
    remote { auth = psk; id = "office1-router"; }
    children {
      net {
        local_ts = 10.0.0.0/24,192.168.11.0/24,192.168.12.0/24
        remote_ts = 192.168.10.0/24
        esp_proposals = aes256-sha256-modp2048
        start_action = trap
      }
    }
  }
}

На роутере Office 1 это должно быть зеркально: локальная подсеть 192.168.10.0/24, удалённые подсети 10.0.0.0/24, 192.168.11.0/24 и 192.168.12.0/24.

Firewall forwarding и NAT

Самая частая ситуация: туннель поднят, но устройства не открываются. На хабе часто забывают разрешить пересылку между VPN-подсетями. Для UFW это именно route allow, а не обычный allow.

sysctl -w net.ipv4.ip_forward=1
ufw route allow from 192.168.11.0/24 to 192.168.10.0/24
ufw route allow from 192.168.10.0/24 to 192.168.11.0/24

NAT для site-to-site обычно не нужен. Лучше маршрутизировать настоящие подсети как есть. NAT может скрыть источник, запутать диагностику и сломать доступ к некоторым устройствам.

Когда вспоминают GRE/IPsec

Иногда поверх IPsec добавляют GRE. Это нужно не всем: GRE полезен, когда требуется передавать multicast/broadcast, строить динамическую маршрутизацию или создавать отдельный туннельный интерфейс поверх защищённого канала. Сам GRE не шифрует трафик, поэтому его используют вместе с IPsec.

Для обычной связки “дом ↔ хаб ↔ дом” GRE чаще всего не нужен. Проще и надёжнее начать с чистого IKEv2/IPsec site-to-site, а GRE рассматривать позже, если появится реальная задача по динамической маршрутизации или multicast.

Безопасность

• Используйте IKEv2, а не устаревшие схемы IKEv1.
• Открывайте наружу только UDP 500/4500 для IPsec, а админки устройств держите внутри VPN.
• Для каждого объекта делайте отдельный PSK или отдельный сертификат.
• Не используйте пересекающиеся подсети: 192.168.1.0/24 на двух объектах почти всегда создаст проблемы.
• Включайте логи и мониторинг: swanctl --list-sas, journalctl, счётчики трафика.

Типовые ошибки и быстрые проверки

Команды диагностики strongSwan

swanctl --list-conns
swanctl --list-sas
swanctl --load-all
journalctl -u strongswan --no-pager -n 100
tcpdump -ni any udp port 500 or udp port 4500

Мини-чек-лист перед запуском

1. Все LAN-подсети уникальны и не пересекаются.
2. На хабе local id совпадает с Remote ID на роутере.
3. На роутере Local ID совпадает с remote.id в strongSwan.
4. PSK длинный, уникальный и одинаковый с обеих сторон.
5. UDP 500/4500 доступны до хаба.
6. Traffic selectors зеркальные.
7. На хабе разрешён forwarding между нужными подсетями.
8. У конечных устройств правильный gateway и нет локального firewall-запрета.