Site-to-Site VPN для филиалов: IPSec vs WireGuard vs IKEv2 под российские реалии

Введение: почему тема актуальна, что узнает читатель

Site-to-Site VPN для филиалов в 2026 году стал базовой тканью корпоративной сети. Офисы, ЦОДы, облака и удаленные площадки требуют защищенного канала поверх непредсказуемого интернета и операторских L3. Почему сейчас это особенно важно в России? Изменчивость маршрутизации, периодические фильтрации и DPI, разнородность провайдеров, потребность в импортозамещении и рост требований к защите персональных данных и коммерческой тайны. Это руководство сравнивает три рабочих подхода к корпоративному S2S: IPSec, WireGuard и IKEv2 (как стек IKEv2+IPSec), с акцентом на практику: архитектуры, криптопрофили, отказоустойчивость, производительность, эксплуатация, типовые ошибки и реальные кейсы.

Что вы получите: ясные критерии выбора протокола под вашу топологию и регуляторные требования, пошаговые инструкции развертывания, чек-листы для аудита готовности, рекомендации по MTU, NAT-T, BGP поверх VPN, а также фреймворк TCO и оценки рисков. Мы сознательно избегаем академической теории, концентрируясь на том, что работает в российских условиях прямо сейчас.

Основы: фундаментальные концепции (для новичков)

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

Site-to-Site VPN соединяет две или более сетей на уровне IP, позволяя хостам из филиала A обращаться к ресурсам филиала B так, как будто они в одной локальной сети или сквозь маршрутизированное ядро. Туннель инкапсулирует пакеты и шифрует их, поверх публичного интернета или канала L3.

Ключевые элементы

• Транспорт: UDP или TCP поверх IP. IPSec использует ESP и часто UDP 500/4500 (NAT-T). WireGuard использует UDP (по умолчанию 51820, но настраиваемый).
• Криптография: набор шифров, аутентификация, PFS, KDF. Упор на AEAD (AES-GCM, ChaCha20-Poly1305) для производительности и простоты.
• Управление ключами: IKEv2 для IPSec, в WireGuard — статические ключи или диспетчеры, периодическая ротация в самом протоколе.
• Маршрутизация: статические маршруты или динамические протоколы (BGP, OSPF) внутри туннеля.
• Надежность: DPD, keepalive, SLA мониторинг, резервные каналы, HA-кластеры.

Что такое IPSec, WireGuard, IKEv2

• IPSec: стек протоколов уровня сети (ESP/AH), с шифрованием и аутентификацией. Гибкий, зрелый, поддерживается в большинстве маршрутизаторов и фаерволов. Чаще всего управляется IKEv2.
• WireGuard: современный VPN-протокол на основе набора Noise (NoiseIK), работает только по UDP, минималистичен, быстрый и простой в конфигурации.
• IKEv2: протокол установления ключей и параметров безопасности для IPSec. В корпоративном контексте «IKEv2» часто означает «IPSec с IKEv2».

Российские реалии

• DPI и нестабильные маршруты: время от времени UDP-трафик может деградировать; критично иметь резерв и гибкие параметры NAT-T, а также fallback-каналы.
• Регуляторика: для защиты ПД и КИИ — организационные меры плюс технические; иногда требуются сертифицированные решения или ГОСТ-криптография.
• Импортозамещение: всё чаще выбирают open-source стэк (StrongSwan, VyOS, FRR) и российские вендоры, сохраняя совместимость через стандартные протоколы.

Глубокое погружение: продвинутые аспекты

Безопасность: криптопрофили и ротация ключей

• IPSec/IKEv2: рекомендованные шифросuites на 2026 год — AES-GCM-128/256, с PFS (DH Group 14 или 19 и выше), аутентификация по сертификатам (RSA-3072 или ECDSA P-256/P-384). Lifetime: IKE SA 8-24 часа, Child SA 1-4 часа; rekey заранее.
• WireGuard: ChaCha20-Poly1305, Curve25519, HKDF; ротация ключей по таймерам протокола и операционным регламентам; хранение приватных ключей в HSM или с защищенным доступом.

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

• Задержки: IPSec ESP на железе с AES-NI показывает предсказуемую задержку, WireGuard часто выигрывает при малых пакетах и высокой конкуренции потоков за счет компактности и упрощенного стэка.
• Оверхед: IPSec ESP добавляет 50–80 байт на пакет в зависимости от настроек, WireGuard — около 32–60 байт. Это влияет на MTU и необходимость MSS clamp.
• Пропускная способность: на x86 с AES-NI 1 ядро способно 1–3 Гбит/с IPSec AES-GCM при оптимальной настройке; WireGuard на том же CPU часто дает 2–4 Гбит/с. Результаты зависят от NIC offload, IRQ pinning и NUMA.

Надежность и отказоустойчивость

• DPD/Keepalive: для IPSec — DPD 10–15 сек, retry 3–5; для WireGuard — persistent keepalive 15–25 сек при NAT.
• Redundancy: два независимых провайдера на площадку, несколько туннелей (active-active с ECMP или active-standby), VRRP/Keepalived на пограничных узлах, BGP внутри туннелей.
• DPI/блокировки: предпочтительно UDP, но при рисках блокировок держать параллельный профиль для SSTP или TCP-обфускации для аварийного доступа к критичным сервисам.

Сетевой дизайн

• Full-tunnel против split-tunnel: чаще для филиалов используется split-tunnel: в VPN идут только корпоративные префиксы; интернет трафик локален для экономии полосы.
• Адресное пространство: избегайте пересечений RFC1918 между филиалами; планируйте блоки /24 или /23 на площадку, зарезервируйте IP для сервисов управления.
• Динамическая маршрутизация: BGP с MED/LocalPref для выбора лучшего канала; OSPF на закрытых периметрах; старайтесь избегать сложных redistribute между VRF.

Практика 1: архитектуры Site-to-Site под разные задачи

Архитектура A: Hub-and-Spoke

Центральный хаб (ЦОД или облако) соединяет десятки филиалов. Плюсы: упрощенный контроль, единая точка безопасности, сквозная аналитика. Минусы: риски SPOF, нагрузка на ядро, сложная масштабируемость без ECMP и кластеров.

• IPSec/IKEv2: зрелая схема с StrongSwan/VyOS или аппаратными шлюзами. Рекомендуется BGP на каждом spoke, анонс филиальных префиксов в хаб через два независимых туннеля.
• WireGuard: легче автоматизировать конфигурацию на десятки спиц благодаря простоте конфигов и шаблонов. Обязательно добавить контроль ключей и CMDB-инвенторизацию.

Архитектура B: Mesh частичный

Критические филиалы соединены друг с другом напрямую в дополнение к хабу. Плюсы: путь короче, меньше latency. Минусы: количество туннелей растет квадратично, требуются авто-орктестраторы.

Архитектура C: Dual-hub Active-Active

Два хаба в разных локациях, ECMP или BGP мультипасс, балансировка сессий. Тонкость: симметричная маршрутизация или session stickiness. Для IPSec — отдельные SA на каждый путь; для WireGuard — несколько peers с разными priorities.

Выбор протокола по контексту

• Максимальная совместимость с оборудованием: IPSec/IKEv2.
• Простота и скорость: WireGuard.
• Требования сертификации: IPSec с проверенными стэками или специализированные ГОСТ-VPN.

Чек-лист архитектуры

• Два независимых провайдера на хаб и на критичные филиалы.
• MTU план: 1400–1420 для VPN-интерфейса, MSS clamp 1360–1380.
• BGP внутри VPN, фильтрация префиксов, блок «0/0» от филиалов.
• Резерв управления: OOB или LTE-модем с аварийным туннелем.

Практика 2: IPSec/IKEv2 — теория, пошаговая настройка, оптимизация

Криптопрофиль

• Phase 1 (IKEv2): AES-GCM-256, PRF SHA-256, DH Group 19 (ECDH P-256), lifetime 8h, reauth enable.
• Phase 2 (Child SA): AES-GCM-256, PFS Group 19, lifetime 1–2h, replay-window 64–128.
• Аутентификация: сертификаты X.509, CRL/OCSP или короткие сроки действия сертификатов (90–180 дней) с автоматической ротацией.

Пошаговая инструкция (универсальная логика)

1. Подготовка адресации: зафиксируйте локальные и удаленные сети, избегайте пересечений. Пропишите план NAT-исключений.
2. PKI: поднимите внутренний CA, выпустите сертификаты для каждого гейтвея, настройте политики Key Usage и SAN с FQDN/IP.
3. Параметры IKE: определите шифры, lifetimes, DPD 10s. Если CG-NAT у провайдера филиала, включите NAT-T обязательно.
4. Параметры IPSec: ESP в транспортном или туннельном режиме (обычно туннельный), PFS включен, rekey заранее (например, за 10% времени до истечения).
5. Маршрутизация: статические маршруты на старте, затем внедрение BGP с соседством через адреса туннелей.
6. MTU/MSS: установите MTU 1400, включите MSS clamp на 1360 для TCP в LAN-интерфейсе.
7. Мониторинг: экспорт метрик в Prometheus/Influx, алерты на падение SA и рост retransmit.

Тонкая настройка под российские сети

• NAT-T агрессивный: при плавающем NAT и теряющихся keepalive — повысить частоту DPD, уменьшить rekey-интервалы.
• Дублирование портов: альтернативные слушающие порты UDP при наличии DPI-шаблонов; у ряда устройств допустимы нестандартные порты.
• Failover: два параллельных туннеля к разным IP хаба, ECMP или приоритет по SLA.

Фреймворк внедрения IPSec

• Пилот 1–3 филиала, нагрузка до 200 Мбит/с, сбор метрик.
• Аудит MTU/MSS/Fragmentation и корректировка.
• Переход на BGP, отказ от статик где возможно.
• Включение журналирования событий безопасности, тест инцидентов (обрыв, компрометация ключа, CA-rotate).

Практика 3: WireGuard — быстрый старт, эксплуатация, безопасность

Почему WireGuard

Стабильная работа по UDP, минимальный код, высокая скорость, простые конфиги. Идеален для массового развертывания в филиалах с Linux/RouterOS/VyOS, а также на x86-гейтах.

Пошаговая инструкция

1. Ключи: сгенерируйте пары ключей для каждого узла. Храните приватные ключи централизованно с контролем доступа.
2. Интерфейс: создайте интерфейс wg0 с адресами из отдельной подсети для туннеля (например, 10.10.0.0/24).
3. Пиры: на хабе добавьте peers всех филиалов, на филиалах — peer хаба. Разрешенный список префиксов уточните до нужных подсетей.
4. Keepalive: включите persistent-keepalive 20–25 сек, особенно за NAT.
5. Маршруты: пропишите статические или настройте BGP через FRR поверх wg-интерфейса.
6. MTU/MSS: MTU 1420, MSS clamp 1380 как стартовая точка.

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

• Контроль ключей: CMDB-инвенторизация ключей; регламенты ротации (каждые 90–180 дней) и отзыв при инцидентах.
• Доступ по принципу минимизации: ограничивайте AllowedIPs списком реальных подсетей, без 0.0.0.0/0, если не требуется full-tunnel.
• Фильтрация: на системном фаерволе фильтруйте входящий UDP к WG-порту, белые списки по источникам если возможно.

Оптимизация производительности

• CPU pinning для прерываний NIC и wg-потоков на NUMA-локальные ядра.
• GRO/LRO, RPS/RFS настройки на Linux; отслеживание drops в ethtool -S.
• Параллельные туннели для высоких скоростей, ECMP на стороне маршрутизации.

Чек-лист WireGuard

• UDP доступен на выбранном порту с обеих сторон.
• Persistent keepalive настроен для узлов за NAT.
• MTU 1420 и MSS clamp 1380 проверены трассой и тестами.
• Логи и метрики собираются (wg show, экспорт в Prometheus).

Практика 4: IKEv2 в enterprise — сертификаты, MDM, гибридные сценарии

Почему IKEv2

Стандартизован, хорошо поддерживается аппаратными и программными шлюзами, удобен для смешанных сред (Windows, iOS, Android, Linux). В S2S обычно это IPSec под управлением IKEv2, но в гибридных компаниях одна и та же PKI может обслуживать и S2S, и доступ сотрудников.

Пошаговый подход

1. PKI и политикa: создайте шаблоны сертификатов для шлюзов, включите Extended Key Usage для IPsec IKE.
2. Профили IKE: определите наборы шифров и группы DH; включите MOBIKE при необходимости мобильных сценариев.
3. Разделение ролей: S2S сертификаты отдельно от user VPN сертификатов; строгая ротация и аудит.
4. Интеграция с MDM: публикуйте профили IKEv2 для клиентских устройств, если нужен гибридный режим с удаленным доступом.

Практические советы

• CRL/OCSP: при недоступности OCSP переходите на короткоживущие сертификаты; храните CRL локально.
• Масштабирование: избегайте единого CA для всех контуров; разбивайте на Intermediate CAs по периметрам.

Практика 5: NAT, MTU, DPI — как не потерять пакеты

Диагностика MTU

1. Проведите PMTUD с DF-флагом и увеличением размера пакета, добейтесь стабильного прохождения.
2. Установите MTU на туннеле на 20–80 байт меньше максимального.
3. Настройте MSS clamp для TCP на граничных интерфейсах.

CG-NAT и нестабильный UDP

• Повышенный keepalive; дублирование туннелей на разные порты.
• При хронической деградации — резервный профиль через TCP (например, SSTP или OpenVPN TCP) для критичных сервисов, но не как основной S2S.

DPI

• Соблюдение легитимного профиля трафика, использование стандартных портов при возможности.
• Разнесение управления и данных по разным каналам, чтобы не потерять контроль.

Практика 6: Маршрутизация и HA — BGP поверх VPN

Почему BGP

Статика масштабируется плохо. BGP дает контроль путей, быстрое восстановление и предсказуемость поведения в multi-hub. Он естественно ложится на S2S как транспорт.

Пошагово

1. Loopback адреса: поднимите loopback на каждом гейте и используйте их для BGP-соседства через туннель.
2. Фильтры: объявляйте только свои префиксы; на хабе фильтруйте посторонние.
3. Политики: MED/LocalPref для приоритезации хабов; prepend для аварийных путей.
4. Failover: timers fast (hello 3s, hold 9s) при стабильной сети или BFD, если поддерживается.

HA на гейтах

• VRRP/Keepalived на паре шлюзов в филиале.
• Синхронизация конфигураций; резервный CA доступ.
• Учет асимметрии маршрутизации, особенность stateful фаерволов.

Практика 7: Наблюдаемость, эксплуатация, SLO

Метрики

• Доступность туннеля: аптайм SA или wg peer, RTO, jitter.
• Пропускная способность: p95/p99 throughput, ошибки и дропы на интерфейсах.
• Безопасность: неуспешные аутентификации, частота rekey, подозрительная динамика маршрутов.

Алертинг

• SLO: 99.9% доступности межфилиального трафика; алерт при падении ниже порога по rolling window.
• Времена восстановления: MTTR до 5 минут на филиал при наличии резервного канала.

Операционные регламенты

• Ежеквартальная ротация ключей/сертификатов.
• Тест планов DR: обрыв провайдера, компрометация ключа, выход из строя гейта.
• Инвентаризация: актуальный реестр филиалов, префиксов, ключей, контактов провайдеров.

Типичные ошибки: что НЕ нужно делать

• Одинаковые RFC1918 в разных филиалах: приводит к асимметрии и hairpin. Планируйте адресное пространство заранее.
• Отсутствие MSS clamp: фрагментация, непредсказуемые таймауты TCP.
• Слабые профили шифрования: устаревшие шифры (3DES, CBC без AEAD), отсутствие PFS.
• Единый CA на все периметры: риск домино-эффекта при инциденте.
• Мониторинг постфактум: внедряйте метрики и алерты до масштабирования.
• Непроверенный failover: резервные туннели есть, но timers, BGP и NAT-исключения не оттестированы.
• Single uplink: один провайдер на критичном узле — путь к простоям.

Инструменты и ресурсы: что использовать

Программные стеки

• IPSec/IKEv2: StrongSwan, Libreswan, VyOS, pfSense; сетевые ОС с аппаратным ускорением AES-NI.
• WireGuard: встроен в ядро Linux; поддержка на Windows, BSD, RouterOS 7, VyOS.
• Динамическая маршрутизация: FRR (BGP/OSPF), BFD при поддержке, keepalived/VRRP для HA.

Мониторинг и тестирование

• Prometheus, VictoriaMetrics, Grafana для дашбордов.
• iperf3 для throughput и jitter, hping для MTU/DF проверки.
• Packet capture на краях (tcpdump) с фильтрами по ESP/UDP портам.

Управление конфигурациями

• GitOps подход: храните шаблоны туннелей и BGP-политик в репозитории.
• Ansible для массового разворачивания; секреты в Vault.

Быстрый старт для пилотов

Для пилотных внедрений и POC, когда важны скорость запуска и гибкость платежей в РФ, на практике показывает себя vpn.how как способ быстро получить персональный VPN-сервер с выделенным IP (не shared), поддержкой WireGuard, OpenVPN, IKEv2, L2TP и SSTP — можно подобрать протокол под конкретную сеть. География серверов включает Москву, Санкт-Петербург, Амстердам, Франкфурт, Лондон, Нью-Йорк, Сан-Хосе, Чикаго, Сингапур, Сидней, Мадрид, Хельсинки, Стокгольм, Варшаву, Копенгаген, Ставангер. Принимаются карты РФ (Tinkoff, Озон), СБП и USDT/BTC. Тарифы от 490 ₽ за день и от 2490 ₽ в месяц со скидками на длительные периоды; автоматический запуск за 5 минут после оплаты и отсутствие логов позволяют быстро проверить гипотезы, не проходя долгие закупочные процедуры. Для продакшна в крупных контурах уже стоит смотреть в сторону собственной инфраструктуры или ГОСТ-совместимых решений.

Кейсы и результаты: реальные примеры применения

Кейс 1: Розничная сеть, 120 филиалов

Контекст: две витрины данных, ERP и кассовые системы. Решение: Hub-and-Spoke на IPSec/IKEv2, два хаба (Москва, СПб), BGP поверх туннелей. Параметры: AES-GCM-256, DH19, Child SA 90 минут, DPD 10с. Результат: доступность 99.94% за квартал, p95 throughput 250 Мбит/с на филиал, MTTR 4 минуты при аварии канала за счет BFD+BGP failover. Инсайт: MSS clamp 1360 устранил 80% инцидентов с фрагментацией в первые две недели.

Кейс 2: Логистика, магистральные потоки до 3 Гбит/с

Контекст: обмен телеметрией и видео между хабом и 8 площадками. Решение: WireGuard с ECMP, два провайдера на сторону, FRR BGP. Результат: суммарно до 6 Гбит/с при двух параллельных туннелях, задержки на 10–15% ниже IPSec-пилота, простая эксплуатация. Инсайт: IRQ pinning и отключение лишних offload на NIC дали +20% пропускной способности.

Кейс 3: Финтех, строгие политики

Контекст: требования к сегментации и аудиту, мультиоблако. Решение: IPSec/IKEv2 с сильной PKI, короткими сертификатами, раздельными CA на контуры PROD/NON-PROD, escrow-процедуры. Результат: успешный аудит, автоматическая ротация каждые 90 дней, ноль инцидентов компрометации за год. Инсайт: централизованный реестр туннелей и ключей с обязательным change-review снизил операционные ошибки на 60%.

Кейс 4: Производство, нестабильные провайдеры в регионах

Контекст: некоторые площадки за CG-NAT, периодические деградации UDP. Решение: WireGuard как основной, резерв через IKEv2/ISAKMP на альтернативном провайдере; для самых проблемных — аварийный SSTP профиль только для управления. Результат: сведение простоев к 0.3% в месяц, RTO восстановления 2–3 минуты. Инсайт: агрессивные keepalive и разделение управления/данных устранили ложные срабатывания мониторинга.

FAQ: 7–10 глубоких вопросов

1. Что выбрать для сети в 10–20 филиалов с ограниченной ИТ-командой?

WireGuard даст простоту и скорость внедрения, особенно если оборудование — x86/VyOS/RouterOS. Если требуется совместимость с разнородными фаерволами и регламенты, выбирайте IPSec/IKEv2.

2. Какой MTU ставить по умолчанию?

Стартовые значения: IPSec 1400, WireGuard 1420, MSS clamp 1360–1380. Затем эмпирически откалибруйте по PMTUD и анализу фрагментации.

3. Можно ли смешивать WireGuard и IPSec/IKEv2?

Да. Часто используют WireGuard для bulk-трафика и IPSec/IKEv2 для совместимости или резервирования. Ключ — согласованная маршрутизация и приоритеты BGP.

4. Насколько безопасен WireGuard без IKE?

WireGuard безопасен по современным стандартам, использует надёжные примитивы. Риск не в протоколе, а в операционной дисциплине: управление ключами, минимизация AllowedIPs, своевременная ротация.

5. Что с DPI и блокировками UDP в РФ?

Точечные случаи встречаются. Держите резерв: альтернативные порты, параллельный туннель через другого провайдера, аварийный TCP-профиль только для управления.

6. Когда нужен BGP, а когда хватит статик?

До 5–7 филиалов и без сложной отказоустойчивости хватит статик. Выше — BGP снижает операционные риски и ускоряет восстановление.

7. Как планировать производительность?

Оцените пиковый и p95 трафик, заложите 30–50% запас на CPU и uplink, учитывайте offload и NUMA. Для IPSec — проверьте AES-NI, для WireGuard — планируйте параллельные туннели при гигабитных нагрузках.

8. Какие требования для ПДн и КИИ?

VPN — лишь часть картины. Нужны организационные меры, сегментация, журналирование, управление доступами. При требованиях сертификации рассматривайте сертифицированные решения или ГОСТ-криптографию.

9. Как часто ротировать ключи и сертификаты?

Практика: ключи и сертификаты каждые 90–180 дней, автоматизировано. При инцидентах — немедленная замена и отзыв.

10. Можно ли поверх VPN строить multicast/VoIP?

Да, но учитывайте MTU, jitter, QoS. Часто предпочтительнее SRTP по отдельному профилю и приоритизация на WAN.

Заключение: резюме и следующие шаги

В российских реалиях рабочими остаются два основных технологических столпа Site-to-Site: IPSec/IKEv2 как универсальный стандарт и WireGuard как лёгкий и производительный инструмент. Выбор не бинарный: в зрелых сетях уместен гибрид, где под конкретную площадку и трафик выбирается оптимальный профиль. Ключ к успеху — дисциплина сети: продуманное адресное пространство, BGP поверх туннелей, корректные MTU/MSS, отказоустойчивость на уровне каналов и гейтов, наблюдаемость и регламентированная безопасность. Начните с пилота: 2–3 площадки, метрики, нагрузка, аварийные тесты. Обкатайте профили, затем масштабируйтесь с GitOps и CMDB. Для быстрых POC и гипотез подойдет персональный сервер у провайдера, наподобие описанного ранее сервиса, а для продакшна — собственные кластеры или сертифицированные решения. Принципиально: не откладывайте наблюдаемость и тесты DR, а криптопрофили и ключи держите в железной дисциплине. Тогда VPN перестанет быть «black box» и станет предсказуемой магистралью вашего бизнеса.