Статья про L3VPN получилась большой — ни много ни мало 130 000 символов.

Учитывая, что и её ещё не все дочитали, эту часть про доступ в Интернет мы вынесли в отдельную публикацию.

Это особенно важно, потому что в рунете, да и вообще в интернетах, нет доступного разбора этой темы.

Вполне вероятно, что вы сейчас читаете эксклюзивный материал.

Итак, есть оператор связи, который предоставляет своему клиенту L3VPN. Ни с того ни с сего, с бухты да барахты понадобился ему ещё и Интернет.

Самое очевидное решение — прокинуть ещё один кабель — в одном VPN, в другом Интернет.

Допустим, это сложно. Тогда можно поднять сабинтерфейс и передавать фотки вконтактике в отдельном VLAN’е.

Допустим, там сложный арендованный канал, где можно прокинуть только 1 VLAN или оборудование клиента не умеет VLAN (стоит обычный компьютер), что тогда?

Об этом следующие 36 000 букв вашей жизни.

Итак, провайдер в тот же самый VPN продаёт и доступ в Интернет, через то же самое подключение, через те же адреса. Это значит, что в сети провайдера придётся где-то настроить доступ из приватной сети, в публичную, а следовательно обеспечить пересечение маршрутной информации.

Всё это непотребство имеет своё название — Route Leaking — маршруты протекают из VRF в глобальную таблицу. Название функционала говорящее — прибегать к Route Leaking’у особенно через статические маршруты нужно только в крайних случаях, ибо жуткий костыль.

Есть два подхода к реализации этого функционала:

1. Настройка статических маршрутов из VRF в публичную сеть и наоборот.
2. Жонглирование Route Target’ами.

Оба имеют право на жизнь.

Начнём со статики.

Ясное дело, нам понадобится NAT, чтобы спрятать частные сети.

Сценарии различаются лишь местом применения:

• В сети клиента — CE NAT.
• В сети провайдера на крайнем PE — PE NAT.
• В сети провайдера на точке выхода в Интернет — VRF Aware NAT.

NAT на CE

Провайдер выдаёт клиенту пул публичных адресов, в который тот транслирует свои внутренние. Всё, что остаётся сделать провайдеру — настроить маршрутизацию между VRF и глобальной таблицей. Учитывая, что трансляция будет на CE, нужно выбрать только один филиал, пусть это будет TARS_2 — там как раз у нас линковая сеть публичная — 100.0.1.0/30.

Как видите, для этого теста нам нужно что-то в качестве Интернета и компьютер, которому доступ туда нужен.

В GNS есть такой чудесный объект, как VPCS, который прекрасно подходит на эту роль.

На TARS_2 нужно настроить NAT, ниже его конфигурация:

TARS_2(config)#interface Loopback0
TARS_2(config-if)#ip address 172.16.255.2 255.255.255.255

TARS_2(config)#interface FastEthernet0/0
TARS_2(config-if)#description To Linkmeup
TARS_2(config-if)#ip address 100.0.1.2 255.255.255.252
TARS_2(config-if)#ip nat outside

TARS_2(config)#interface FastEthernet0/1
TARS_2(config-if)#description To LAN
TARS_2(config-if)#ip address 172.16.1.1 255.255.255.0
TARS_2(config-if)#ip nat inside

TARS_2(config)#router bgp 64502
TARS_2(config-router)#network 172.16.1.0 mask 255.255.255.0
TARS_2(config-router)#network 172.16.255.2 mask 255.255.255.255
TARS_2(config-router)#neighbor 100.0.1.1 remote-as 64500

TARS_2(config)#ip nat inside source list 100 interface FastEthernet0/0 overload

TARS_2(config)#access-list 100 deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
TARS_2(config)#access-list 100 permit ip 172.16.0.0 0.0.255.255 any

access-list 100 состоит из двух строк — первая запрещает трансляцию адресов для пакетов, которые идут из своей сети в свою же сеть, находящуюся на другом конце провайдера.

Вторая строка разрешает трансляцию только для адресов своей сети. Если вдруг вы пропишите permit ip any any, то сразу же упадёт BGP-сессия с Linkmeup_R3.

Подробности по настройке NAT были освещены в пятой части СДСМ.

Конфигурация Интернета:

Internet(config)#interface Loopback0
Internet(config-if)#ip address 101.0.0.101 255.255.255.255

Internet(config)#interface FastEthernet0/0
Internet(config-if)#description To linkmeup
Internet(config-if)#ip address 101.0.0.1 255.255.255.252

Internet(config)#router bgp 64501
Internet(config-router)#network 101.0.0.0 mask 255.255.240.0
Internet(config-router)#neighbor 101.0.0.2 remote-as 64500

Internet(config)#ip route 101.0.0.0 255.255.240.0 Null0

Настройки BGP на Internet точно такие же, как были в Балаган-Телекоме в восьмом выпуске, мы только позволили себе некоторые вольности с IP-адресами.

Интерфейс Loopback 0 на узле с именем Internet олицетворяет собой весь интернет. Пинг до него и будем проверять.

Соответствующим образом настроен и Linkmeup_R1 для связи с Internet:

Linkmeup_R1(config)#interface FastEthernet1/1
Linkmeup_R1(config-if)#description To Balagan-Telecom
Linkmeup_R1(config-if)#ip address 101.0.0.2 255.255.255.252

Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router)#network 100.0.0.0 mask 255.255.254.0
Linkmeup_R1(config-router)#network 101.0.0.0 mask 255.255.255.252
Linkmeup_R1(config-router)#neighbor 101.0.0.1 remote-as 64501

Linkmeup_R1(config)#ip route 100.0.0.0 255.255.254.0 Null0

Что же касается доступа в Интернет из VPN, то в данном случае конфигурацию нужно менять только на ближайшем к CE PE — в нашем случае Linkmeup_R3.

1. 1. Создадим маршрут по умолчанию для VRF TARS. Это для того, чтобы пакеты, пришедшие от TARS_2 не были отброшены и знали куда двигаться.

   Linkmeup_R3(config)#ip route vrf TARS 0.0.0.0 0.0.0.0 101.0.0.2 global
   

   Обратить внимание здесь нужно на две вещи:

   Ключевое слово global. Оно говорит о том, что Next Hop (101.0.0.2) нужно искать в глобальной таблице маршрутизации.

   В качестве адрес Next-Hop выбран линковый адрес Linkmeup_R1 в сторону Интернета. Почему не Loopback, как мы любим? Это позволяет избежать так называемого blackholing’a. Дело в том, что loopback всегда доступен, а в случае падения канала между нашим шлюзом (Linkmeup_R1) и Интернетом TARS_2 этого никак не заметит и продолжит слать трафик на Linkmeup_R3, а тот, тоже ничего не подозревая, на Linkmeup_R1. Если же мы укажем линковый адрес, то он пропадёт из таблиц маршрутизации сразу, как упадёт линия.

   В результате предыдущей операции на Linkmeup_3 появляется маршрут по умолчанию:
   

2. 2. Теперь его нужно сообщить клиенту, чтобы у того тоже появился маршрут по умолчанию (хотя он мог бы настроить его и самостоятельно).

   address-family ipv4 vrf TARS
   neighbor 100.0.1.2 default-originate
   

   Результат:
   
   Итак, маршруты туда, то есть в Интернет, у нас уже есть, теперь что касается обратно.

3. 3. На Linkmeup_R3 настроим статический маршрут для сети 100.0.1.0/30:

   ip route 100.0.1.0 255.255.255.252 FastEthernet1/0
   

   Зачем нам это нужно? Чтобы был маршрут, логично ведь. Если из Интернета пакет прилетит на Linkmeup_R3, а на нём не будет маршрута к 100.0.1.0/30 в глобальной таблице маршрутизации (в VRF-то он, конечно, будет), пакет будет отброшен.

   Было:
   
   Маршрут-то есть, да только не туда. Пакет не будет отброшен, но и до адресата не дойдёт.

   Стало:
   
   4. Далее об этой сети нужно сообщить BGP-соседям — о ней должны узнать все. В частности нас интересует Linkmeup_R1.

   router bgp 64500
   network 100.0.1.0 mask 255.255.255.252
   

Результат:

BGP в принципе и прежде знал об этой сети, но только в address-family ipv4 vrf TARS, куда она попадала с помощью команды redistribute connected. В глобальной же таблице маршрутизации её не было.

Итак, всё готово, проверяем:

Это говорит о том, что заработал Route Leaking, то есть доступ из VRF в глобальную таблицу маршрутизации и наоборот работает.

Проверка доступности Интернета с компьютера — это формальность, которая покажет, что мы правильно настроили NAT. Фактически вся магия происходит на Linkmeup_R3, а знакомая нам трансляция на TARS_2, то есть вещи это по большому счёту не связанные, и, если Интернет доступен с TARS_2, он будет доступен и с PC1.

Однако мы проверим:

Интернет доступен. Ура!

Повторим шаги настройки:

• Настроить NAT. На CE.
• Настроить маршрут по умолчанию в сторону интернета для VRF с указанием Next Hop и ключевым словом Global. На PE.
• Заставить PE анонсировать данный маршрут по умолчанию клиенту. На PE.
• Настроить маршрут в глобальной ТМ в сторону клиента с указанием выходного интерфейса. На PE.
• Сообщить этот маршрут MBGP-соседям, а точнее тому узлу, который смотрит в Интернет. На CE.

Полная конфигурация интересных нам узлов.

Описанная конфигурация и есть Route Leaking.

Тут мы опустим сценарий с NAT на крайнем PE, потому что он неинтересный.

VRF-Aware NAT

Более правильный и чуть более масштабируемый вариант — настройка трансляции на Egress PE — на выходе в Интернет. В этом случае у нас есть центральный узел, где выполняются все операции, а клиенту не нужно делать ничего.

Единственное неудобство: несмотря на то, что, возможно, ни один клиент не подключен к Egress PE непосредственно, этому маршрутизатору придётся поддерживать все VRF, из которых нужно получать доступ в Интернет. Собственно, поэтому он и VRF-Aware.

Egress PE в нашем случае — Linkmeup_R1, который является шлюзом в интернет для всей сети linkmeup — никаких абсолютно дополнительных настроек на других узлах. Пусть PC2 из сети C3PO Electronic (C3PO_2) хочет получить доступ в Интернет.

PC1 из TARS’ Robotics не трогаем и оставляем без изменений — они со своими белыми адресами — отдельная история, хотя их тоже вполне можно натить таким же образом.

1) Итак, во-первых на Linkmeup_R1 должен быть VRF C3PO. Он уже есть, но если бы не было, нужно было бы, чтобы было бы.

Конфигурация VRF типичная и она не поменялась:

Linkmeup_R1(config)#ip vrf C3PO
Linkmeup_R1(config-vrf)#rd 64500:100
Linkmeup_R1(config-vrf)#route-target export 64500:100
Linkmeup_R1(config-vrf)#route-target import 64500:100

2) Настраиваем NAT

Включаем ip nat inside в ту сторону, откуда получаем пакеты для трансляции, то есть в сторону P-маршрутизатора Linkmeup_R2:

Linkmeup_R1(config)#interface FastEthernet 0/1
Linkmeup_R1(config-if)#ip nat inside

В сторону Интернета включаем ip nat outside:

Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip nat outside

Создаём ACL, где разрешаем доступ из сети C3PO в интернет:

Linkmeup_R1(config)#access-list 100 permit ip 192.168.0.0 0.0.255.255 any

И собственно сам NAT:

Linkmeup_R1(config)#$ip nat inside source list 100 interface FastEthernet1/1 vrf C3PO overload

3) В BGP, как и в прошлый раз, прописываем отправку маршрута по умолчанию в данный VRF:

Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router)#address-family ipv4 vrf C3PO
Linkmeup_R1(config-router-af)#redistribute static
Linkmeup_R1(config-router-af)#default-information originate

Поосторожней с редистрибьюцией в продакшне. Используй только вместе с фильтрацией.

Заметьте, что здесь недостаточно одной только команды redistribute static, чтобы забрать и анонсировать маршрут по умолчанию. Для этого дополнительно придётся выполнить явно команду default-information originate.

Чтобы этот маршрут анонсировался BGP, нужно, чтобы он был в таблице маршрутизации:

Linkmeup_R1(config)#ip route vrf C3PO 0.0.0.0 0.0.0.0 101.0.0.1 global

Сейчас сразу не заработает, потому что я слегка слукавил, говоря, что никакие настройки нигде кроме интернет-шлюза не понадобятся.

Дело в том, что мы сгенерировали маршрут по умолчанию для VRF C3PO на Linkmeup_R1 и по BGP передали его на Linkmeup_R3, но тут он и застрял, не дойдя до C3PO_2 — нужно заставить OSPF анонсировать маршрут по умолчанию. Как и в предыдущий раз без явной команды default-information originate он этого делать не будет:

Linkmeup_R3(config)#router ospf 2 vrf C3PO
Linkmeup_R3(config-router)# default-information originate

Проверяем:

Было бы странно, если бы не заработало.

Полная конфигурация узлов для VRF Aware NAT.

Это был тот же Route Leaking.

Common Services

До сих пор мы обсуждали задачу передачи трафика из VPN в публичные сети и обратно.

Ещё один подход к предоставлению доступа в Интернет — вывести его в отдельный VRF.

Строго говоря — он наиболее масштабируемый, потому что нет необходимости настраивать что-то индивидуально для каждого клиентского VRF.

Важное условие — NAT происходит в сети клиента и в VRF Internet импортируются только маршруты к публичным префиксам клиента.

Common Services, который часто называют Shared Services — это продолжение вопроса о взаимодействии между VRF, который мы рассмотрели ранее. Основная идея в том, что экспорт/импорт совершается засчёт особой настройки route-target. Только на этот раз нужно ограничить список передаваемых префиксов, чтобы избежать пересечения адресных пространств и разрешить только публичные маршруты.

Рассмотрим задачу снова на примере TARS, потому что у них уже есть публичные сети.

1. 1) На шлюзе мы создаём VRF Internet.

   Linkmeup_R1(config)#ip vrf Internet
   Linkmeup_R1(config-vrf)#rd 64500:1
   Linkmeup_R1(config-vrf)#route-target import 64500:11
   Linkmeup_R1(config-vrf)#route-target export 64500:22
   

   Обратите внимание, что route-target на импорт и на экспорт в этот раз разные и сейчас станет понятно почему.

2. 2) Перенести интерфейс в сторону Интернета в VRF:

   Linkmeup_R1(config)#interface FastEthernet 1/1
   Linkmeup_R1(config-if)#ip vrf forwarding Internet
   Linkmeup_R1(config-if)#ip address 101.0.0.2 255.255.255.252
   

3. 3) Перенести BGP-соседство с маршрутизатором в Интернете в address-family ipv4 vrf Internet:

   Linkmeup_R1(config-router)#router bgp 64500
   Linkmeup_R1(config-router)#no neighbor 101.0.0.1 remote-as 64501
   Linkmeup_R1(config-router)#address-family ipv4 vrf Internet
   Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 remote-as 64501
   Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 activate
   

4. 4) Объявляем маршрут по умолчанию:

   Linkmeup_R1(config)#router bgp 64500
   Linkmeup_R1(config-router-af)#network 0.0.0.0 mask 00.0.0.0
   Linkmeup_R1(config-router-af)#default-information originate
   

   Linkmeup_R1(config)#ip route vrf Internet 0.0.0.0 0.0.0.0 101.0.0.1
   

5. 5) В клиентском VRF TARS нужно также настроить RT:

   Linkmeup_R1(config-vrf)#ip vrf TARS
   Linkmeup_R(config-vrf)# route-target both 64500:200
   Linkmeup_R1(config-vrf)# route-target export 64500:11
   Linkmeup_R1(config-vrf)# route-target import 64500:22
   

Итак, помимо собственного RT, который обеспечивает обмен маршрутной информацией с другими филиалами (64500:200), здесь настроены и те RT, которые и для VRF Internet, но наоборот:

• то, что было на экспорт в VRF Internet (64500:22), то стало на импорт в VRF TARS
• то, что было на импорт в VRF Internet (64500:11), то стало на экспорт в VRF TARS

Почему так? Почему нельзя просто дать route-target both 64500:1, например, на всех VRF?

Основная идея концепции Common Service — предоставить доступ к нужному VRF клиентам, но не позволить им общаться друг с другом напрямую, чтобы обеспечить изоляцию, как того требует определение VPN.

Если настроить одинаковый RT на всех VRF, то маршруты будут спокойно ходить между ними.

При указанной же выше конфигурации у всех клиентских VRF есть RT 64500:22 на импорт (все будут получать маршруты Internet), и также у них есть RT 64500:11 на экспорт, но только у VRF Internet есть такой RT 64500:11 на импорт — только VRF Internet будет получать маршруты клиентов. Друг с другом они обмениваться не смогут. Главное, чтобы Internet не занялся филантропией и не начал маршрутизировать клиентский трафик.

Итак, в результате наших операций мы можем видеть следующее:

На TARS_2 всё в порядке. На Linkmeup_R1 есть маршрут до сети 100.0.0.0/30, но есть и лишние маршруты до частных сетей:

И в этом случае у нас даже будет интимная связность:

Но что делать с этими лишними маршрутами в VRF Internet? Ведь если мы подключим ещё один VRF так же, у нас и от него появятся ненужные серые подсети.

Тут как обычно поможет фильтрация. А если конкретно, то воспользуемся prefix-list + route-map:

Linkmeup_R1(config)#ip prefix-list 1 deny 172.16.0.0/12 le 32
Linkmeup_R1(config)#ip prefix-list 1 deny 192.168.0.0/16 le 32
Linkmeup_R1(config)#ip prefix-list 1 deny 10.0.0.0/8 le 32
Linkmeup_R1(config)#ip prefix-list 1 permit 0.0.0.0/0 le 32

Первые три строки запрещают анонсы всех частных сетей. Четвёртая разрешает все остальные.

В нашем случае вполне можно было бы обойтись одной строкой: ip prefix-list 1 permit 100.0.0.0/23 le 32 — вся подсеть Linkmeup, но приведённый нами пример более универсальный — он допускает существование других публичных сетей и соответственно один prefix-list может быть применён для всех VRF.

Следующая конструкция применяет расширенное community к тем префиксам, что попали в prefix-list 1, иными словами устанавливает RT:

Linkmeup_R1(config-map)#route-map To_Internet permit 10
Linkmeup_R1(config-map)#match ip address prefix-list 1
Linkmeup_R1(config-map)#set extcommunity rt 64500:11

Осталось дело за малым — применить route-map к VRF:

Linkmeup_R1(config)#ip vrf TARS
Linkmeup_R1(config-vrf)#export map To_Internet

После обновления маршрутов BGP (можно форсировать командой clear ip bgp all 64500) видим, что в VRF Internet остался только публичный маршрут:

И, собственно, проверка доступности Интернета с PC1 (NAT уже настроен на TARS_2):

Уважаемые читатели, вы только что ознакомились с другим подходом к Route Leaking‘у.

Полная конфигурация всех узлов для Common Services.

Полезные ссылки

Наиболее доступно тема Common Services описана Jeremy Stretch. Но у него нет указания на то, что префиксы нужно фильтровать.

Вообще, у них там в ихних америках, все друг друга знают и уважают. Поэтому Джереми охотно ссылается на Ивана Пепельняка, а точнее его заметку о Common Services, а Иван в свою очередь на Джереми. Статьи их дополняют друг друга, но опять же до конца тему не раскрывают.

А вот и третья ссылка, которая в купе с первыми двумя позволяет сложить какое-то представление о том, как работает Common Services.

Все виды доступа в Интернет из VRF описаны в данной статье. Но она настолько запутанная, что именно поэтому я и решил посвятить отдельный микровыпуск СДСМ вопросу настройки этого функционала.

В целом же про MPLS и его приложения, в том числе L3VPN, можно глубоко почитать у Ina Minei, Julian Lucek. MPLS-Enabled Applications.

В этом году ждите СДСМ12. MPLS L2VPN. Напоминаю, что все выпуски СДСМ теперь удобно собраны на отдельной странице.

Автор
eucariot — Марат Сибгатулин (inst, tg, in)

Оставайтесь на связи

Канал в телеграме: t.me/linkmeup_podcast
Канал на youtube: youtube.com/c/linkmeup-podcast
Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
Сообщество в вк: vk.com/linkmeup
Группа в фб: www.facebook.com/linkmeup.sdsm
Добавить RSS в подкаст-плеер.
Пообщаться в общем чате в тг: https://t.me/linkmeup_chat

Поддержите проект: