IPSec в корпоративной среде воспринимается как одна из самых надёжных технологий построения туннелей для защищённого взаимодействия между сетями, площадками, удалёнными филиалами и центрами обработки данных. Основанный на стойких криптографических алгоритмах и строгом механизме аутентификации, IPSec разделяется на две фазы: первая (Phase 1) устанавливает защищённый канал между шлюзами, а вторая (Phase 2, или Quick Mode) определяет, какой именно трафик следует через этот канал передавать, какие параметры шифрования к нему применять и по каким селекторам (Selectors) определять границы политики защиты. Именно в этой второй фазе заключена главная гибкость — и одновременно главная уязвимость — конфигурации IPSec.
Ошибка на этом уровне не приводит к мгновенному разрыву соединения, как при сбоях на Phase 1. Наоборот, туннель поднимается, SA устанавливается, шифрование работает. Но происходит куда более опасное: часть трафика, который должен был быть защищён, начинает обходить туннель, уходит напрямую в интернет, маршрутизируется через незащищённые интерфейсы или, что ещё коварнее, остается на границе шифрования, но не соответствует правилам обработки. Это означает, что IPSec “жив”, туннель “вверх”, пользователи видят подключение — но данные уходят по незашифрованным маршрутам. И это делает проблему в разы опаснее, чем простой сбой: речь идёт не о потере доступа, а об утечке.
Как работает Phase 2 и почему всё завязано на Selectors
В Phase 2 IPSec создаёт так называемый Security Association (SA), который описывает, какой трафик разрешён к шифрованию. Он формируется на основе четырёх компонентов: локального IP (Local Subnet), удалённого IP (Remote Subnet), протокола и портов. Вместе они составляют селектор, по которому IPSec определяет, к какому трафику применять шифрование, а какой пропускать без него. На практике это означает, что все данные, проходящие между двумя площадками, будут зашифрованы только если их параметры попадают под эти селекторы.
Ошибка в этих параметрах — например, неправильно указанный диапазон, забытая VLAN, игнорируемая подсеть или перепутанный адрес — приводит к тому, что трафик, не попадающий в политику, уходит “мимо” туннеля. Он обрабатывается обычной таблицей маршрутизации, поднимается в сторону провайдера или локального шлюза, и никакое шифрование IPSec к нему не применяется. Более того, если NAT или Policy-Based Routing включены — он может попасть в интернет без каких-либо признаков защиты. Всё это при “включенном” VPN.
Почему такие ошибки трудно отследить
Главная особенность таких сбоев — в том, что они не нарушают работу соединения. Туннель установлен, SA активны, Phase 1 и 2 “зелёные”, в интерфейсе маршрутизатора всё отображается как “подключено”. Логов об ошибке нет. Даже мониторинг показывает — “связь установлена”. Но часть трафика не попадает в шифрование. И именно потому, что он технически не нарушает политику — он её обходит. Ни одна система безопасности не будет бить тревогу, если маршрут построен по правилам. Просто он не защищён.
Особенно часто это происходит в Policy-Based IPSec, где администратор вручную указывает, какие сочетания source/destination/address должны попадать в туннель. Ошибка в одном байте маски (/24 вместо /23), в одном IP, в одном объекте — и целая подсеть, например с серверами мониторинга, камерами, серверами журналирования — остаётся вне защиты. В случае Route-Based IPSec эта ошибка может быть связана с неправильной маршрутизацией: трафик, не направленный в туннель-интерфейс, просто идёт напрямую. И опять же — ни одна часть системы об этом не скажет. Потому что нет “сбоя”. Есть некорректное попадание в политику.
Как это выглядит в реальности
В реальных инцидентах подобные ошибки приводили к тому, что серверы удалённого филиала синхронизировали данные по HTTP напрямую через интернет, в то время как всё остальное шло через IPSec. Или что HR-система, подключённая к базе данных из облака, работала в “части сети”, которую забыли внести в селектор, и все запросы шли незашифрованными. Или что системы телефонии и VoIP, из-за неправильной маски сети, не попадали в SA и “падали” при переключении между площадками. Всё это не выглядело как катастрофа. До момента, когда данные утекали.
Наиболее опасный сценарий — когда селектор на одной стороне настроен шире, чем на другой. В таком случае одна сторона отправляет зашифрованный трафик, но получатель не принимает его в рамках SA. Он считает это “неразрешённым” и дропает. Или — наоборот — пропускает незашифрованный трафик, считая его “обычным”. В первом случае — потеря данных. Во втором — утечка. И в обоих случаях администратор не видит проблемы, пока кто-то не начнёт анализировать трафик на границе.
Где чаще всего происходят ошибки
Самая распространённая причина — несогласованность политик между сторонами. Одна сторона считает, что туннель защищает трафик между 10.1.0.0/16 и 10.2.0.0/16, а другая — указывает только 10.2.1.0/24. В результате всё остальное — не зашифровывается. Или добавляется новая подсеть в LAN, но не добавляется в селектор. Маршрутизация есть, IP “видны”, но шифрования нет. Или администратор включает новые службы (например, телеметрию, видеонаблюдение, SNMP), но “забывает” внести порт и протокол в SA — если используется селекция по L4. Тогда IPSec игнорирует такие пакеты как “вне политики”.
Такие ошибки становятся ещё опаснее в случае, если включена автоматическая генерация SA при “динамическом” обмене политиками. В некоторых реализациях туннель может принять SA, отличную от локальной, и начать работу в “пересекающемся” режиме. Это приводит к асимметрии: одна сторона считает, что шифрует, другая — что расшифровывает “не тот” трафик. И тогда часть пакетов теряется, а другая — выходит без шифрования.
Почему не помогает “всё пингуется”
Это — классическая ловушка. Администратор проверяет: “туннель поднят, пинги идут, маршруты есть”. Но ICMP может идти в обход SA. Особенно если на граничных интерфейсах разрешён прямой маршрут. Это создаёт иллюзию, что сеть “работает”, хотя на самом деле вся прикладная часть — API, базы, файлы, SIP — идёт по незащищённому каналу. Проверка должна быть не по “работе пинга”, а по анализу SA, пакетов, использованию ESP, логов IPSec и сопоставлению маршрутов и политик.
Настроить IPSec — значит понимать границы защиты
На курсе «Технологии туннелирования» Вы научитесь не только поднимать IPSec-соединения, но и проектировать политику безопасности, при которой весь нужный трафик гарантированно попадает под SA, а всё остальное — блокируется или маршрутизируется контролируемо. Мы разбираем работу селекторов, Phase 2, анализ конфигураций, механизмы route- vs policy-based IPSec, работу NAT-T, туннельных интерфейсов, взаимодействие с PBR и правилами Firewall. Вы научитесь выявлять утечки, проверять реальное шифрование, строить логику защиты не по интерфейсу, а по модели риска.
Туннель есть — не значит, что данные защищены. Без точного селектора IPSec — просто декорация. Реализуйте настоящую защиту!
![]() |
![]() |
![]() |
![]() |
![]() |