Как в современных реалиях организовать межсетевой (site-to-site) VPN с учётом актуальных технологий и требований безопасности?

Коротко по сути и с учётом реалий 2026 года.

1) Может ли «ТСПУ» различать обычный site‑to‑site VPN и «VPN для обхода блокировок»?
- Если под ТСПУ вы имеете в виду средства провайдеров/регуляторов — DPI, TLS/QUIC‑фингерпринты и прочие системы фильтрации — то они обычно:
  - надёжно распознают конкретные протоколы (IPsec/ESP, классические WireGuard‑заголовки, OpenVPN, QUIC и т. д.) по структуре пакетов и отпечаткам;
  - смотрят на порт/сертификаты/SNI, адреса назначения, поведение сессии, статистику (время, объём, паттерны) и могут блокировать/ограничивать по этим признакам.
- Что они не могут сделать на уровне пакетов — это достоверно определить «намерение» (легитимный корпоративный туннель или цель обхода блокировок). Намерение можно лишь предполагать по контексту (назначение целевых IP, совпадение с известными сервисами обхода, использование публичных прокси и т. п.).
- Итого: протоколы распознают; цель — нет. Но распознавание само по себе даёт основание для блокировки/фильтрации.

2) Какие сегодня практичные варианты для site‑to‑site VPN (с учётом безопасности и надёжности)
Ниже — краткое сравнение с рекомендациями.

- IPsec (IKEv2) — «классика», аппаратная поддержка, хорошо подходит для корпоративных S2S:
  - Плюсы: зрелый стандарт, поддержка на маршрутизаторах/фаерволах, NAT‑T; сильные алгоритмы (AES‑GCM, ChaCha20‑Poly1305), сертификаты/PSK.
  - Минусы: ESP легко обнаруживается DPI; настройка сложнее, особенно при динамических IP; возможны проблемы с NAT.
  - Когда выбирать: если нужны HA/политики/интеграция с оборудованием (Cisco, Juniper, MikroTik, pfSense/OPNsense и т. п.).

- WireGuard — простой, быстрый, небольшой код:
  - Плюсы: высокая производительность, простая конфигурация, NAT traversal работает, хорошо для туннелей между роутерами/инстансами.
  - Минусы: стандартный WireGuard имеет узнаваемый заголовок/паттерн и может быть задет DPI; «стандартный» не маскирует себя как HTTPS.
  - Когда выбирать: когда нужна скорость и простота, можно использовать стандартный WG для прозрачных site‑to‑site и управлять динамическими IP через DDNS или менеджмент.

- WireGuard over QUIC / WireGuard over TLS (и VPN over QUIC)
  - Плюсы: трафик маскируется под широко используемый TLS/QUIC (HTTP/3), сложнее отличить от обычного HTTPS/QUIC; QUIC даёт лучшее поведение через NAT и при потере пакетов.
  - Минусы: требует более новых реализаций/стека; может потребоваться сертификат от CA; продвинутые DPI всё равно могут заметить аномалии QUIC‑потока.
  - Когда выбирать: если хотите «заставить» туннель выглядеть как обычный HTTPS/QUIC (уменьшить шанс блокировки по протоколу).

- OpenVPN / OpenConnect (AnyConnect) поверх TLS
  - Плюсы: хорошо известные средства, можно запускать на TCP/443, TLS 1.3, легче «маскировать» под HTTPS; OpenConnect совместим с Cisco AnyConnect.
  - Минусы: OpenVPN имеет узнаваемые отпечатки, хотя их можно снижать; производительность ниже WG/IPsec.
  - Когда выбирать: совместимость/маскировка важнее throughput.

- Managed / SD‑WAN / Cloud‑VPN (Cisco SD‑WAN, VMware SD‑WAN, AWS/Azure VPN, Tailscale/ZeroTier)
  - Плюсы: упрощённое управление, маршрутизация, QoS, мониторинг; Tailscale/ZeroTier удобны для быстрого соединения через NAT.
  - Минусы: коммерческие зависимости (контрольная плоскость у вендора), возможные юридические/регуляторные нюансы при использовании зарубежных сервисов; ZeroTier/Tailscale‑протоколы тоже детектируются DPI.
  - Когда выбирать: много веток, нужно централизованное управление и оптимизация трафика.

3) Практические рекомендации, ориентированные на безопасность и надёжность
- Для бизнеса: предпочтительнее IPsec IKEv2 на железных фаерволах/маршрутизаторах или мощных маршрутизаторах с поддержкой HA. Сертификатная аутентификация, современные шифры (AES‑GCM/ChaCha20‑Poly1305), сильные группы DH (X25519), регулярная ротация ключей.
- Для высокой производительности и простоты: WireGuard site‑to‑site. Комбинируйте с автоматикой для обновления/мониторинга и политиками доступа.
- Для минимизации шансов блокировки: использовать туннель поверх TLS1.3/QUIC (валидный сертификат от доверенного CA, ALPN соответствующий http/3) — это делает туннель похожим на обычный HTTPS/QUIC. Учтите, что некоторые DPI умеют фингерпринтить TLS/QUIC.
- Для динамических IP и NAT: используйте NAT‑T (IPsec), keepalive, динамический DNS, либо решения типа Tailscale/headscale, которые упрощают NAT traversal.
- Жесткая сегментация: в site‑to‑site пробрасывайте только нужные подсети/порты. Не делайте «всё в туннель» без необходимости.
- Логирование и мониторинг: NetFlow/IPFIX, метрики VPN (управление сессиями, реки), контроль MTU/Path MTU. Настройте алерты на резкие изменения трафика.
- Безопасность управления: доступ к роутерам/фаерволам по защищённым каналам (SSH с ключами, двухфакторная аутентификация), ограниченный доступ по IP.
- Юридические и регуляторные аспекты: в РФ существует регуляция того, что запрещено скрывать трафик, и требования к операторам. Проконсультируйтесь с юристом по поводу использования обфускации/заглушки протоколов и использования зарубежных управляющих сервисов.

4) Конкретный выбор — что посоветовать вам
- Небольшая инфраструктура, упор на скорость и контроль: WireGuard S2S + DDNS + firewall rules.
- Корпоративный подход, аппаратная надежность и интеграция: IPsec IKEv2 на фаерволах (MikroTik/VyOS/pfSense/Cisco).
- Быстро, без настройки проброса портов, с удобным менеджментом: Tailscale (если устраивает модель контроля плоскости) либо headscale (self‑host) + WireGuard.
- Если нужно снизить риск блокировки протокола: туннель поверх TLS/QUIC (реализация — OpenVPN3/OCserv с TLS1.3 или WG‑over‑QUIC), но учитывайте законность и сложность поддержки.

5) Что я могу сделать дальше для вас
- Помочь подобрать вариант по вашим требованиям (пропускная способность, динамика IP/статические, доступность оборудования, требование по маскировке трафика, политика логов и соответствие регуляции).
- Прислать примерную конфигурацию (пара конфигов для pfSense/MikroTik/VyOS/ WireGuard) если укажете модель оборудования и желаемый протокол.
- Описать пошагово развёртывание site‑to‑site на выбранном стеке.

Если хотите — скажите: какие скорости/подсети, статические ли IP у концов, важна ли «нескрываемость» туннеля (т. е. не выглядеть как обход блокировок), и есть ли предпочтения по оборудованию/бюджету.

у нас в аналогичном случае (два офиса, разные города рф) взяли AmneziaWG — обфусцированный WireGuard, специально под российские реалии. ТСПУ режет по сигнатуре, не по конечному IP, так что "внутрироссийский" не значит "гарантированно работает". IPSec/IKEv2 пока держится лучше классики, но AmneziaWG надёжнее на перспективу.

Внутрироссийский VPN трафик по моему наблюдению ходит нормально. И c OpenVPN и IPSeec я лично проблем не вижу.

С проблемой блокировки vpn внутри РФ не сталкивался. Кемерово, Анапа, Чегдомын (поселок такой, где-то в Хабаровском крае), Москва - командировочные цеплялись отовсюду. IPSec. А вот в Казахстане уже гарантированно не работает. Про РБ не скажу ничего, пока туда никого не заносило.

Прелесть опен впн в том, что он работает по TCP, a ssh не блочат. <br/> Значит, ssh -D и опен впн клиент через проксю. <br/> Или просто туннелированием через флаг -L <br/> <br/> В конце концов грубо говоря можно всегда поэкспериментировать, потому что в влесс модно завернуть что угодно. Но я думаю если не сработает, тебе хватит обычного ssh <br/> <br/> Ну или в крайнем случаи использовать udp 2 raw. Оно умеет инкасапулировать по ICMP))) <br/> <br/> -------- <br/> Посыл моего данного ответа, что если один протокол туннелирования работает, но своим фукционалом не удовлетворяет поставленной задачи, то всегда можно завернуть один в другой(инкасапуляция)

Можно использовать, например, IPIP.