Policy-based vs route-based VPN: что выбрать в 2026 и где не обжечься

Введение: почему выбор маршрутизации в VPN решает половину успеха

О чем спор: policy-based против route-based

Давайте начистоту: когда вы строите корпоративный VPN, самое важное решение — не только выбор шифров или вендора. Ключ в другом. Как мы поведем трафик? По политикам или через маршруты. Policy-based и route-based — два стиля, две философии. Первый опирается на правила, которые указывают, какой трафик шифровать и куда. Второй строит виртуальные интерфейсы и доверяет маршрутизатору. Звучит просто? На бумаге да, в проде — как повезет.

В 2026 году ставка высокая: гибридные облака, SASE и SD-WAN, IPv6-only сегменты и требования к наблюдаемости. Трафик скачет между филиалами, облаками, партнерами и удаленными сотрудниками. Нам нужен выбор, который выдержит рост, регуляторку и ночные апгрейды без потерь SLA. И да, давайте без телодвижений, после которых механики собирают самолет в полете.

В этой статье мы, по-честному и с примерами, разберем типы маршрутизации в VPN, объясним разницу policy-based vs route-based, покажем, где что работает лучше, а где — принесет боль. Накидаем практические рецепты настройки на популярных платформах и дадим чек-листы, чтобы вы пошли и сделали правильно с первого захода.

Почему это важно именно сейчас

Тренд 2026 года — унификация сетевой фабрики. Организации выравнивают WAN, облачные VPC/VNet и кампусы под единую политику маршрутизации, наблюдаемости и автоматизации. В этом пазле policy-based IPsec не всегда тянет динамику: E2E телеметрия, ECMP, BFD, перехват трафика для инспекции, мультиоблако с BGP over IPsec — все это легче жить в route-based архитектуре. Но! В per-app туннелях, там, где безопасность выше гибкости, policy-based до сих пор король. Мы не за одну веру, мы за прагматичный микс.

С другой стороны, рост WireGuard и QUIC-туннелей подталкивает вендоров к интерфейсно-ориентированным моделям. Даже старые киты из классического IPsec-мира больше не сопротивляются: VTI, route-based, SD-WAN fabric — это новая норма. А значит, хороший инженер обязан понимать обе стороны и эстетично комбинировать их под задачу.

Три частые ошибки, из-за которых болит голова

Во-первых, «впихнуть невпихуемое»: пытаются натянуть policy-based на дизайн, где явно просится маршрутизация и динамика. Во-вторых, «треугольник из туннелей» — строят десятки статических связей там, где BGP снял бы половину проблем за один вечер. И, наконец, третье — недооценивают MTU и MSS. VPN живет на конечной нагрузке: одна неверная настройка DF, и видеоконференции у CEO превращаются в слайд-шоу. Да, мелочи решают. Всегда.

Базовая теория: как IPsec дружит с маршрутизацией

IKE, SA и селекторы трафика

IPsec строится из двух крупных блоков: IKE (фаза обмена ключами) и собственно SA (Security Associations), которые защищают трафик. В IKEv2 мы договариваемся о шифрах, аутентификации, времени жизни. Затем формируем пары SA для каждой стороны. В policy-based сетапах селектор SA — это триада «источник, назначение, протокол/порт». И вот тут нюанс: чем больше уникальных пар и приложений, тем больше SA, тем сложнее жизнь.

Route-based раскладывает карты иначе: селектор часто становится «любой к любому» внутри туннеля, а трафик фильтруется и направляется уже политиками файрвола на интерфейсах. Это дает гибкость, особенно при динамическом маршруте и многопутевости. Селекторы перестают быть головной болью, и вы перестаете держать в голове десятки ACL для каждого нового сервиса.

SPD, SAD и политики шифрования

Чтобы понимать, что попадет в VPN, а что нет, устройство сверяется с SPD (Security Policy Database). Там хранятся правила сопоставления трафика и действий: шифровать с такими-то параметрами или пропускать в открытую. SAD (Security Association Database) хранит текущие SA — живые туннели с их SPI, ключами и сроками жизни. В policy-based модели SPD — клей, который держит конструкцию, а в route-based SPD значительно проще, ведь весь трафик, попавший на туннельный интерфейс, по умолчанию шифруется.

Звучит как победа route-based? Почти. Если у вас жесткие требования к изоляции и вы хотите, чтобы только строго определенные подсети ходили в туннель, policy-based это реализует более явно. В route-based вы достигаете того же через фильтры и ACL на интерфейсах, плюс, при необходимости, через VRF.

VTI, GRE over IPsec и почему интерфейсы правят бал

В 2026 году большинство вендоров поддерживают VTI — виртуальные туннельные интерфейсы, где вы получаете логический линк вроде point-to-point. Назначили IP, подняли OSPF или BGP, поехали. GRE over IPsec добавляет инкапсуляцию GRE внутрь шифрования для мультипротокольности и упрощения некоторых кейсов (например, мультикаст), но увеличивает накладные расходы и MTU-заботу. Чаще всего, если нет явной необходимости в GRE, VTI хватает с головой. Ваш стек становится проще, мониторинг — понятнее, а автоматика — прямолинейнее.

Policy-based VPN: суть, сильные и слабые стороны

Как строится политика: ACL, crypto map и селекторы

Policy-based VPN основан на механизме «если трафик соответствует правилу — шифруем». На практике это значит: ACL или их аналог описывает подсети источника и назначения, иногда еще и порты, протоколы. Эти правила привязываются к криптопрофилю через crypto map или похожие конструкции. В итоге каждое правило — потенциально отдельный набор SA.

Плюс подхода: четкая и прозрачная изоляция. Вам не нужно поднимать отдельный интерфейс. Нет туннельных IP, меньше поверхностной сложности. Минус: масштабирование. Как только вы хотите пустить в туннель десятки приложений, для разных зон, с асимметричными маршрутами к облакам — начинаются состыковки, которых так не любит продакшен. Правила множатся, и каждый change становится «режим без права на ошибку».

Где policy-based блистает

Есть классы задач, где этот тип маршрутизации — натурально удобен. Например, точечный обмен данными с партнером: одна или две подсети, жесткие границы, минимум динамики. Или когда у вас на периметре стоит firewall, который в основном инспектирует приложения, а туннель — вспомогательная функция. Еще кейс: высокосекьюрные зоны с принципом минимизации поверхности — никаких дополнительных интерфейсов, все под контролем строго прописанных селекторов.

Для некоторых облачных шлюзов старых ревизий policy-based по-прежнему предпочтителен, особенно если сервис-провайдер поддерживает только селекторные сценарии. Не все, но есть такие кейсы в провайдерах MPLS/VPN, где policy-based работает надежнее в их инфраструктуре.

Подводные камни и ограничения

Главный минус — гибкость. Как только вы хотите пустить динамическую маршрутизацию, сделать ECMP, применить BFD или быстро перекидывать трафик в разные облака в зависимости от SLA, policy-based будет упираться. Некоторые вендоры поддерживают псевдо-динамику и на policy-based, но это компромиссы, а не ровная дорога.

Еще одна боль — NAT и асимметрия. Если вы ставите NAT перед IPsec, есть шанс поймать рассинхронизацию селекторов. Добавьте разные MTU по разным магистралям — и получите странные «зависания» приложений. Плюс — телеметрия. Мониторить туннель как интерфейс проще, чем собирать косвенные метрики по SA и ACL. В больших сетях это прямо ощущается.

Route-based VPN: интерфейсы, динамика и масштаб

Виртуальные туннельные интерфейсы и их магия

Route-based VPN строится на туннельном интерфейсе: вы поднимаете IP на каждой стороне, и дальше — обычный роутинг. Хотите OSPF — пожалуйста. Нужен BGP — легко. Нужно несколько путей и распределение нагрузки — пожалуйста, ECMP, policy routing, PBR на интерфейсе. Подача простая: трафик, который попал на туннельный интерфейс, будет зашифрован. Селекторы перестают быть центром вселенной.

Большой плюс — стандартные инструменты диагностики. Пинг, трассировка, SNMP, потоковая телеметрия, реалистичный SLA. Вы перестаете лечить вслепую и начинаете жить как нормальный сетевой инженер: если интерфейс гуляет — ищем причину, алерты летят в NOC и SIEM.

Маршрутизация: статическая, OSPF, BGP

Статические маршруты — все еще частый выбор для небольших сетей. Но в 2026 году, если у вас больше пяти-десяти филиалов и облако, BGP over IPsec стал практически стандартом де-факто. Почему не OSPF? Он тоже годится, особенно в простых дизайн-паттернах hub-and-spoke. Но BGP гибче на границах автономных сегментов, проще в контроле путей и анонсов, стабильнее при частых изменениях. Плюс для public cloud: все крупные провайдеры здорово дружат с BGP на своих VPN-шлюзах.

Динамика нужна не ради галочки. Она даст вам быструю сходимость при сбоях, плавное добавление новых подсетей без ручного шаманства, наглядную политику предпочтений путей. И это уже не роскошь — это опора SLO/SLA, которая нужна бизнесу.

Производительность и будущее-назад

Маршрутизаторы и NGFW в 2026 умеют аппаратно ускорять AES-GCM, многие добавили ChaCha20-Poly1305 для платформ без AES-NI, и это здорово. В route-based проще вставить еще один туннель для миграций, прикрутить QoS прямо на интерфейс, применить per-tunnel SLA-проверки. Вдобавок SD-WAN, как правило, строится поверх route-based подхода: вы получаете централизованное управление, сегментацию, steering по бизнес-правилам. В policy-based все тоже достижимо, но ценой времени и нервов, особенно в смешанных средах.

Сравнение policy-based и route-based: критерии выбора

Сложность и масштабирование

Если у вас два офиса и три сервера — вероятно, policy-based будет проще в конфиге и сопровождении. Но, как только масштаб растет, route-based выигрывает. Вы не держите в голове сотни селекторов. Вы оперируете интерфейсами, маршрутами и политиками. Риск человеческой ошибки падает. Автоматизация становится доступнее. А значит — меньше ночных эскалаций.

Правило большого пальца: при наличии облака, двух и более провайдеров, требованиях к телеметрии и быстрой сходимости — route-based. При точечном партнерском обмене и строгих ограничениях — policy-based.

Безопасность и прозрачность

Policy-based изначально закрыт. Он шифрует только то, что описано. Это нравится аудиторам, а некоторые стандарты проще объяснить именно так. Route-based не менее безопасен, просто механика другая: фильтруем на интерфейсах, применяем зоны, VRF, ACL. Если ваша команда уверенно работает с firewall-политиками и сегментацией — route-based даст вам такой же уровень контроля, но с приятным бонусом масштабируемости.

Совместимость и межвендорность

В смешанных сетях с устройствами разных производителей route-based зачастую предсказуемее. Селекторы могут трактоваться по-разному, расширения IKE — тоже. Интерфейсный подход сглаживает углы, особенно при переходах на IPv6-only и BGP over IPsec. Тем не менее, есть legacy и сервис-провайдерские ограничения, где policy-based остается единственным рабочим вариантом. Тут важен здравый смысл и пилоты.

Сценарии использования и архитектуры 2026

Филиал-филиал: от простого к зрелому

Начальный уровень — policy-based между двумя точками с одной-двумя подсетями. Дешево, сердито, понятно. Средний уровень — hub-and-spoke, где филиалы строят туннели к центру. Здесь route-based выигрывает: добавляете филиал, запускаете динамику, анонсы пошли, политики на хабе все расставили. Зрелый уровень — два хаба в разных регионах, ECMP, BFD, SLA на туннеле, перехват трафика на инспекцию, QoS. Это уже почти SD-WAN, и тут route-based вне конкуренции.

Гибридное облако: AWS, Azure, GCP

Публичные облака любят route-based. AWS VGW и ускоренный GW, Azure VPN Gateway, GCP Cloud VPN — все хорошо понимают BGP. Вы поднимаете VTI, настраиваете ASN, публикуете префиксы, готово. Есть режимы policy-based, особенно в базовых SKU или при межплатформенных ограничениях, но для гибкости, DR и мультиоблака легче жить с route-based. В 2026 многие переходят на IPv6 в облачных VPC/VNet, и BGP тут — спасение для управляемого анонса префиксов.

SD-WAN, SASE и ZTNA

SD-WAN контроллеры практически всегда строят overlay на route-based туннелях, будь то собственные протоколы или IPsec под капотом. SASE, когда он интегрируется с вашим периметром, тоже опирается на туннели с интерфейсами: отгрузить метрики, балансировать трафик, применять бизнес-политику — все проще через VTI. ZTNA — другая стихия, но в гибридных схемах ему нужен backhaul в ваши сети; и там интерфейсы снова удобней. Рецепт: смешиваем. Для тонкого, рискованного трафика — policy-based, для остальной массы и управления — route-based.

Межвендорный обмен и M&A

При слияниях и поглощениях часто приходится срочно подключать сети друг друга. Если у сторон разные вендоры и политики, route-based ускоряет стыковку. Проще создать VTI, поднять BGP, ввести фильтрацию и постепенно расширять периметр. Если же безопасность требует «скальпеля», а не «ножницы», временно используйте policy-based для критically limited связей, а затем переводите в interface-based, когда пыль уляжется.

Практика настройки: популярные платформы

Cisco: ASA/FTD и IOS-XE

На ASA/FTD исторически policy-based — родной путь через crypto map и ACL. Но, начиная с новых версий, поддержка VTI позволяет делать route-based, хотя у ASA есть особенности в диагностике и управлении. Если у вас много филиалов и нужен BGP — лучше IOS-XE (ISR/ASR/Catalyst). Там VTI, IPsec profiles, DMVPN или FlexVPN — вот родная среда. Практика: для ASA оставляйте policy-based в партнерских одноточечных кейсах, а основную сеть ведите на IOS-XE с VTI и динамикой.

Шаги в общих чертах: определяем IKEv2 политику и шифры, настраиваем IPsec transform-set/пропрофиль, добавляем VTI с IP адресами, включаем IGP или BGP, применяем ACL/zone-based firewall на туннельном интерфейсе. Не забываем про MSS clamp и PMTUD.

Juniper SRX и Fortinet FortiGate

SRX традиционно силен в route-based: st0 интерфейсы, отточенная дружба с OSPF/BGP, богатый toolkit для политики. FortiGate также велик с VTI и BGP over IPsec, плюс удобные GUI-мастера, которые спасают жизнь в уставшие вечера. Policy-based на обоих поддерживается, но мы советуем использовать его там, где он осмыслен — ограниченные селекторы, партнерский обмен, небольшие проекты. Для enterprise-фабрики — однозначно интерфейсы и динамика.

Практические подсказки: на FortiGate задайте phase2 selectors как 0.0.0.0/0 при route-based, чтобы снять ограничения на трафик, и фильтруйте на политиках. На SRX следите за security zones и policy от/к st0, чтобы не пробить дыру. И включайте DPD.

MikroTik, pfSense/OPNsense, StrongSwan

MikroTik RouterOS v7 хорошо подтянул IPsec и BGP: route-based жизнеспособен, хотя нюансы интерфейсов и мониторинга еще встречаются. pfSense/OPNsense с StrongSwan дают оба подхода: policy-based через Phase 2 с конкретными сетями, route-based через VTI. Совет: если планируете облако или рост, делайте VTI, иначе потом миграция зайдет с песком в шестернях.

В StrongSwan на Linux route-based — почти дефолт: создаете туннельный интерфейс (например, xfrm или vti), поднимаете статические маршруты или BGP (FRRouting), фильтруете iptables/nftables. Для per-app защиты и минимизации поверхности держите отдельные инстансы конфигураций и селекторы в policy-based, но это точечный инструмент.

Облако: AWS, Azure, GCP

— AWS: для динамики используйте AWS Site-to-Site VPN с BGP. Если высокая производительность — Accelerated VPN или Transit Gateway, где route-based и BGP — базовая конструкция. Policy-based возможен, но для старых кейсов. — Azure: VPN Gateway (RouteBased) с поддержкой IKEv2, BGP и активным-активным режимом. PolicyBased SKU — узкоспециализирован и ограничен. — GCP: HA VPN с BGP — стандарт, Classic VPN уже в legacy-углу. Везде: делайте проверку MTU end-to-end, анонсы префиксов фильтруйте, держите аптайм за счет dual tunnels и ECMP, если доступно.

Производительность, MTU и QoS

MTU, MSS и PMTUD: мелочь, но критично

IPsec добавляет накладные расходы. VTI, GRE поверх IPsec — еще больше. На практике это значит: реальная MTU по пути уменьшается. Ошибка в DF-битах и запрете ICMP Frag Needed часто убивает большие пакеты. Рецепт: включайте PMTUD, разрешайте ICMP нужного типа, настройте MSS clamping на 1360–1380 для TCP при туннельном overhead, измеряйте фактическую безопасную MTU. И да, проверяйте с обеих сторон, иначе поймаете асимметрию.

Хорошая привычка — документировать принятые значения MTU/MSS прямо рядом с конфигурацией туннеля, чтобы через полгода никто не делал круги по тем же граблям. И держите тестовые шаблоны для проверки крупных пакетов при изменениях политики.

Криптография и ускорение

В 2026 уже почти везде ускоряются AES-GCM на аппаратных модулях. ChaCha20-Poly1305 — отличная альтернатива на устройствах без AES-NI. Выбор шифра влияет на latency и throughput. Смотрите на реальные графики: иногда переход с AES-CBC+SHA1 на AES-GCM дает 20–40 процентов выигрыша. Плюс — меньше CPU, меньше джиттера, счастливее голоса и видео.

Помните про PFS (Perfect Forward Secrecy): это не «галочка», а важная гарантированная стойкость. IKEv2 поверх IKEv1 — выбор без дискуссий. Сроки жизни SA ставьте разумными: короче — безопаснее, но не уходите в паранойю, чтобы не жечь процессор перегенерацией.

QoS и приоритизация

Route-based позволяет вешать QoS прямо на туннельный интерфейс, сохранять/переписывать DSCP, делать shaping по классам. У policy-based это сложнее и зависит от вендора. Если вы возите голос/видео через VPN — QoS must-have. Не стесняйтесь делать per-tunnel политики с SLA: потеря пакетов выше порога — переключаемся на другой линк. Это нормальная инженерия, а не «перебдели».

Отказоустойчивость и мониторинг

DPD, SLA и BFD: быстрые глаза и быстрые руки

Dead Peer Detection держит вас в курсе, жив ли пэр. Но для настоящей скорости в route-based добавьте BFD поверх туннеля и интегрируйте его с IGP/BGP. Так вы получаете сходимость за сотни миллисекунд, а не десятки секунд. IP SLA или эквивалентные пробы измеряют фактическое качество пути: задержку, джиттер, потери. Роутинг управляется не догадками, а реальными метриками.

Совет из жизни: заведите стандартные профили таймингов и порогов под типовые каналы. И автоматизируйте реакцию. Человеческий фактор нужен для анализа, не для рывков в 3 ночи.

Active-active, ECMP и многопутевость

Если провайдеры позволяют, поднимайте по два туннеля к разным точкам входа. ECMP по SLA — стандартная практика. Для критичных сервисов это снимает угрозу «одна точка отказа». В policy-based подобные схемы достижимы, но редко элегантны. В route-based вы делаете это естественно: несколько интерфейсов, веса, пробы, профили нагрузки.

Наблюдаемость: логи, потоки, телеметрия

В 2026 мы живем в мире observable networking. Логи IKE/IPsec должны лететь в SIEM, NetFlow/IPFIX с туннеля — в аналитику, метрики интерфейса — в мониторинг. Это не опция. Алерты на деградации SLA и флап туннеля — обязательны. И, да, красиво рисуйте дешборды: когда вам нужно быстро объяснить руководству, где болит, визуальная правда спасает.

Безопасность и соответствие требованиям

Современные шифры и криптоагильность

Выбирайте IKEv2, PFS, шифры уровня AES-GCM или ChaCha20-Poly1305. Откажитесь от устаревших алгоритмов. Обновляйте профили вместе с вендорными рекомендациями. Криптоагильность — способность быстро переехать на новый набор шифров — стала реальным требованием комплаенса. Документируйте, тестируйте заранее, держите план переключения.

Сертификаты вместо pre-shared keys — почти обязательны в средних и крупных сетях. PKI можно упростить через ACME или интеграцию с корпоративным CA. Это дисциплинирует и инженеров, и процессы.

Сегментация, VRF и микроизоляция

В route-based VRF — магия. Вы можете разделить туннели по VRF, навесить разные политики, ограничить маршруты. В итоге атака в одном сегменте не прольется в другой. Для policy-based похожий эффект достигается через наборы правил, но VRF проще поддерживать и объяснять. Добавьте микросегментацию на уровне NGFW, и вы получите здоровую модель «минимально необходимый доступ».

Аудит и ретроспективы

Проводите периодические ревью: какие селекторы еще нужны, какие маршруты избыточны, где политики стали слишком широкими. Сшивайте логи IKE, IPsec, firewall и BGP, чтобы видеть единую картину. Инциденты любят тишину. Не давайте им этого удовольствия. После каждого крупного change — ретроспектива и запись выводов в playbook.

Тестирование, диагностика и типовые ошибки

Чек-поинты построения туннеля

Порядок проверки прост: IKE SA есть? Отлично. Есть ли IPsec SA? Проверили ли селекторы/SPD? Пинг over туннельного интерфейса? Трассировка и видимость маршрута? Если policy-based — убеждаемся, что ACL точны, и NAT не ломает селекторы. Если route-based — проверяем компании входящие/исходящие ACL на интерфейсе и соседство IGP/BGP.

Дальше — проверка приложений. На L7 может быть сюрприз: MTU, таймауты, переподключения. Соберите шаблон «тест-скрипт» с pings, curl, iperf, наборами пакетов разных размеров. Чем меньше импровизации, тем меньше шансов пропустить мелкую, но злую проблему.

MTU, фрагментация и DF-бит

Классический грех: запретили ICMP или не учли DF, и большие пакеты тихо падают. Решение: включить PMTUD, позволить ICMP type 3 code 4, сделать MSS clamp. И проверяйте обе стороны. Помните про асимметрию: туда — 1476, обратно — 1454, и у вас не совпадает поведение приложений. Это не мистика, это физика.

NAT-Traversal и асимметричная маршрутизация

NAT-T спасает, когда один из пэров за NAT. Но отсюда и пляшут сложности: одинаковые порты, дрейф сеансов, редкие баги в прошивках. Держите прошивки свежими и включайте детальную диагностику IKE/IPsec. Асимметричная маршрутизация — отдельная боль. Половина потока шла через один туннель, половина вернулась другим — и stateful firewall отклонил ответ. Решение: проектируйте симметрию, используйте пер-туннельные политики или session synchronization в кластерах.

Автоматизация и IaC для VPN

Terraform, Ansible и GitOps

Terraform — для облаков и некоторых вендоров, Ansible — для сетевых конфигов, Git — единый источник правды. В route-based автоматизация естественнее: вы параметризуете туннельные интерфейсы, ASN, списки анонсов, SLA. В policy-based тоже можно, но управление множеством селекторов и ACL требует больше аккуратности и шаблонов.

GitOps-подход: все изменения через PR, проверка политик линтерами, автотесты на стенде, автодеплой по расписанию во внепиковое окно. Нет, это не «слишком сложно». Это дешевле первой большой аварии.

Тестирование и верификация

Паттерн «validate-before-merge»: перед попаданием изменений в прод запускаются тесты. Подымается временный туннель на стенде, проверяются BGP сессии, пинги, MTU, QoS метки. Для policy-based: соответствие селекторов дизайну, отсутствуют ли конфликты, правильно ли обработан NAT. Для route-based: корректность маршрутов, нет ли утечек в VRF, сошлась ли политика.

Секреты и безопасность автоматизации

Храните PSK и сертификаты в секрет-хранилищах (Vault, KMS, секреты Kubernetes, если у вас CNI-подход). Не кладите ключи в плэйн в репозитории. Логируйте, кто и когда менял криптополитику. И главное — планируйте ротацию ключей как регулярный процесс, а не как «как-нибудь потом».

Экономика и выбор

Лицензии, производительность и железо

Считайте честно: некоторые вендоры лицензируют VPN-туннели, пропускную способность, криптоускорение. Route-based чаще употребляет больше интерфейсных сущностей, но не обязательно дороже — зависит от платформы. Аппаратное ускорение AES-GCM экономит CPU и деньги: меньше железа для тех же SLA. В policy-based при большом числе SA дешевые платформы быстрее упираются в производительность.

Операционные затраты

Жизнь — это сопровождение. Route-based дешевле в эксплуатации в средах, где меняется топология, добавляются сети, растут облака. Мониторинг, автоматизация, однотипные шаблоны — ваш друг. Policy-based выигрывает в малых и фиксированных сценариях. Выбор — не религия, это Excel с рисками и задачами.

Расплата за неправильный выбор

Типичный кейс: компания выросла в три раза, а у нее сто policy-based туннелей с набором ACL на каждый. Любой change — минное поле. Перевод на route-based неизбежен, но делается под давлением и ночью. Можно было сэкономить месяцы, если бы изначально заложили VTI и динамику. Обратные кейсы тоже есть: включили interface-based «на все», а затем поняли, что партнер пускает только конкретные подсети — пришлось локально усложнять ACL. Золотое правило: проектируйте гибрид.

Чек-листы и best practices

Выбор архитектуры

• Есть облако и планируется рост? Выбирайте route-based, VTI, BGP.
• Точечный партнерский обмен? Policy-based с четкими селекторами.
• Нужен SLA на туннель? Route-based с IP SLA/BFD.
• Жесткие требования к сегментации? VRF + interface firewall или точечные селекторы.

Внедрение

• Определите криптополитику: IKEv2, PFS, AES-GCM/ChaCha20.
• Проверьте MTU end-to-end, включите PMTUD и MSS clamping.
• Для route-based: спланируйте ASN, фильтрацию префиксов, атрибуты BGP.
• Для policy-based: минимизируйте селекторы, избегайте порт-специфичных правил без нужды.

Эксплуатация

• Логи IKE/IPsec в SIEM, метрики интерфейсов в мониторинг, алерты на деградации.
• Периодическая ротация ключей и сертификатов, обновления прошивок.
• Автотесты после изменений, ретроспективы инцидентов и обновление плэйбуков.
• Ежеквартальный аудит маршрутов и политик доступа.

Реальные кейсы и шаблоны решений

Кейс 1: из 20 филиалов в 60 за год

Компания начинала с policy-based: два провайдера, три партнера, все просто. За год открылось 40 новых площадок и два региона в облаке. Пришлось мигрировать на route-based. Подняли по два VTI на площадку, включили BGP с communities, сделали ECMP, приоритизацию VoIP. Результат: сходимость менее секунды, гибкое добавление подсетей, минус 30 процентов инцидентов в NOC.

Кейс 2: партнер с регуляторными ограничениями

Партнер принял только policy-based с жесткими селекторами и IKE-параметрами. Решение: для этого конкретного направления оставили policy-based, для остального межофисного трафика — route-based. На периметре добавили трансляцию меток DSCP и двойную инспекцию на NGFW. Устроили общий SLA-мониторинг, провели нагрузочные тесты. Все счастливы, никто не переписывал свои стандарты.

Кейс 3: миграция IPv4-only к гибриду с IPv6

Облака и филиалы постепенно включили IPv6. На route-based VTI запустили BGP с двуми адресными семьями, аккуратно анонсировали префиксы, сохранили QoS и телеметрию. Для ленивых сервисов, которые не любили большие пакеты, подправили MSS. Переход прошел без простоя, потому что интерфейсный подход позволил жить «двумя эпохами» параллельно.

Частые ловушки и как их обходить

Слишком много селекторов

Если в policy-based список правил толстеет быстрее, чем ваши playbook — вы в зоне риска. Решение: группируйте подсети, поднимайте интерфейсные туннели, переносите фильтрацию на firewall-политики. Стройте пошаговую миграцию: сначала создайте параллельный route-based канал, затем постепенно переключайте маршруты.

Слепая зона мониторинга

В policy-based нет интерфейса — нет и очевидных метрик. Не игнорируйте это. Выделите отдельную телеметрию по SA, используйте системные логи IKE/IPsec, собирайте NetFlow до/после. Или переходите на route-based, где интерфейс — ваш лучший друг в наблюдаемости.

«Работало — и внезапно сломалось»

Чаще всего — банальный рекик ключей на одной стороне и баг в прошивке на другой, или усталый NAT-T. Обновите прошивки, включите подробную диагностику, сравните crypto-профили и lifetime. Держите матрицу совместимости по вендорам и версиям. Это скучно, но экономит бессонные ночи.

План перехода: с policy-based на route-based без боли

Поэтапная миграция

Создайте параллельные VTI, поднимите статические маршруты с более высоким административным расстоянием. Прогоните тесты, включите телеметрию. Затем переведите часть префиксов под BGP с низким risk-профилем. Убедитесь, что ACL на интерфейсах соответствуют политике безопасности. Постепенно выключайте селекторы в policy-based, не рубите с плеча.

Контроль качества

Согласуйте SLO: задержка, потери, джиттер. Пропишите, каким образом мониторинг будет отслеживать деградации. Включите BFD, если платформа поддерживает. Потренируйте фейловер специально: выключите один линк, проверьте сходимость, пороги алертов, поведение приложений. Этот «краш-тест» один раз сэкономит десятки нервных часов.

Коммуникация и документация

Задокументируйте схему, префиксы, ASN, криптополитику, MTU/MSS, контрольные команды. Поделитесь картинкой и чек-листом с командой поддержки. Назначьте окно изменений и fallback-план — иногда именно это отличает контролируемую миграцию от хаоса.

FAQ

Быстрые ответы, часть 1

• Вопрос: Что выбрать для малого офиса без облака? Ответ: Policy-based, если подсетей мало и изменений минимум. Это проще и дешевле в настройке.
• Вопрос: Что выбрать для гибридного облака с ростом? Ответ: Route-based с VTI и BGP. Даст гибкость, телеметрию и упрощенную автоматизацию.
• Вопрос: Можно ли смешивать подходы? Ответ: Да, и это нормально. Партнеров и точечные интеграции — policy-based, основной периметр — route-based.

Быстрые ответы, часть 2

• Вопрос: Что с QoS внутри IPsec? Ответ: Сохранение DSCP и политика на интерфейсе лучше работает в route-based. Policy-based зависит от вендора и сложнее.
• Вопрос: Как бороться с «зависанием» больших пакетов? Ответ: Включить PMTUD, разрешить ICMP Frag Needed, настроить MSS clamping. Проверять MTU в обе стороны.
• Вопрос: Нужен ли IKEv2? Ответ: Да. Он устойчивее, гибче и безопаснее, чем IKEv1. Плюс лучше поддерживается в облаках.

Быстрые ответы, часть 3

• Вопрос: Динамика или статические маршруты? Ответ: Для пяти сайтов статик ок. Для десятков и облака — BGP. Это уже стандартная практика.
• Вопрос: Сколько туннелей поднимать? Ответ: Минимум два на площадку, к разным пэрам/региону. Так вы получите отказоустойчивость и возможность обслуживания без простоя.
• Вопрос: Как убедить аудит? Ответ: Документируйте криптополитику, сегментацию, логи и процедуры ротации ключей. Покажите контроль доступа на интерфейсах, если используете route-based.