Какой VRF достигает узла VPN, а какой несёт пакет?

Каждый туннель внутри контекста маршрутизации клиента всё равно должен достигать своего удалённого партнёра, и этот поиск может происходить в совершенно другой таблице. Ошибка здесь даёт один из самых запутанных отказов в IPsec с поддержкой VRF: туннель поднимается, маршруты выглядят присутствующими, а трафик умирает, потому что один из двух поисков использовал неверный контекст. Выполните четыре шага ниже по порядку и запишите оба назначения отдельно.

Два поиска, один туннель

Внешний инкапсулированный пакет адресован транспортному адресу партнёра и маршрутизируется до того, как существует какая-либо защита. Внутренний пакет адресован серверу клиента и маршрутизируется после декапсуляции, внутри контекста клиента. Это два назначения, два поиска и часто две разные таблицы.

Документация Cisco по IPsec с поддержкой VRF называет их VRF передней двери и внутренним VRF. Передняя дверь несёт зашифрованный транспорт, а внутренний контекст несёт защищённый трафик. Ничто в названии туннеля по имени клиента не заставляет появиться хотя бы один из маршрутов.

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

Подтвердите транспортный поиск для партнёра

Начните с передней двери, потому что туннель, который не может достичь партнёра, никогда не пропустит ни одного защищённого пакета. В IOS запросите маршрут к партнёру внутри транспортного VRF, а не в глобальной таблице.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

Первая команда отвечает, достижим ли адрес партнёра в этом контексте, вторая перечисляет VRF, которые действительно существуют, а третья показывает, сформировалась ли ассоциация безопасности. Адрес партнёра, который разрешается только в глобальной таблице, классическая ошибка передней двери, и она проявляется как IKE-переговоры, которые никогда не начинаются.

Проверьте также назначение интерфейса. Документированное поведение требует, чтобы VRF передней двери туннеля и VRF интерфейса WAN совпадали; несовпадение может позволить пакету уйти и всё же помешать обработке ответа в правильном контексте.

Подтвердите внутренний поиск для сервера

Когда передняя дверь доказана, перейдите в контекст клиента и задайте тот же вопрос о префиксе сервера. Этот поиск решает, можно ли передать декапсулированный пакет дальше.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

Первая команда показывает внутренний маршрут, а вторая состояние сессии вместе с контекстами, которые платформа с ней связала. Если маршрут существует, но подробности сессии указывают неверный внутренний контекст, туннель передаёт в таблицу, которая не знает префикса клиента.

Маршрут в глобальной таблице не является доказательством ни для одного из двух поисков. Глобальные маршруты используются, когда пакет не связан с VRF, а интерфейс туннеля, назначенный контексту клиента, меняет эту связь. Если внутренний маршрут отсутствует, пакет декапсулируется и затем отбрасывается из-за отсутствия записи пересылки, что выглядит как потеря пакетов, а не как ошибка маршрутизации.

Разместите настройку там, где её ожидает модель

Та же документация различает модели конфигурации, и настройка, принадлежащая одной, не обязательно принадлежит другой. Для интерфейсов туннеля с защитой туннеля внутренний VRF определяется на интерфейсе туннеля. В решениях на основе crypto map внутренний VRF является частью записи crypto map. Перенос похоже названной команды между моделями без проверки её роли — это путь, которым работающая схема становится нестабильной.

Маршрутизация и идентичность — отдельные вопросы. Достижимость никогда не заменяет профиль партнёра, который устройство примет, а переименование VRF не должно менять предлагаемые учётные данные. Проверяйте и то и другое после любого изменения, потому что туннель, ведущий переговоры с неверным профилем, всё равно может сформировать ассоциацию и ничего не передавать.

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