return

Сети для самых маленьких. Микровыпуск № 6. MPLS L3VPN. Доступ в Интернет

8 декабря 2015, 19:20

В догонку к выпуску про L3VPN публикую статью о доступе в Интеренте из VPN.
Эта тема очень плохо раскрыта в рунете. Мне не удалось найти сколько-нибудь вменяемого описания что это вообще такое.
Восполняя этот пробел, я сначала добавил этот параграф в основню статью, но длина в 170 000 символов напугала даже меня.
В общем, вполне вероятно, что вы сейчас читаете эксклюзивный материал.
Отталикваемся от следующей сети: Доступ в Интернет из L3VPN Вся конфигурация VPN уже выполнена C3PO слева видит C3PO справа. А TARS справа видит TARS слева.
Чтобы вы не рыскали в поисках настроек, я их собрал тут (без Интернета).
Итак, может статься, что провайдер в тот же самый VPN продаёт и доступ в Интернет. Именно в VPN, не отдельный кабель, не отдельный VLAN, а именно доступ в Интернет через то же самое подключение, через те же адреса. Это может быть также капризом заказчика.
Ясное дело, что понадобится NAT, чтобы спрятать частные сети.
Так вот: есть 3 подхода к реализации этого функционала, которые различаются лишь местом, где происходит трансляция адресов:

  1. В сети заказчика, например, на CE.
  2. На Ingress PE — маршрутизаторе, к которому подключен CE.
  3. На Egress PE — маршрутизаторе, который подключен к Интернету.

Каждый из них имеет право на жизнь. Рассмотрим все.

NAT на CE

Такой NAT возможен, например, когда у клиента уже есть публичные адреса. Тогда в этот пул транслируются внутренние адреса. Всё, что остаётся сделать провайдеру — настроить маршрутизацию между 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 64520
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 64510
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 64510

Linkmeup_R1(config)#ip route 100.0.0.0 255.255.254.0 Null0

Что же касается доступа в Интернет из VPN, то в данном случае конфигурацию нужно менять только на ближайшем к CE PE — в нашем случае Linkmeup_R3.
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. Теперь его нужно сообщить клиенту, чтобы у того тоже появился маршрут по умолчанию (хотя он мог бы настроить его и самостоятельно).

Linkmeup_R3(config-router)# address-family ipv4 vrf TARS
Linkmeup_R3(config-router)# neighbor 100.0.1.2 default-originate

Результат: Итак, маршруты туда, то есть в Интернет, у нас уже есть, теперь что касается обратно.
3. На Linkmeup_R3 настроим статический маршрут для сети 100.0.1.0/30:

Linkmeup_R3(config)№ ip route 100.0.1.0 255.255.255.252 FastEthernet1/0

Зачем нам это нужно? Чтобы был маршрут, логично ведь. Если из Интернета пакет прилетит на Linkmeup_R3, а на нём не будет маршрута к 100.0.1.0/30 в глобальной таблице маршрутизации (в VRF-то он, конечно, будет), пакет будет отброшен.
Было: Маршрут-то есть, да только не туда. Пакет не будет отброшен, но и до адресата не дойдёт.
Стало: 4. Далее об этой сети нужно сообщить BGP-соседям — о ней должны узнать все. В частности нас интересует Linkmeup_R1.

Linkmeup_R3(config)#router bgp 64500
Linkmeup_R3(config-router)#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.
Однако мы проверим: Интернет доступен. Ура!

Если вам интересно, давайте проследим, что происходит с пакетом по пути от PC1 до Internet.

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

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

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

VRF-Aware NAT

Более правильный и чуть более масштабируемый вариант — настройка трансляции на Egress PE — на выходе в Интернет. В этом случае у нас есть централизованный узел, где выполняются все операции и нет необходимости в Route Leaking’е через статические маршруты. Единственное неудобство: несмотря на то, что ни один клиент может быть не подключенным к этому маршрутизатору, ему придётся поддерживать все 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 FastEthernet 1/1 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.

Common Services

До сих пор мы обсуждали задачу передачи трафика из VPN в публичные сети и обратно.
Ещё один подход к предоставлению доступа в Интернет — вывести его в отдельный VRF.
Строго говоря — он наиболее масштабируемый, потому что нет необходимости настраивать что-то индивидуально для каждого клиентского VRF.
Если говорить о доступе в Интернет, то важное условие — NAT происходит в сети клиента и в VRF Internet импортируются только маршруты к публичным префиксам.
Common Services, который часто называют Shared Services — это продолжение вопроса о взаимодействии между VRF, который мы рассмотрели ранее. Основная идея в том, что экспорт/импорт совершается засчёт особой настройки route-target. Только на этот раз нужно ограничить список передаваемых префиксов, чтобы избежать пересечения адресных пространств и разрешить только публичные маршруты.
Рассмотрим задачу снова на примере TARS, потому что у них уже есть публичные сети.
На шлюзе мы создаём 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) Перенести интерфейс в сторону Интернета в 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) Перенести 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 64510
Linkmeup_R1(config-router)#address-family ipv4 vrf Internet
Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 remote-as 64510
Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 activate

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) В клиентском 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): Полная конфигурация всех узлов для Common Services.
Наиболее доступно тема Common Services описана Jeremy Stretch. Ноу него нет указания на то, что префиксы нужно фильтровать.
Вообще, у них там в ихних америках, все друг друга знают и уважают. Поэтому Джереми охотно ссылается на наше всё Ивана Пепельняка, а точнее его заметку о Common Services, а Иван в свою очередь на Джереми. Статьи их дополняют друг друга, но опять же до конца тему почему-то не раскрывают.
А вот и третья ссылка, которая в купе с первыми двумя позволяет сложить какое-то представление о том, как работает Common Services.
Все виды доступа в Интернет из VRF описаны в данной статье. Но она настолько запутанная, что именно поэтому я и решил посвятить такой большой кусок статьи настройке этого функционала.
Ещё раз приведу все ссылки на информацию о доступе в Интернет из VRF:
Все способы организации: Providing Internet Access for MPLS L3 VPNs.
Тот же Jeremy Stretch. MPLS VPN with Common Services.
Иван Пепельняк. MPLS VPN Common Services Design

Мне почему-то тяжеловато читать примеры конфигурации cisco, но лучше них эту тему пока никто не раскрыл: NAT — Integration with MPLS VPN.

like 206 views 2072 message 0

0 коментариев

Ещё статьи

Что происходит с главной 3. Не в последний раз.
Linkmeup растёт и развивается, и на этот раз новость будет о том, как у нас в друзьях появился самый матёрый и крупный коммерческий ЦОД всея Руси – это, конечно же, ...
like 575 1118 0
5 августа 2020
Анонс подкаста. Выпуск 24
21-го февраля 24-м выпуском подкаста linkmeup мы открываем большую тему виртуализации и SDN — серия радиошоу погрузит вас в этот удивительный и чуждый для сетевого инженера мир. В гостях Александр ...
like 0 4449 29
16 февраля 2015
Где сохранить пакет? Чипы и буферы
Эта статья едва ли для широкого круга читателей, но будет небезынтересна тем, кто хотел бы знать, сколько максимум пакет может полежать где-нибудь в сети, добираясь от точки А к точке ...
like 1 7962 0
1 июня 2020