Содержание статьи

Зачем IPsec в 2026: контекст и задачи

Традиционные VPN против современных угроз

IPsec пережил десятки модных технологий и всё ещё держит планку. Почему в 2026 мы не списываем его со счетов? Потому что протокол даёт нам то, что любят безопасники и админы: чёткую криптографическую модель, совместимость между вендорами и гибкость на уровне политики. Появились SASE и ZTNA, да и TLS-базовые туннели набрали обороты, но когда речь о шифровании IP-трафика от ядра до ядра, IPsec закрывает задачу без лишних танцев с бубном. Он работает в ядрах ОС, дружит с аппаратным ускорением, и это чувствуется на пропускной способности. Реальность такова: угрозы выросли, а бюджеты не всегда поспевают. Здесь IPsec спасает тем, что хорошо документирован, опирается на стандарты и позволяет строить системы с предсказуемым поведением. Нужна строгая политика, аутентификация хостов и надёжные ключи? Это его стихия.

Что мы видим на практике в 2026? Растёт доля гибридных сетей, где филиалы, дата-центры и облака сшиваются в единое защищённое пространство. IPsec выступает как скелет такой архитектуры. Плюс к этому растёт чувствительность к задержкам и стоимости транспорта. VPN поверх публичного интернета с IPsec часто выигрывает у MPLS по гибкости и цене при грамотном QoS и правильной развёртке. Мы также видим тренд на аппаратные NIC с offload IPsec, DPU и SmartNIC — скорость без компромиссов. И ещё один момент: регуляторы. Когда нужно показать аудиторам прозрачность и зрелость криптографии, IPsec даёт понятный набор артефактов — от параметров SA до журналов IKE.

Где IPsec незаменим сегодня

Есть сценарии, где IPsec буквально незаменим. Межфилиальные туннели с маршрутизацией на уровне ядра, когда мы хотим чтобы приложения не знали о туннеле. Поддержка IPv6 end-to-end без прокладок. Индустриальные сегменты и OT, где устройства «говорят» простыми IP-протоколами и требуют прозрачного шифрования. Взаимодействие с провайдерами, которые предоставляют L3-сервисы и ожидают стандартизованный набор параметров. Когда критично сохранить исходные адреса и метки, IPsec в транспортном режиме справляется, не ломая стек. Плюс сценарии с высокой пропускной способностью и низкой латентностью: при правильной настройке и аппаратном ускорении туннель не становится «бутылочным горлышком». Это важно для приложений реального времени — от телеметрии до потокового видео и финансовых систем.

Ещё один классический кейс — мультивендорность. AWS, Azure, GCP, локальные шлюзы от разных производителей, Linux на периферии, и всё это должно дружить. IPsec — это мост между ними. Добавим сюда мобильность: с IKEv2 и MOBIKE клиент может менять адрес, сохраняя сессию. Это уже не роскошь, а необходимость для частично удалённых команд и гибридных рабочих мест. И да, когда бизнес просит «чтобы работало, как часы», в ответ лучше не спорить — лучше принести IPsec, который уже десять лет выдерживает производственные буревестники.

Ключевые понятия, без которых никуда

Чтобы двигаться дальше, быстро освежим словарь. Security Association, или SA, — это договорённость о параметрах защиты: алгоритмы, ключи, SPI, сроки жизни. Есть IKE SA для управления и пара IPsec SA для трафика в каждом направлении. SPI — индекс, по которому узел находит соответствующую SA. SPD — база политик, описывает что шифровать, что пропускать, по каким селекторам. SAD — база ассоциаций, где хранятся активные SA. ESP — протокол, который шифрует и аутентифицирует полезную нагрузку. AH — протокол аутентификации заголовков, который сегодня реже в ходу, но не ушёл в музей. IKEv2 — протокол для согласования всех этих параметров и ключей, отвечает за рукопожатие, перезапуски и переустановку SA. Два режима защиты — транспортный и туннельный. Первый защищает полезную нагрузку IP, второй заворачивает пакет целиком. Простая схема, но из неё растёт всё остальное.

Архитектура IPsec без тумана

Стек и роли компонентов

IPsec встроен на уровне сетевого стека операционных систем. Он не прикладной, не «вверху»: он прямо внутри IP, рядом с маршрутизацией. Это означает одну приятную вещь — приложения не обязаны знать о туннелях, политиках, шифрах. Все магические превращения происходят между IP и нижележащей сетью. IKE работает в пользовательском пространстве и договаривается, а ядро выполняет шифрование и проверку. Разделение труда чёткое: IKEv2 — мозги, IPsec — мускулы. Такой подход обеспечивает стабильность и предсказуемость, а ещё позволяет аппаратно ускорять именно тяжёлые операции криптографии, где большие числа и блоки данных.

С точки зрения маршрутизации у нас два подхода — policy-based и route-based. В первом случае SPD выбирает, что шифровать, по селекторам: адреса, протоколы, порты. Во втором — создаётся интерфейс туннеля, и мы просто маршрутизируем через него. На практике route-based превалирует из-за гибкости и дружбы с динамической маршрутизацией: OSPF, BGP, даже ECMP. Но policy-based полезен для точечных сценариев и строгой сегментации. В 2026 инженеры любят смешанные модели: критичные потоки — по политикам, всё остальное — через виртуальные интерфейсы туннеля.

SPI, SA, SPD и SAD на пальцах

Если отбросить аббревиатуры, всё просто. SPD — список правил, что делать с трафиком. Прилетел пакет? Смотрим селекторы. Совпало правило на защиту — ищем SA в SAD. Если есть подходящая SA, шифруем или проверяем. Нет — IKEв2 создаёт новую SA. SPI — это число, по которому принимающая сторона понимает, какое состояние применить к пришедшему ESP-пакету. У каждой SA есть ключи, алгоритмы и таймеры жизни. Обычно мы задаём два лимита — по времени (например, 30 или 60 минут для IPsec SA) и по объёму данных (скажем, 4 или 8 гигабайт), чтобы не перерастить в риск повторного использования ключей. IKE SA живёт дольше, часами, а вот трафиковые SA чаще ротируются для безопасности и свежести криптографии.

Анти-повтор — важная часть механики. ESP хранит окно номеров пакетов и отвергает повторные. Окно настраивается, например 64 или 128, а иногда и тысячи, если сети нестабильны и могут быть перестановки. В 2026 мы часто расширяем окно для мобильных сценариев, чтобы низкие потери не превращались в ложные тревоги. Ещё один нюанс — фрагментация. Лучше избегать её за счёт правильного MTU и MSS clamping, а если уж она случается, думать над PMTUD и режимом использования DF-бита. Эти мелочи способны испортить жизнь, если их игнорировать, и наоборот, подарить спокойствие, если вы всё правильно настроили.

Куда девается пакет: путь от приложения до провода

Представим, что приложение отправляет TCP-пакет на сервер в другом филиале. Пакет попадает в стек, проходит через таблицу маршрутизации. Маршрут ведёт на виртуальный интерфейс туннеля или правило SPD говорит: шифруем по ESP. Ядро формирует ESP-заголовок, добавляет аутентифицированный тег, инкрементирует номер пакета. Если режим туннельный, исходный IP-пакет заворачивается целиком в новый IP, с внешними адресами шлюзов. Если транспортный — шифруется только полезная нагрузка и верхние заголовки, исходный IP остаётся. Затем пакет летит через физическую сеть. На приёмной стороне ядро по SPI находит нужную SA, проверяет целостность, окно реплея, расшифровывает и отдаёт исходный пакет стеку. Чистая магия без участия приложений. И это то, за что мы любим IPsec: прозрачность плюс контроль.

ESP по косточкам

Что именно защищает ESP

ESP — рабочая лошадка IPsec. Он обеспечивает конфиденциальность, целостность и аутентификацию отправителя. С ним мы можем быть уверены, что никто не подсмотрит полезную нагрузку, не подменит данные и не притворится другим. В транспорте ESP защищает заголовки верхнего уровня — TCP, UDP, ICMP, а в туннеле — весь оригинальный IP-пакет. На практике 99 процентов внедрений IPsec — это ESP. Почему? Потому что он закрывает всё, что нужно бизнесу: шифрование плюс контроль целостности, да ещё и в сочетании с современными алгоритмами AEAD, где шифрование и аутентификация идут рука об руку. Получается быстрый и строго определённый механизм, который легко масштабировать и поддерживать.

Есть детали, которые часто забывают. ESP поддерживает опцию без шифрования, только аутентификация, но это уже история прошлого — в 2026 мы включаем AEAD почти всегда. Ещё момент: ESP не защищает внешний IP-заголовок, за исключением некоторых полей в туннеле. Что это значит? Метки DSCP, маркеры маршрутизации и фрагментация остаются видимыми сети. Это удобно для QoS, но стоит помнить о рисках метаданных. В чувствительных сценариях мы минимизируем утечки через режим туннеля и аккуратно управляем DSCP-копированием, чтобы не светить приоритеты там, где это не нужно.

Формат ESP и выбор алгоритмов

Структура ESP проста: заголовок с SPI и номером пакета, зашифрованный блок данных с возможным заполнением, и аутентификационный тег. В режиме AEAD, таком как AES-GCM или ChaCha20-Poly1305, мы получаем всё одним махом. Что выбираем в 2026? Для серверов с аппаратным AES обычно ставим AES-GCM-128 или AES-GCM-256. На ARM и мобильной периферии ChaCha20-Poly1305 работает стабильно и экономно. Для PRF и хешей — SHA-256 или SHA-384, в зависимости от политики. Группы для обмена ключами — ECC: secp256r1, Curve25519 (группа 31), иногда X448 для повышенной стойкости. Диффи-Хеллман моды с PFS обязательны: честно, выключать PFS в 2026 — всё равно что ездить без ремня.

Лайфхаки выбора. Если видите старые алгоритмы типа 3DES или SHA-1 — бегите или меняйте немедленно. Присматривайтесь к гибридным наборам с предквантовой стойкостью, где классический ECDH дополняется PQC-компонентом для IKEv2. Некоторые вендоры уже поставляют превью. Да, это чуть сложнее в конфигурации, но это ваш билет в будущую эпоху постквантовых угроз. А если нужна скорость? Смотрите в сторону Intel QAT, AMD IPSec offload, ARM Crypto Extensions, NVIDIA BlueField DPU. Аппаратная магия разгружает CPU и стабилизирует задержки. И не забывайте про правильные размеры окон и пакетизации — порой один флажок MTU экономит часы разбирательств.

Аутентифицированное шифрование и режимы работы

AEAD изменил правила игры. В старых связках, где шифрование отдельно, а аутентификация отдельно, инженеры часто запутывались в порядках операций и подсчёте тегов. AEAD снимает этот пласт риска и ускоряет обработку. AES-GCM стал дефолтом в дата-центрах, а ChaCha20-Poly1305 — любимчиком на периферии и мобильных устройствах. Важно выбрать корректную длину ключа: 128 бит достаточно для большинства задач, 256 — для долгоживущих SA и строгих требований комплаенс. И да, не забывайте про случайные IV и счётчики — библиотека и ядро обычно делают всё правильно, но лучше проверять версии и патчи. Слишком часто мы видели инциденты, где проблема была не в стандарте, а в реализации.

Практический совет: тестируйте реальный трафик с вашим набором шифров. Прогоните 1, 5 и 10 гигабит на стенде. Посмотрите, где упирается CPU, какой профиль задержек. Включите аппаратные счётчики, захватите pcap до и после шифрования, убедитесь, что DSCP переносится как надо. Потренируйтесь с падениями туннеля на ротации ключей — некоторым приложениям это как красная тряпка. Стабильность на перезапусках — то, что отличает аккуратную продовую настройку от лабы.

AH: когда, зачем и почему редко

Что делает AH и его сильные стороны

AH добавляет аутентификацию и контроль целостности для IP-пакетов, включая часть полей заголовка. В отличие от ESP, AH не шифрует полезную нагрузку, зато защищает больше метаданных. Идея проста: если вам не нужна конфиденциальность, но нужна строгая аутентификация и гарантия, что никто не тронул заголовки, AH — инструмент. Он может пригодиться в закрытых средах с особой политикой, где шифрование запрещено, но контроль обязателен. Такое бывает в некоторых регулированных сегментах, в лабораториях или для процедурного контроля маршрутизации.

Надо ли это в 2026? Иногда — да. Когда мы передаём трафик по частным каналам и хотим поймать любые попытки вмешательства, AH покажет себя с лучшей стороны. Однако честно скажем: ситуация редкая. Большинству систем нужен приватный канал, и ESP закрывает и аутентификацию, и шифрование, и всё остальное. Если бизнес спрашивает «зачем AH, если есть ESP?», ваш ответ в девяти случаях из десяти — не нужен. Но знать про него стоит, потому что в старых сетях и у консервативных вендоров он ещё встречается. И когда вы читаете чужую схему, непонимание AH может дорого стоить.

Ограничения AH: NAT и совместимость

Главная боль AH — NAT. Он ломает аутентификацию, потому что устройство переписывает IP-адреса, а AH защищает именно эту часть. Да, можно хитрить, но чаще всего проще и правильнее перейти на ESP с NAT-T. Второй минус — межвендорная совместимость. На бумаге всё стандартизовано, но в реальности параметры и поведения разъезжаются, пока вы аккуратно не подгоните конфигурации. Учитывая, что спрос на AH невелик, многие производители не тратят лишние силы на поддержку «всего и сразу». Итог предсказуем: вы платите временем инженеров за спорный выигрыш.

Если уж вам нужен контроль заголовков, рассмотрите ESP в режиме без шифрования для теста или диагностики, а затем включите AEAD. Получите и целостность, и конфиденциальность, и NAT-T без боли. Это тот случай, когда проще сделать «как у всех», чем строить экзотические схемы. Экономия нервов — тоже ресурс. И да, когда речь о доступе извне, в 2026 вы точно будете проходить через NAT, CGNAT или балансировщики. AH здесь будет лишним пассажиром.

Когда AH всё же оправдан

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

IKE и IKEv2: рукопожатия и договорённости

Как работает IKEv2: фазы и обмены

IKEv2 — дирижёр оркестра. Он поднимает защищённый канал управления, а затем согласует пары IPsec SA для трафика. В двух словах: сначала создаётся IKE SA через обмен ключами (обычно ECDH), затем стороны аутентифицируются (сертификаты, PSK, EAP), после чего строится первая пара CHILD SA для данных. Фишка IKEv2 — лаконичный и надёжный обмен. Меньше сообщений, меньше возможностей для ошибок, чем у IKEv1. Плюс встроенные механизмы перезапуска, пересогласования и уведомления о состоянии. Проще с точки зрения дебага и стабильнее под нагрузкой.

На уровне практики мы задаём политики предложений: какие шифры, какие группы, какие хеши. Стороны выбирают пересечение. В 2026 набор типовых предложений включает AES-GCM-128 или 256, PRF на SHA-256, DH группы 19 или 31, и PFS включён. Мы тщательно настраиваем таймауты, интервалы DPD и логику пересогласований, чтобы избежать одновременных rekey от двух сторон. Это мелочь, но она предотвращает глупые коллизии и временные прерывания. А ещё IKEv2 умеет фрагментировать свои сообщения, что помогает в сетях с жесткими MTU и защищает от банальных проблем на границах провайдеров.

Аутентификация, EAP и совершенная прямая секретность

Аутентификация — это момент истины. В проде мы чаще используем сертификаты и PKI. PSK годятся для точечных соединений, но быстро становятся болью при масштабировании. EAP добавляет гибкость для клиентов: вы можете подключать IKEv2 к корпоративной AAA, строить тонкие политики доступа и отзывать доступы почти мгновенно. В 2026 многие организации перешли на модель «короткоживущих» сертификатов и автоматизированную выдачу через ACME-подобные потоки — меньше ручной рутины, меньше шансов на забытые ключи.

Совершенная прямая секретность, или PFS, — это ваш амортизатор против будущих взломов. Если кто-то украдёт долгосрочный ключ, он не сможет расшифровать захваченный сегодня трафик. Мы настойчиво говорим «включать всегда». Интервал ротации для CHILD SA — 30-60 минут или в пределах 1-8 гигабайт данных, в зависимости от профиля нагрузки. Для IKE SA — несколько часов, иногда сутки. Важно, чтобы ротация не приводила к заметным провалам — тестируйте приложения, особенно чувствительные к разрывам TCP, и при необходимости подстраивайте буферизацию и таймауты.

NAT-T, DPD и Keepalive: чтобы связь не падала

NAT-T — жизненно важный механизм. Он упаковывает ESP в UDP 4500, обходит NAT и балансировщики, и делает вашу жизнь проще. Без NAT-T в реальном интернете вы почти гарантированно упрётесь в головную боль. DPD, или Dead Peer Detection, помогает обнаруживать молчащие стороны. В сочетании с IKEv2 это даёт аккуратную перезагрузку и пересогласование, вместо подвисших туннелей. Keepalive с небольшими пакетами поддерживает состояние в сетях с агрессивными таймерами. Мы обычно ставим DPD в районе 10-15 секунд и таймаут 30-45, но подбираем по реальной стабильности. Слишком часто — лишняя нагрузка. Слишком редко — лишние паузы при авариях.

Совет из практики: документируйте контрольные порты и протоколы. IKE — UDP 500, NAT-T — UDP 4500, внутренняя маршрутизация — ваш выбор. Настройте наблюдаемость этих портов в системах мониторинга, чтобы отличать криптографические ошибки от банальной фильтрации на межсетевых экранах. И помните про правила приоритезации: если инфраструктура видит эти потоки как голосовые сервисы, они будут жить дольше и лучше, чем как «просто какие-то UDP». Иногда это спасает от необъяснимых падений в пиковые часы.

Режимы transport и tunnel

Транспортный режим: экономно и быстро

Транспортный режим защищает полезную нагрузку IP и заголовки верхних уровней, но оставляет исходный IP-заголовок видимым. Это экономит байты, уменьшает накладные расходы и упрощает диагностику. Когда он уместен? Хост к хосту, сервер к серверу, внутри дата-центров и кластеров, где вы контролируете адресацию и доверяете маршрутизации. Например, защита трафика между базами данных и приложениями, когда железо рядом и NAT не мешает. В 2026 мы видим рост спроса на транспортный режим в Kubernetes кластерах для east-west трафика, где IPsec интегрируется с CNI и сохраняет видимость IP для политики сети. Это и просто, и эффективно.

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

Туннельный режим: универсальный солдат

Туннельный режим заворачивает исходный IP-пакет целиком, добавляя внешний IP-заголовок со шлюзами. Это стандарт де-факто для межсетевых соединений: филиалы, дата-центры, облака. Он надёжен и гибок. Мы скрываем внутреннюю адресацию, спокойно работаем с NAT, переносим политики маршрутизации как душе угодно. В 2026 это основной выбор для мультивендорных связок: облако ждёт именно такой тип, провайдер понимает его, у вендоров он отшлифован.

О накладных расходах. Да, туннель добавляет десятки байтов, и в сетях с маленьким MTU это вызывает фрагментацию. Решение известно: настраивайте MTU на интерфейсах туннеля и применяйте MSS clamping для TCP (часто 1360-1380 байт при внешнем MTU 1500, в зависимости от вашего набора заголовков). Взамен вы получаете гибкую маршрутизацию и независимость от внутренней адресации. Если добавить GRE over IPsec, VTI или VPP-интерфейсы, можно строить полноценные L3-фабрики поверх интернета. И это работает удивительно стабильно, если всё аккуратно посчитать.

GRE over IPsec, VTI и policy vs route

Иногда нужно добавить огурцов. GRE поверх IPsec даёт вам дополнительные заголовки, в которых удобно возить multicast, динамическую маршрутизацию и некоторые протоколы, которые капризны к чистому IPsec. VTI, или виртуальные туннельные интерфейсы, упрощают жизнь, превращая IPsec-сессию в обычный интерфейс для маршрутизатора. Это почти всегда упрощает поддержку, мониторинг и балансировку. Политические туннели остаются для конкретных задач: сегментация или шифрование лишь части потоков. Но как только вы ушли в масштаб и наблюдаемость, route-based с VTI чаще выигрывает.

В 2026 мы видим широкое принятие VPP и DPDK в сетевых функциях, где IPsec реализуется на скоростях 40-100 Гбит и выше. Это уже совсем другой мир. Профиль нагрузки, NUMA, пиннинг ядер, параллелизм SA — всё играет роль. И да, чем проще логика маршрутизации поверх туннеля, тем легче отлаживать производительность. Минимизируйте магию, оставляйте её для презентаций, а в прод — понятные и наблюдаемые компоненты. Поверьте, так спокойнее спать.

Шифры 2026: скорость, стойкость и постквант

Наборы шифров, которые работают сегодня

В 2026 у нас есть чёткий золотой набор: AES-GCM-128 для дефолта, AES-GCM-256 для критики, ChaCha20-Poly1305 для ARM и мобильных маршрутизаторов. Хеши — SHA-256 и SHA-384. PRF — на SHA-256. Группы ECDH — secp256r1 и X25519. Это покрывает 95 процентов потребностей. Мы избегаем SHA-1 и 3DES, как от огня, и следим, чтобы в предлагаемых наборах не было артефактов прошлого. Для долгих каналов с большими объёмами включаем 256-битные ключи, но не злоупотребляем — иногда это избыточно и бьёт по производительности без реального выигрыша в риске.

Простой чек-лист перед продом. Включите AEAD. Убедитесь, что NAT-T включён. Пропишите одинаковые порядки реки и lifebytes на обеих сторонах. Настройте окно реплея согласно профилю потерь. И проверьте, что аппаратные ускорители реально используются — иначе вы зря купили железо. Это скучно, да. Но это тот самый этап, где закладывается спокойствие будущей ночи дежурного инженера.

Квантовые угрозы и гибридные профили

Постквант в дверях. Стандартизация ключевых механизмов для обмена ключами идёт полным ходом. В 2026 всё больше вендоров предлагают гибридные режимы IKEv2: классический ECDH плюс постквантовый KEM, типа Kyber, в одном рукопожатии. Идея в том, чтобы закрыть риски «собери сейчас, расшифруй потом». Да, это увеличивает размер сообщений и добавляет нагрузку, но цена разумная. Особенно для каналов, где данные живут долго. Важно выбрать вендора и реализацию, которые уже прошли хотя бы пилоты. Не бросайтесь в омут, но и не тяните, если у вас появляются долгосрочные активы под угрозой квантовых атак.

Переходный период будет долгим. Мы не выключаем ECDH завтра. Мы добавляем PQC-компонент гибридно и следим за совместимостью. Обновления прошивок, ядра, IKE-демонов — всё это должно быть синхронно. И да, обратите внимание на логистику ключей и сертификатов. PKI тоже ждёт обновления. Введите практику криптополитики: документируйте, что и почему разрешено, и закладывайте 12-24 месяца на мягкую миграцию. Это звучит скучно, но экономит годы и нервы.

Производительность: от CPU к DPU

Производительность IPsec — это сочетание алгоритмов, реализации и железа. На чистом CPU современные сервера тянут 5-20 Гбит на поток IPsec при хорошей настройке. С QAT или специализированными ускорителями легко переходить барьер 40-100 Гбит. DPU и SmartNIC разгружают CPU, выделяя криптографию на собственные ядра. Это даёт стабильную задержку и предсказуемые SLO. но есть нюанс — сложность сетевой топологии и наблюдаемости растёт. Планируйте это заранее: телеметрия от DPU, экспорт метрик, интеграция с SIEM.

Практический рецепт. Начинаем с профилирования: pps, размер пакета, доля небольших пакетов. Включаем offload, проверяем, что потоки равномерно распределяются по ядрам. Настраиваем IRQ affinity, NUMA-aware расписание и pinning. Тестируем под реальной нагрузкой в течение хотя бы часа пик. И не забываем про QoS: DSCP для туннелей или копирование приоритетов. Иногда одна пропущенная карта приоритетов съедает больше, чем устаревший процессор.

Практика: проектирование и деплой

Адресация, политики и маршрутизация

Один раз нарисуйте, семь раз используйте. Начинаем с адресации: чёткие префиксы, выделенные зоны для туннелей, статические и динамические маршруты. Решите, где нужен route-based, а где policy-based. Определите селекторы SPD по зонам и подсетям, и избегайте излишней гранулярности. Чем проще правило, тем меньше сюрпризов. Планируйте MTU и MSS заранее: посчитайте накладные расходы, особенно если у вас GRE поверх IPsec. Пропишите поведение DSCP: копируем метки или задаём дефолт, чтобы не пролить секреты о приоритетах наружу. Это база, на которой всё остальное держится.

Дальше политики. Определите криптопрофили: наборы шифров, группы, сроки жизни SA. Сделайте короткую, понятную таблицу, чтобы все команды говорили на одном языке. Выделите профили «дефолт», «строгий» и «тест». Так вы избежите зоопарка наборов, когда один туннель на AES-GCM-128, соседний на ChaCha20, третий на древнем наборе «на всякий случай». Пусть порядок лидеров будет одинаковым у всех. При проблемах вы сможете быстро их сузить, а не рыться в хаосе.

Масштабирование: IKEv2, MOBIKE, HA

Когда туннелей десятки и сотни, возникает другая математика. IKEv2 масштабируется лучше, чем IKEv1, и это уже аксиома. Мобильность с MOBIKE позволяет смену адреса без падения сессий — приятно для внешних клиентов и ветвей с динамическими провайдерами. Высокая доступность строится вокруг кластеров шлюзов: актив-актив для больших нагрузок, актив-пассив для простоты. Маршрутизация — через BGP поверх туннелей, с контролем префиксов и graceful restart. Не забывайте про симметричную маршрутизацию и equal-cost балансировку, если у вас параллельные туннели. Прозрачный фейловер — это общий язык для сетей и приложений.

В 2026 мы часто видим интеграцию IPsec в SD-WAN, где контрольный план управляет сотнями туннелей автоматически. Политики в одном месте, ключи в безопасном хранилище, и измерения на каждом узле. Это взрослая история, которая требует дисциплины. Журналирование IKE, экспорт метрик в Prometheus или аналоги, а также оповещения в реальном времени — это не опции, а гигиена. И, конечно, резервирование PKI и CRL-дистрибуции, иначе отозванный сертификат так и останется «живым» там, где вы об этом забудете.

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

Без наблюдаемости любая криптография превращается в гадание. Что мониторим? Состояния SA, скорость rekey, падения IKE SA, DPD события, окна реплея, RTT туннелей, pps и bps, фрагментацию, ошибки аутентификации, сбои на аппаратных ускорителях. Выведите SLI: доступность туннеля, медиана задержки, 95-й и 99-й перцентили, джиттер. На основе SLI формулируем SLO: например, 99.95 процента доступности и медиана задержки до 5 миллисекунд для критичных филиалов. Эта механика переводит разговоры «кажется, всё тормозит» в язык фактов.

Отладка — это искусство. Запасы pcap до и после шифрования, корреляция SPI с логами IKE, отметки времени на общих NTP, чтобы диаграмма сходилась. Иногда лучший инструмент — синтетические прогоны: отправляем известные шаблоны трафика и смотрим, как туннель их переваривает. И не бойтесь поднимать красные флаги: если повторная передача растёт, а окно реплея заполнено, значит где-то дрожит канал. Задача — не обвинить IPsec, а показать ему, где подложить соломку.

Кейсы и ошибки: от полей до облаков

Межфилиальные туннели и SD-WAN

Кейс из реальной жизни. Несколько десятков офисов, у каждого две независимые линии. Задача — убрать MPLS, сохранить качество, снизить затраты. Решение: IPsec-туннели поверх интернета, BGP поверх VTI, актив-актив балансировка. DSCP для критики, обычный трафик — best effort. Результат: средняя задержка 12 миллисекунд, потеря 0.2 процента, доступность 99.96 процента. В пиковые часы трафик уходит на более свободную линию автоматически. Стоимость упала на 35 процентов. Это не сказки, это нормальная сеть 2026 года, если уделить пару недель на аккуратную настройку и пилот.

Где ошибались? Поначалу забыли MSS clamping, TCP рвалось — лечится одной строчкой. Путали lifebytes между концами — в итоге одновременный rekey делал замирание. Исправили — туннель как швейцарские часы. Итог: методический подход, хороший стенд и чек-листы творят чудеса. И да, отдельный регистр метрик по каждому офису даёт возможность сравнивать яблоки с яблоками, а не спорить эмоциями.

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

В облаках IPsec живёт под именами managed VPN и Cloud VPN. Все любят туннельный режим, VTI и BGP. У облачных шлюзов есть характер: в AWS стандартный throughput на туннель ограничен, затем масштабируем через несколько параллельных туннелей и транзитные шлюзы. В Azure различаем policy-based и route-based, но для продов всегда берём route-based. В GCP всё аккуратно, но следите за квотами, чтобы не упёреться лбом в потолок в ночь релиза. NAT-T везде маст-хэв, и проверьте их списки шифров — иногда дефолты у провайдеров не самые свежие.

Кейс. Компания подключает три региона к центральному дата-центру. Схема: по два туннеля на регион, суммируем пропускную до 6-8 Гбит на сторону, BGP анонсирует только нужные префиксы. QoS в провайдере синхронизирован с DSCP из туннеля, приоритеты приложений сохраняются. В момент пиковой распродажи узкое место оказалось не в криптографии, а в NAT у поставщика, который резал UDP-сессию по бездействию. Keepalive и увеличение таймера решили проблему. Мораль: иногда IPsec невиновен — виноваты крестьяне вокруг него.

Частые ошибки и быстрые решения

Ошибки повторяются. Слишком «богатые» policy-based селекторы ломают совместимость. Разные lifetimes на концах приводят к аккуратным, но чувствительным паузам. Игнорирование MTU и MSS растит количество ретрансляций и бьёт по скорости. Неправильные окна реплея превращают потери в паранойю и дропнутые пакеты. И ещё — забытые сертификаты. Истёк срок, и вы внезапно стоите в час пик с горящими лампочками. Ужасно? Да. Лечится? Да, напоминаниями, автоматической переэмиссией и мониторингом сроков.

Чек-лист на холодильник. Пройди по шифрам, убери устаревшее. Проверь NAT-T. Выравняй lifetimes и rekey-тайминги. Настрой MTU, MSS, DSCP. Включи DPD и логирование. Обнови прошивки и ядра. Запусти план ротации ключей. Убедись, что PKI жив и здоров. Эти десять пунктов закрывают 80 процентов проблем ещё до их появления. Звучит банально, но лучше скучная предсказуемость, чем геройский подвиг в 3 часа ночи.

Безопасная эксплуатация и комплаенс

Ротация ключей и криптополитика

Ключи стареют. Это не поэзия, это физика и статистика. Мы задаём понятные интервалы жизни: CHILD SA 30-60 минут или 1-8 ГБ, IKE SA 4-24 часа. Причина ясна — снижаем стоимость компрометации и усиливаем PFS. Важно, чтобы ротация была шумной только в логах, а не в приложениях. Подберите тайминги так, чтобы они не совпадали между соседними туннелями и не вспыхивали одновременно. Это маленькая инженерная хитрость, которая держит прод в тонусе без драм.

Криптополитика — документ, который спасёт вас на аудитах и при смене команд. В нём мы фиксируем допустимые алгоритмы, длины ключей, периоды жизни, требования к PFS и правила ротации. Это не просто бумага — это договор внутри команды. Мы также описываем процедуру экстренной смены ключей, чтобы в случае инцидента не бегать, как в первый раз. Поверьте, такой документ окупается при первой же проверке.

Политики доступа, ZTNA и роль IPsec

ZTNA и SASE модны и полезны, но IPsec не уходит. Их роли разные. ZTNA — тонкий доступ к приложениям с аутентификацией пользователя и устройства, часто поверх TLS. IPsec — транспортный щит для сетевых сегментов и машин. В 2026 большинство зрелых архитектур используют оба подхода. IPsec покрывает east-west и север-юг между площадками, ZTNA даёт безопасный доступ внешним пользователям. Вместе они закрывают и сеть, и пользователей, и устройства. «И волки сыты, и овцы целы», как говорится. Важно, чтобы политики не конфликтовали, а телеметрия стекалась в единую систему обнаружения аномалий.

Не забывайте про минимизацию привилегий. Даже в IPsec-модели сегментация важна. Не надо давать филиалу видеть весь мир. Давайте только то, что необходимо. Префиксы, ACL поверх туннелей, контроль маршрутов. Лишние права — это квиток на инцидент. Аудит покажет, что вы серьёзно относитесь к безопасности, а инженеры скажут спасибо за предсказуемость.

Аудит, соответствие и реагирование на инциденты

Комплаенс — это не баг, а фича. Когда все знают, где искать логи, как сверить параметры SA, как доказать, что шифры соответствуют политике, стресс уменьшается. Что нужно? Централизованное хранение логов IKE, события DPD и rekey, запись изменений конфигураций, контроль сроков сертификатов. Плюс регулярные проверки на предмет устаревших алгоритмов и несогласованных lifetimes. Это дисциплина, которая окупается.

Инцидентная реакция начинается с сигналов. Тревога на падение туннеля не должна приходить одна. Её сопровождают метрики RTT, потерь, статусы IKE SA, статусы аппаратных модулей. Руководству нужен понятный отчёт, а инженерам — сигнатуры проблемы. Чем быстрее вы отличите сбой канала от криптографической несовместимости, тем меньше простоя. И не стесняйтесь проводить постмортем: честно расписать, где залипли, где поторопились, где недонастроили. Это взрослое отношение, которое выводит сеть на новый уровень.

Глубже в механику SA: согласование и жизненный цикл

Как выбираются предложения и что такое пересечение

Выбор шифров — это про пересечение множеств. Каждая сторона приносит список предложений, IKEv2 выбирает совместимый набор. Проблемы начинаются, когда списки слишком длинные или несогласованно упорядочены. Наш опыт говорит: 2-3 варианта в профиле достаточно. Первый — желательный, второй — альтернативный на другом классе железа, третий — совместимость с консервативными соседями. Чем меньше экзотики, тем лучше. И да, зафиксируйте эти профили в коде инфраструктуры, чтобы не было «сюрпризов по субботам».

Согласование SA — это и про lifetimes. Важна согласованность таймингов. Если одна сторона пытается переустановить SA слишком часто, а другая не ожидает, будут дрожания. Выбирайте окна так, чтобы они не попадали на перекрёстки нагрузки. Например, избегайте одновременной ротации во всех туннелях в полдень. Развести на минуты — уже помогает. И тестируйте, как ваши приложения переживают rekey, особенно базы данных и критический RPC.

Автоматизация: инфраструктура как код и валидаторы

В 2026 автоматизация — не роскошь. Мы описываем туннели, профили шифров, lifetimes и селекторы как код. Генерируем конфигурации для разных вендоров из одной модели. Пропускаем через валидаторы, которые ловят несогласованности. Это экономит недели на проектах от пятидесяти туннелей и выше. Плюс позволяет документировать всё автоматически — комментарий рядом с кодом говорит больше, чем устные легенды. А при инциденте у нас есть диффы и история изменений — подарок для расследования.

И не забывайте про тестовые окружения. Лаборатория со стендом, где можно моделировать потери, задержки, фрагментацию и rekey — лучший друг инженера. Запланируйте нагрузочные окна, симулируйте падение одного из концов, проверяйте поведение DPD. Такие «репетиции» минимизируют риск, что в проде вы увидите «невозможную» проблему впервые. А этого не любит никто — ни бизнес, ни дежурные, ни пользователи.

Управление рисками и документирование исключений

Иногда реальность диктует компромисс. Кто-то из партнёров не поддерживает нужный набор шифров. Где-то старое устройство не тянет AES-GCM-256. Мы фиксируем исключения, ограничиваем их сроком и зоной действия, и прописываем план выхода. Это взрослая позиция: признать ограничение, но не превращать его в вечный долг. Каждое исключение проходит через риск-ревью: что мы теряем, чем компенсируем, когда уберём. Так мы не даём техническому долгу захватить инфраструктуру.

И да, честно говорим команде: «Здесь у нас неидеально». Такая прозрачность рождает доверие. Люди чувствуют, что у управляемых рисков есть автор и срок. Это лучше, чем сюрпризы на ревью безопасности. В конце концов мы строим системы, а не коллекцию чудес.

Транспорт против TLS VPN и роль IPv6

IPsec и TLS-базирующиеся VPN: кто есть кто

В последние годы TLS VPN сильно окрепли. Они хороши для доступа пользователей и приложений, быстро проходят через прокси и фаерволы, и часто проще в клиентском опыте. Но IPsec — это магистраль. Он шифрует трафик прозрачно для приложений, дружит с маршрутизацией и QoS, и в сочетании с аппаратным ускорением обеспечивает стабильную латентность. Так что это не «или-или», это «и-и». Там, где нужна сетевой транспарантность и высокая пропускная способность, берём IPsec. Там, где нужен легковесный доступ к отдельным сервисам, используем TLS. Живём вместе, не спорим.

Когда бизнес спрашивает «почему не только TLS?», мы отвечаем цифрами. Маршрутизируем десятки префиксов, держим 10-40 Гбит с предсказуемой задержкой, управляем DSCP, BGP, ECMP. Это язык IPsec. TLS в этих задачах либо потребует нестандартных танцев, либо съедет в кашу из прокси и специфичных клиентов. Компромисс возможен, но за счёт усложнений. И зачем, если есть стандартный, надёжный путь?

IPsec и IPv6: плюсы и подводные камни

С IPv6 IPsec чувствует себя, как дома. Простая адресация, больше пространства, меньше NAT. NAT-T уходит, и жизнь упрощается. Но подводные камни есть. PMTUD и ICMPv6 критичны — не блокируйте их бездумно. Внимательно отнеситесь к Extension Headers и маршрутизации — часть сетевых устройств до сих пор неловко работает с ними в сочетании с IPsec. Планируя IPv6-сети с IPsec, заранее тестируйте поведение туннелей, особенно если у вас WAN-оборудование среднего класса, которое старательно, но не всегда умно «оптимизирует» трафик.

В выигрыше ли вы? Да. Маршрутизация чище, политики однозначнее, NAT-проблем меньше. Но не забудьте про операционный опыт: мониторинг и диагностика должны понимать IPv6-адреса и строить на них алерты. А ещё — обучите команду. Иногда самый большой барьер к IPv6 — это не железо и не софт, а привычки. С IPsec всё то же: технология готова, нас догоняют люди и процессы.

Zero Trust и сетевой шифр: синергия без конфликтов

Zero Trust — не враг IPsec. Он дополняет его. Модель подразумевает, что каждый запрос проверяется, а доверие постоянно подтверждается. IPsec в этой картине — шифрованный транспорт между доверенными доменами, где поверх строятся политики доступа и аутентификация пользователя. В 2026 зрелые команды перестают спорить «что лучше», и строят сквозные цепочки: девайс и пользователь проходят проверку, доступ идёт к нужному сегменту по ZTNA, а внутри сегмента и между сегментами работает IPsec с PFS и мониторингом. Результат — защита и на уровне соединения, и на уровне личности.

Секрет прост: договоритесь о границах ответственности. Кто отвечает за выдачу и отзыв сертификатов? Кто управляет профилями шифров? Кто меряет SLO туннелей? Кто поддерживает конфигурации ZTNA? При чётких ответах два мира не конфликтуют, а усиливают друг друга. И да, обратная связь из SOC в сети — это золото. Когда аналитика видит аномалии, сети знают, где подкрутить. Это и есть взрослая, живая безопасность.

Оптимизация и экономия: где спрятаны проценты

MTU, MSS и фрагментация

Вы удивитесь, сколько проблем уходит, когда правильно выставлен MTU. Для туннеля на стандартной «внешней» 1500 MTU мы часто ставим MTU 1400-1420 на VTI, а MSS для TCP ограничиваем 1360-1380. Конкретные цифры зависят от набора заголовков и опций. Тестируйте пинг с большим размером и флагом «не фрагментировать», смотрите трассировки, наблюдайте retransmissions. Если всё тихо — вы подобрали верно. Это экономит не проценты, а иногда десятки процентов производительности.

Не забывайте про коробки посередине. Некоторые провайдерские устройства любят «помочь» и переписать пакеты необычным образом. Включите логирование ICMP fragmentation needed, проверьте, что PMTUD не задушен фаерволом. Эти маленькие пешки решают большие партии. И ещё — смотрите на распределение размеров пакетов. Если у вас смесь мелких и больших, возможно эффективнее разбить трафик по туннелям с разными профилями QoS. Пусть большие грузовики едут по одной дороге, а маленькие — по другой. В сети это работает почти так же, как на трассе.

Offload и профилирование CPU

Аппаратные ускорители — ваш друг, если вы дружите с ними правильно. Проверьте версии драйверов, включите offload в ядре, измерьте выигрыш. Иногда придётся подвинуть IRQ, закрепить очереди за ядрами, привязать трафик определёнными политиками. Это тонкая настройка, но она окупается. На мидлвее нагрузка спадает на 20-40 процентов, задержка стабилизируется. В высоких скоростях это разница между «не тянет» и «работает как будто без шифрования».

Профилируйте. Смотрите perf, eBPF-телеметрию, flame graphs. Где тратит время стек? На криптографии, копировании данных, блокировках? Может, у вас одна горячая блокировка мешает параллелизму SA, и всё остальное уже не важно. И да, измеряйте под реальной нагрузкой, а не синтетикой «одной длинной очереди». Жизнь редко бывает такой идеальной, как бенчмарк.

QoS, DSCP и приоритезация

Туннели живут лучше, когда сеть их уважает. DSCP — сигнальный флажок, к которому многие провайдеры прислушиваются. Решите заранее: копируете ли вы DSCP внутрь туннеля или задаёте наружный отдельно. Несогласованность приводит к неожиданным приоритетам и спорному поведению. Лучше держать простой и понятный маппинг, документированный и протестированный. И проверяйте, что изменения метки не ломают целостность — в ESP внешние метки видны, а вот внутренняя полезная нагрузка защищена. Это даёт манёвренность без компромисса безопасности, если всё согласовано.

Нюанс: QoS — не магия. Он не создаёт пропускную способность, он её справедливо делит. Поэтому в узких местах, где вы регулярно упираетесь в потолок, сначала оптимизируйте план емкости, а уже потом рисуйте многоцветные карты приоритетов. Иначе вы получите красивую диаграмму, где всё равно плохо.

Сценарии миграции и модернизации

С IKEv1 на IKEv2: как пройти без боли

Миграция с IKEv1 — уже классика. Делаем двойной стек, запускаем пилоты, переносим туннели пачками. Важно, чтобы криптопрофили, периоды и политики были заранее согласованы. Журналирование включить на максимум, метрики собрать, тесты прогнать. Потом отдельный шаг — отключить старые наборы шифров, которые держались «на всякий случай». Это как генеральная уборка: сначала тяжело, потом дышится легче. Бонус — автоматизация. IKEv2 проще в кодогенерации, меньше углов и исключений.

Ожидания. Производительность чаще растёт, стабильность усиливается, особенно на rekey. Клиентские подключения становятся предсказуемее. Фактор риска — совместимость редких вендоров. Решение — стейджинг с двойной связью и аккуратное сравнение поведения. И не бойтесь отложить миграцию одного филиала, если там особенные условия. Линейности в жизни мало, но системность всегда помогает.

Обновление шифров и прощание с SHA-1

Обновление шифров страшит меньше, если у вас есть криптополитика. Просто запускаете «миграцию профиля»: сначала добавляете новый набор как альтернативу, проверяете пересечение, переключаете при удобном окне, затем убираете старый. Так вы никогда не попадёте в ситуацию «чёрного экрана». Важный момент — контрольные измерения. Сравните задержки, CPU, ошибки целостности. Иногда новый шифр ведёт себя иначе на ваших пакетах. Лучше знать заранее, чем узнавать в горячей фазе.

И пожалуйста, забудьте SHA-1. В 2026 это даже не дискуссия. Если кто-то настаивает на нём «для совместимости», это повод пересмотреть интеграцию целиком. Хорошая совместимость — это уважение к будущему, а не поклон предкам. Сорри за эмоции, но здесь я категоричен.

Постквантовые пилоты: план на год

Если вы храните чувствительные данные, которые живут годами, начните пилот гибридного IKEv2. Выберите пару площадок, обновите софт, включите гибридный обмен ключами, измерьте накладные расходы. Обновите документацию, обучите команду, опишите «план Б». Через три-четыре месяца у вас будет фактология, а не догадки. Затем масштабируйте: включайте гибрид на магистралях, оставляя классический на периферии до обновления железа. Это стратегия маленьких шагов, но она ведёт к большой цели — защите «здесь и сейчас» и устойчивости «потом».

И не забывайте о партнёрах. Постквантовый мир — это про совместимость не меньше, чем про криптографию. Пишите и договаривайтесь заранее, не ставьте соседей перед фактом. Хорошие сети строят диалог, не ультиматумы.

Трюки от практиков: дебаг и стресс-тесты

Диагностика по SPI и пульс туннеля

Когда туннель капризничает, начинаем со SPI. Соотнесите SPI в pcap с SA в SAD. Смотрите счётчики реплеев, дропов по целостности, таймеры lifetimes. Отдельно отметьте RTT и джиттер на обоих концах, чтобы увидеть, кто виноват. Иногда это не криптография, а узкое место на линке. Убедитесь, что rekey не сходится с пиками нагрузки и не ест ресурсы. Добавьте корреляционные идентификаторы в логи, чтобы иметь сквозной след события от IKE до маршрутизатора. Это как слепок пальцев — уникальный и бесценный при разборе.

Лайфхак: заведите «паспорт туннеля». Параметры шифров, lifetimes, диапазоны, MTU, история инцидентов, контакты соседей. Обновляйте его при любом изменении. Через полгода это будет ваш золотой стандарт, а через год — основа для автоматизации. И да, не ленитесь подписывать графики на дешбордах. Неподписанная линия — как загадка, которую никто не хочет разгадать в 3 ночи.

Нагрузочное тестирование без самообмана

Стресс-тест — не марафон, а спринт на трёх дорожках. Первая — синтетика с разными размерами пакетов и pps. Вторая — реплика реального трафика: микс портов и протоколов. Третья — аварийные сценарии: rekey, падение интерфейса, потеря 1-3 процентов пакетов, асимметрия маршрутов. Все три важны. Без аварий вы не увидите, как туннель держит удар. Без микса — не поймёте влияние на приложения. Без pps — не поймёте профиль CPU. И пожалуйста, проводите тесты хотя бы час, а лучше два. Кеши и таймеры любят играть с нами в прятки.

Запомните: цель теста — не рекорд, а предсказуемость. Вы хотите знать, что в пятницу в 18:00 у вас не начнётся «шоу с огоньками». Поэтому используйте чёткие критерии: какой pps держим, какая задержка, сколько времени rekey идёт без потерь. Эти цифры — ваш амулет от сюрпризов.

Инцидент-менеджмент и обратная связь

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

FAQ: коротко и по делу

Чем ESP отличается от AH и что выбрать в проде

ESP шифрует и аутентифицирует полезную нагрузку, AH только аутентифицирует, частично включая заголовки. В 2026 мы почти всегда выбираем ESP с AEAD, потому что это и конфиденциальность, и целостность, и совместимость с NAT-T. AH — нишевый инструмент для редких случаев без шифрования. Если сомневаетесь, берите ESP, не промахнётесь.

Какой режим выбрать: транспортный или туннельный

Транспортный режим хорош для хост-к-хост, внутри дата-центров и когда важен минимальный overhead. Туннельный — для межсетевых связей, облаков и мультивендорных схем. Он скрывает внутреннюю адресацию, работает с NAT и дружит с BGP. Если у вас сеть между площадками и провайдеры в середине, берите туннельный. Для локальных и управляемых сегментов — транспортный.

Какие шифры актуальны в 2026

AES-GCM-128 по умолчанию, AES-GCM-256 для критичных систем, ChaCha20-Poly1305 для ARM и мобильных платформ. Хеши SHA-256 и SHA-384. ECDH на X25519 или secp256r1. Обязательно PFS. Избегаем SHA-1 и 3DES. Смотрите на гибридные профили IKEv2 с постквантовыми компонентами для долгоживущих каналов.

Как настроить NAT-T и не страдать

Включите NAT-T, используйте IKE на UDP 500 и ESP over UDP 4500. Настройте DPD и keepalive, чтобы не терять состояние на жадных NAT. Проверьте таймеры у провайдера и балансировщиков. Убедитесь, что MTU и MSS учтены, чтобы не получить немые дропы из-за фрагментации. И не забывайте логи IKE — они первые подскажут, где всё пошло не так.

Какие тайминги жизни SA выбрать

Для CHILD SA 30-60 минут или 1-8 ГБ, для IKE SA 4-24 часа. Главное — согласованность между сторонами и отсутствие одновременного rekey на множестве туннелей. Проведите тесты под нагрузкой, чтобы убедиться, что приложения спокойно переживают ротацию. Лучше чаще и предсказуемо, чем редко и болезненно.

Что делать с постквантовыми рисками уже сейчас

Запланируйте пилот гибридного IKEv2: добавьте постквантовый KEM к ECDH. Обновите софт и прошивки, проверьте совместимость. Начните с магистралей, затем расширяйте. Обновите криптополитику и процессы PKI. Даже если массовое принятие займёт время, вы будете готовы и избежите спешки в момент X.

Как убедиться, что IPsec не стал узким местом

Меряйте pps, bps, задержку и джиттер. Включите аппаратный offload, проверьте профилирование CPU. Подберите MTU и MSS, настройте QoS, следите за фрагментацией. Прогоните стресс-тесты: микс трафика, rekey, сбои каналов. Если туннель держит эти сценарии без потерь и всплесков задержки, всё хорошо. А если нет — у вас есть план, где подкрутить.