Теоретические основы и архитектура

Безопасность плоскости данных (Data Plane Security) в MPLS L3VPN строится на строгой изоляции таблиц VRF. Однако ошибки конфигурации могут привести к катастрофической уязвимости — утечке маршрутов между клиентами (Route Leaking). Основные причины утечек: 1. Ошибочный импорт чужого Route Target (например, если администратор случайно скопировал конфиг и указал route-target import 65000:100 в VRF B, все внутренние подсети Клиента А станут видны Клиенту Б). 2. Неконтролируемая взаимная редистрибуция (Mutual Redistribution) между протоколами PE-CE без использования тегов маршрутов (Route Tags), вызывающая маршрутные петли и перетекание префиксов через клиентский сайт. 3. Отсутствие фильтрации на CE-маршрутизаторах: клиент может непреднамеренно анонсировать по eBGP префиксы других своих партнёров, превратив оператора в бесплатный транзит. Для защиты оператор обязан: использовать уникальные RT, настраивать Route Maps с жесткими фильтрами префиксов на каждом PE-CE стыке и контролировать максимальное количество принимаемых маршрутов.

Что именно гарантирует изоляция L3VPN

По RFC 4364 клиентские сети разделены четырьмя механизмами: (1) контекст пересылки выбирается по входному интерфейсу, то есть пакет попадает только в FIB своего VRF; (2) Route Distinguisher делает VPNv4 NLRI уникальным, поэтому перекрывающиеся префиксы не затирают друг друга в BGP; (3) Route Target определяет, какие маршруты VRF экспортирует и импортирует; (4) в ядре пакет несёт две метки, и клиент не может влиять ни на транспортную, ни на VPN-метку. Оператор вправе обещать клиенту уровень безопасности, сопоставимый с Frame Relay/ATM (RFC 4364, раздел Security Considerations; анализ угроз - RFC 4381), но не больше: шифрования и аутентификации данных в L3VPN нет, а гарантия действует ровно до тех пор, пока политика RT/RD и фильтры на стыках настроены верно.

Где изоляция ломается: список мест

  • Route Target. Достаточно одного лишнего route-target import (скопированный блок, шаблон без подстановки клиента), чтобы чужие маршруты оказались в VRF. RT - это единственный переключатель между "изолирован" и "виден", поэтому его нужно считать защищаемым ресурсом: единый реестр RT, генерация из номера клиента, автоматическая сверка вывода show с реестром.
  • Расширенные community от CE. Если на PE-CE сессии eBGP принимаются extended community, клиент может прицепить к своему префиксу RT:65000:100; PE при экспорте добавит свои RT, а чужая метка останется, и удалённые PE импортируют префикс в VRF жертвы. Поэтому на входе от CE extended community стирают, а политику строят только на RT, которые назначает PE.
  • Общие сервисы (extranet). Общий VRF - это контролируемая дыра в изоляции. Правила: каждый клиент экспортирует в общий VRF только опубликованные префиксы и отдельным RT (A: 65000:910, B: 65000:920), общий VRF импортирует их через import map/route-policy со списком допустимых префиксов, а клиенты импортируют из него один RT 65000:999 и только префиксы серверов. Общий VRF не должен реэкспортировать клиентские маршруты и работать транзитом между клиентами.
  • Перекрывающиеся адреса. Если A и B оба публикуют 192.168.10.0/24, общий VRF выберет один путь, и обратный трафик сервера уйдёт не тому клиенту. В общий VRF публикуют только уникальные адреса (NAT-пул, отдельная /24 из реестра оператора).
  • RD. RD не управляет политикой, но один и тот же RD в VRF двух разных клиентов делает их префиксы одним NLRI: RR выберет один лучший путь, и половина клиентов получит чужой next-hop. RD должен быть уникален на пару (VRF, PE); для одного клиента на разных PE разные RD ещё и сохраняют несколько путей на RR.
  • Лимиты. Клиент с полной интернет-таблицей на PE-CE сессии исчерпывает память RIB/FIB и ломает соседей по PE. Защита двойная: лимит маршрутов на VRF (Cisco: maximum routes, Huawei: routing-table limit, Junos: maximum-prefixes на таблице) и max-prefix на BGP-соседе.

Подмена метки на стыке CE-PE

Метка VPN имеет значение только внутри домена оператора. Если бы PE принимал от CE пакеты с MPLS-заголовком, клиент мог бы подобрать чужую VPN-метку (метки выдаются из небольшого предсказуемого диапазона, начиная с 16) и отправить пакет прямо в чужой VRF на egress PE. Защита: интерфейс к CE не участвует в MPLS-пересылке (Cisco: нет mpls ip, интерфейса нет в show mpls interfaces; Junos: нет family mpls и записи в protocols mpls interface; Huawei: нет mpls на интерфейсе), а пакет с меткой, пришедший на такой интерфейс, отбрасывается. Исключение составляют стыки, где метки намеренно принимаются (Inter-AS Option B/C, CSC): там доверие переносится на control plane.

Inter-AS и граница доверия

  • Option A (back-to-back VRF): ASBR ведёт себя как PE и считает соседний AS клиентом: отдельный (под)интерфейс и eBGP на каждый VRF. Изоляция строгая, масштаб слабый; безопасность та же, что на PE-CE.
  • Option B (MP-eBGP VPNv4 между ASBR): VPN-маршруты всех клиентов идут в одной сессии, и ASBR доверяет соседу авторство RT. Нужны фильтр по RT (Cisco ASBR без VRF по умолчанию отбрасывает VPNv4 без совпадающего локального RT, это отключается no bgp default route-target filter, так что на ASBR фильтр заменяют явной политикой), перезапись RT при разных пространствах RT и лимит префиксов на соседа. Метки, принятые на ASBR, должны быть выделены этим же ASBR; чужие метки без записи в LFIB отбрасываются.
  • Option C (multihop MP-eBGP между RR, транспортные /32 PE в BGP-LU): ASBR не видит VPN-маршрутов, а доверие максимальное. В eBGP-LU пропускают только /32 loopback PE/RR по prefix-list и принимают метки только для них; иначе соседний оператор получит доступ к любому внутреннему адресу.

Проверка поведением, а не конфигурацией

Изоляцию проверяют не только по конфигурации: из VRF A ищут маршрут в сторону префикса B (show ip route vrf A 10.220.0.0 не должен находить ничего, кроме опубликованного в общий VRF), сверяют список RT на экспортирующей и импортирующей сторонах (в show bgp vpnv4 unicast all <prefix> должны быть только ожидаемые RT) и следят за счётчиками лимита маршрутов. VRF не защищает ресурсы самого PE: адрес интерфейса PE в клиентском VRF доступен клиенту, а нагрузка на control plane общая; этим занимаются CoPP, ACL и uRPF в следующих уроках. Утечку в глобальную таблицу создают статические маршруты с ключом global (Cisco ip route vrf A 0.0.0.0 0.0.0.0 ... global) и импорт из VRF в global: в чек-лист аудита включите их поиск.

Что проверять в первую очередь

Для каждого VRF: список RT (show vrf detail), связанные map/policy, лимиты маршрутов, наличие MPLS на интерфейсах CE. Для общего VRF: что именно он экспортирует и импортирует. Для каждого клиента: show bgp vpnv4 unicast all <prefix> показывает RD и RT, принадлежащие только ему, плюс служебный RT общих сервисов.

Схема архитектуры и топология