return

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

1 августа 2016, 20:00

Статья про 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.

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

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

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

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

  • Настроить 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

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

like 248 views 58083 message 9

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

  • Дмитрий Максименко

    Common Services, пункт 5)
    Всю голову сломал, почему не работает) Оказалось, что нужно делать на R3 а не R1 этот пункт 🙂 Исправьте.

    27 июня 2019, 04:05
  • Здравствуйте. Подскажите пожалуйста. В секции «Common Service» пункт №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

    Разве эти команды не должны быть выполнены в address-family ipv4 vrf Internet?
    Благодарю.

    13 января 2019, 00:56
  • Доброго времени суток. Отличная статья.
    мне кажется или для маршрутизатора Linkmeup_R1 отсутствует конфигурационный файл если зайти по ссылке
    Полная конфигурация всех узлов для Common Services.

    21 мая 2018, 16:16
  • Юрий Телятников

    Добрый День.
    Мне кажется или здесь опечатка.

    5 августа 2016, 10:51
  • Добрый день! Очень полезная статья! Один вопрос, если нужно и НАТить и белые адреса на интерфейс клиенту, какой подход тогда лучше выбрать? Насколько я понял через MP-BGP vrf и global ликовать нельзя?

    2 августа 2016, 06:30
  • Дмитрий Максименко

    Дальнейшая фильтрация prefix-list + route-map
    тоже нужно делать на R3, а не R1 🙂

    27 июня 2019, 08:58
  • Верно! Спасибо! Исправлено!

    6 августа 2016, 08:41
  • Добрый день! Спасибо за ответ. Объясню.
    Допустим, в vrf Clients есть два вида пользователей:
    а) С серыми адресами на интерфейсе. Им нужен NAT или PAT
    б) С белыми адресами на интерфейсе. Им нужна маршрутизация белой сети.

    Какой выбрать подход, чтобы угодить всем? 🙂

    Можно занатить через глобал, но тогда нельзя маршрутизировать белые адреса (из глобал в vrf Clients). Если положить аплинк от отдельный vrf Uplink, тогда с маршрутизацией все ясно, но как быть с НАТом?

    5 августа 2016, 05:13
  • Привет. VRF и Global через BGP не получится, это верно. Вопрос до конца не понял: натить белые в белые?

    4 августа 2016, 20:17

Ещё статьи

linkmeup и Миран. Или что происходит с главной 2.
Самые внимательные уже заметили перемены на главной и даже нашли им объяснение. На этот раз к нам приехал логотип Мирана, и наконец-то пропали мертворожденный Форум и завершённый CCIE за год. ...
like 0 4357 0
26 марта 2018
Анонс подкаста онлайн
Пришло время подкасту сделать небольшой шаг вперёд. 20-й выпуск будет в тестовом режиме транслироваться в реальном времени. Впервые в истории linkmeup. Сегодня, 19-го октября в 15:00 по московскому времени на ...
like 0 7630 38
14 октября 2014
Анонс подкаста sysadmins. Выпуск 8. "Жёлтая программа" \\\\25.11 13:00 Мск
Они сдулись и скатились! Они будут рассказывать про 1С! Ну что ж, да, мы будем рассказывать про 1С. Но я уверен, что таких рассказов вы мало где услышите, а все ...
like 393 4958 0
22 ноября 2018