Услуги vpn l3 что это
L3VPN
Введение
Рассмотрим, что такое услуга L3-VPN, что она из себя представляет и зачем нужна. L3-VPN это услуга/сервис виртуальной частной сети, которая предоставляется операторами связи на ряду с L2-VPN и VPLS. Данная услуга уже работает на 3 уровне модели OSI (на уровне IP) по принципу точка-многоточка. Она позволяет объединять сети офисов/магазинов заказчиков в единую. Обмен пакетами клиентов происходит через сеть провайдера. Для организации L3-VPN от клиента уже требуется пограничное оборудование выполняющее роль маршрутизатора (на языке операторов связи, пограничное оборудование клиента называется CE-Customer Edge).
L3-VPN с точки зрения клиента.
Представим, что у вы владеете несколькими магазинами и перед вами стоит задача связать локальные сети этих магазинов в одну единую, которая будет абсолютно изолирована для других.
Задача: объединить супермаркет в селе Угрюмое, алкогольный магазин в деревне Колышки и магазин стройматериалов в г. Саратов.
Вы решили воспользоваться услугой L3VPN, выбрали провайдера, который не «загнул» цену на этот сервис. С точки зрения вас, как клиента, данная услуга будет выглядеть, как показано на рисунке 1,
т.е. так, как будто все ваши магазины подключены к одному маршрутизатору провайдера: деревня Колышки отдает посредством протокола динамической маршрутизации свою сеть провайдеру и принимает ваши сети из г. Саратов и села Угрюмое.
L3-VPN с точки зрения провайдера.
В данном случае задача сети провайдера прикинуться маршрутизатором. В реальном виде она может быть огромна. Оборудование клиента будет подключено в ближайший пограничный коммутатор оператора связи, а соединение посредством протокола динамической маршрутизации будет осуществлено с его ближайшим маршрутизатором (на языке операторов связи, пограничный маршрутизатор провайдера к которому подключается клиент называется PE-Provider Edge).
Под облачком может скрываться до сотни устройств с протяженностью сети провайдера в несколько тысяч километров, однако, вы об этом не узнаете. При всем при этом, чтобы настроить данную услугу, администратору оператора связи требуется от силы 20 минут работы. А случае, если вам потребуется подключить дополнительный магазин, то провайдеру надо всего-лишь произвести настройки на том маршрутизаторе к которому он будет подключен, чтобы добавить его в вашу единую сеть, сеть клиента.
Какие существуют разновидности VPN и чем они отличаются
В прошлой статье мы разобрались с тем, что такое VPN. Теперь познакомимся с конкретными реализациями этой технологии и кратко расскажем об их преимуществах и недостатках.
Итак, в прошлый раз мы разобрались с тем, что такое технология VPN, где она нужна и зачем используется. В этот раз мы познакомимся с ее конкретными реализациями и кратко расскажем об их преимуществах и недостатках.
Само по себе определение VPN (виртуальная частная сеть) довольно широко, и с ходу трудно сказать, что можно считать VPN, а что нет. С определенной натяжкой VPN можно назвать и прародительницу Интернета ARPANET. Любопытно, что почти все технологии, а чаще всего все-таки протоколы, изначально применявшиеся для построения распределенных корпоративных сетей, постепенно становились основными способами доступа в Сеть для обычных пользователей.
Впрочем, ни дела давно минувших дней, ни заботы корпоративные нас не волнуют. С чисто практической точки зрения следует кратко познакомиться с теми вариациями VPN, которые неподготовленный и не шибко разбирающийся в сетевых технологиях пользователь сможет встретить на своем пути.
В первую очередь стоит рассмотреть те из них, что помогут защититься при использовании публичного Wi-Fi-доступа и позволят обойти блокировки тех или иных ресурсов. Как правило, доступные частным пользователям VPN-сервисы опираются на возможности популярных ОС и предлагают самостоятельно настроить с помощью пошаговой инструкции подключение к ним.
В последнее время сервисы VPN еще больше упростили этот процесс — они скрывают технические детали и доводят его до уровня «сюда положить денежку, отсюда скачать программку, нажать эту кнопочку и радоваться жизни, не забывая пополнять баланс личного счета». Тем не менее в некоторых случаях может быть полезно понимать, чем одни вариации VPN отличаются от других.
Настройки VPN в операционных системах Android (слева) и Windows (справа)
Популярные типы VPN
PPTP (Point-to-Point Tunneling Protocol) появился 20 лет назад, и в этом заключаются как его достоинства, так и недостатки. Несомненный плюс этого протокола — он поддерживается буквально всеми ОС, даже очень старыми. За счет этого достигается определенная универсальность и доступность. К тому же по современным меркам он очень нетребователен к вычислительным ресурсам.
Обратная сторона медали — из-за столь солидного возраста нынче он предлагает низкий уровень защиты пользователя. Казавшиеся достаточно надежными в середине 1990-х методы шифрования по нынешним меркам слабы и сочетаются с не самой удачной архитектурой и рядом ошибок в самой популярной реализации протокола от Microsoft.
Кроме того, по умолчанию шифрование вообще не предлагается, а взлом пароля на современном аппаратном обеспечении возможен менее чем за сутки. Тем не менее в тех случаях, когда защита подключения не так важна или когда нет иных вариантов VPN-подключений, то уж лучше использовать PPTP с шифрованием, чем вообще без него.
Мне однажды удалось попасть в не очень приятную ситуацию в одной из стран с особым (если вы понимаете, о чем я) отношением к Интернету. Отправка электронной почты через корпоративный PPTP-сервер на родине закончилась тем, что письма, высланные в течение одного дня, были доставлены адресату с задержкой от пары дней до пары недель. Где и почему они «путешествовали», читатель может предположить сам. Использование же иных, более надежных вариантов VPN пресекалось.
Китайцы классно придумали: для масштабирования своей VPN-сети они просто взламывают чужие Windows-серверы — https://t.co/6uLwtNNl7p
L2TP (Layer 2 Tunneling Protocol) во многом схож с PPTP. Эти стандарты разрабатывались и были приняты практически одновременно, но L2TP считается более эффективным для построения виртуальных сетей, хотя и чуточку более требователен к вычислительным ресурсам по сравнению с PPTP. Фактически же он используется интернет-провайдерами и корпоративными пользователями. Обратите внимание, что L2TP по умолчанию также не предлагает шифрования и используется одновременно с другими протоколами — как правило, это IPSec.
IPSec (Internet Protocol Security) — это целый набор протоколов, стандартов и рекомендаций, специально разработанный для создания безопасных соединений в Сети. Первые наработки тоже появились в начале 1990-х годов, однако изначально была поставлена цель не «высечь IPSec в граните», а регулярно дорабатывать его для соответствия духу времени.
И да, в связи со всякими известными событиями в очередной раз рекомендуем всем вам почаще использовать VPN: http://t.co/kdx7t7tQzb
Нетрудно догадаться, для ведомств какого характера велись эти разработки. Набор IPSec состоит из десятков стандартов (и каждый из них внутри себя имеет не одну версию), описывающих различные этапы работы с защищенными соединениями. Он действительно хорош и с точки зрения архитектуры, и с точки зрения надежности используемых алгоритмов, и с точки зрения возможностей.
При всех достоинствах IPSec у него есть и недостатки. Во-первых, для неподготовленного пользователя он очень сложен в настройке, что, в свою очередь, чревато снижением уровня защиты в том случае, если что-то сделано неправильно. К тому же, как было отмечено, он нередко используется в совокупности с другими технологиями.
Во-вторых, он гораздо требовательнее к вычислительным ресурсам. Отчасти этот недостаток компенсируется использованием аппаратного ускорения некоторых вариантов алгоритма шифрования AES — именно он предлагается в современных версиях IPSec, хотя есть и другие варианты алгоритмов. Подобные ускорители уже есть в современных процессорах как для настольных, так и для мобильных устройств, а также для Wi-Fi-роутеров.
К сожалению, то, что хорошо продумали теоретики (математики в первую очередь), в жизнь претворяют практики, далеко не всегда обладающие достаточным уровнем знания и понимания предметной области. Исследование, опубликованное в октябре 2015 года, показывает, что до 66% IPSec-подключений могут быть относительно легко взломаны и что АНБ США может обладать подходящим аппаратным обеспечением для такого взлома.
Непростые простые числа, криптография в HDD, патчи Adobe и другие интересные события недели https://t.co/yxQcGKECLd pic.twitter.com/1cUaKH1kSn
Проблема кроется в некорректном использовании алгоритмов для инициализации защищенных соединений. Причем это касается не только IPSec, но и TLS с SSH, а также TOR и OTR. То есть имеется потенциальная возможность прочтения не только VPN-подключений, но и защищенных соединений для ряда сайтов, почтовых серверов, мессенджеров и так далее.
Да, для реализации подобной атаки требуются довольно долгие приготовления и хорошие вычислительные ресурсы, но в данном случае примечательно, что исследователи использовали облачные технологии Amazon и, судя по всему, потратили сумму, вполне подъемную и для частного лица.
После такой подготовки время на атаку сокращается до минуты в лучшем случае или до месяца — в худшем. Впрочем, некоторые эксперты скептически отнеслись к данному исследованию — они утверждают, что в реальности процент уязвимых систем не так велик, хотя к некоторым аспектам исследования действительно стоит отнестись очень серьезно, а разработчики потенциально уязвимого ПО уже выпустили или планируют обновления и предупредили пользователей.
Интересно, хотя и немного сложное в понимании, продолжение истории с расшифровкой VPN-трафика: https://t.co/PcuUNyLURw
SSL (Secure Sockets Layer) и TLS (Transport Layer Security) VPN, как видно из названия, представляют целый класс решений, опирающихся на соответствующие протоколы SSL и TLS, иногда дополненные другими методами защиты. Собственно говоря, SSL/TLS каждый из вас встречал в первую очередь на веб-сайтах, включая и тот, что вы читаете прямо сейчас: префикс https и зеленый замочек в адресной строке говорят об использовании именно этих протоколов защиты соединения.
Первые версии протокола появились еще в прошлом веке, но активно использоваться стали только в этом. Широкая распространенность этих протоколов способствовала их детальному изучению и последовательному выявлению все новых и новых уязвимостей как в архитектуре, так и в конкретных реализациях. SSL 3.0 был упразднен в июне 2015 года, актуальной на текущий момент является версия TLS 1.2, однако полностью безопасной считать ее нельзя — многое опять-таки зависит от реализации (см. IPSec). Кроме того, оба протокола вынуждены нести на себе тяжкий груз обратной совместимости.
Плюсом SSL/TLS VPN является то, что из-за широкого применения этих протоколов в Интернете они беспрепятственно пропускаются практически всеми публичными сетями. Минус — не слишком высокая производительность на практике и сложность в настройке, а также необходимость установки дополнительного ПО.
Популярными реализациями SSL/TLS VPN являются OpenVPN (SSL 3.0/TLS 1.2) и Microsoft SSTP (SSL 3.0). Фактически SSTP привязан к платформе Windows. OpenVPN в силу своей открытости имеет множество реализаций практически для всех платформ и к тому же на данный момент считается наиболее надежным вариантом VPN.
Заключение
Мы перечислили лишь самые популярные у частных пользователей типы VPN. Впрочем, за годы развития этой технологии у нее появилось бессчетное множество вариаций. Одни только решения для корпоративного и телекоммуникационного секторов чего стоят.
И три главных совета от нашего эксперта напоследок: шифруйте свои данные, используйте VPN и регулярно обновляйте ПО #KasperskySMB
Обычному же пользователю я советую использовать, если это вообще возможно, только OpenVPN в силу его открытости, надежности и защищенности. Впрочем, и для него, и для других типов VPN есть еще ряд хитрых нюансов технического и юридического характера, о которых мы поговорим в следующем материале.
Сети Для Самых Маленьких. Микровыпуск №6. MPLS L3VPN и доступ в Интернет
Статья про L3VPN получилась большой — ни много ни мало 130 000 символов.
Учитывая, что и её ещё не все дочитали, эту часть про доступ в Интернет мы вынесли в отдельную публикацию.
Это особенно важно, потому что в рунете, да и вообще в интернетах, нет доступного разбора этой темы.
Вполне вероятно, что вы сейчас читаете эксклюзивный материал.
Итак, есть оператор связи, который предоставляет своему клиенту L3VPN. Ни с того ни с сего, с бухты да барахты понадобился ему ещё и Интернет.
Самое очевидное решение — прокинуть ещё один кабель — в одном VPN, в другом Интернет.
Допустим, это сложно. Тогда можно поднять сабинтерфейс и передавать фотки вконтактике в отдельном VLAN’е.
Допустим, там сложный арендованный канал, где можно прокинуть только 1 VLAN или оборудование клиента не умеет VLAN (стоит обычный компьютер), что тогда?
Об этом следующие 36 000 букв вашей жизни.
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:
Internet(config)#interface FastEthernet1/1
Internet(config-if)#description To Balagan-Telecom
Internet(config-if)#ip address 101.0.0.2 255.255.255.252
Internet(config)#router bgp 64500
Internet(config-router)#network 100.0.0.0 mask 255.255.254.0
Internet(config-router)#network 101.0.0.0 mask 255.255.255.252
Internet(config-router)#neighbor 101.0.0.1 remote-as 64501
Internet(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. Теперь его нужно сообщить клиенту, чтобы у того тоже появился маршрут по умолчанию (хотя он мог бы настроить его и самостоятельно).
address-family ipv4 vrf TARS
neighbor 100.0.1.2 default-originate
Результат:
Итак, маршруты туда, то есть в Интернет, у нас уже есть, теперь что касается обратно.
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.
Однако мы проверим:
Интернет доступен. Ура!
1) Обычным образом пакет попадает на шлюз по умолчанию — TARS_2
2) TARS_2 видит, что адрес назначения подпадает только под маршрут по умолчанию, передаёт пакет в интерфейс FE0/0 на Linkmeup_R3.
В последний момент он замечает, что заголовок пакета полностью удовлетворяет списку доступа (access-list 100) и транслирует локальный адрес 172.16.1.2 в 100.0.1.2
3) Пакет приходит в VRF TARS на Linkmeup_R3, где снова подпадает под маршрут по умолчанию, который указывает на адрес 101.0.0.2 из глобальной таблицы маршрутизации. Уже из глобальной ТМ Linkmeup_R3 знает, что 101.0.0.2 доступен через 1.1.1.1 и рекурсивно через 10.0.23.2. Причём пакету выдаётся метка 16. То есть после Linkmeup_R3 пакет уже пойдёт по MPLS LSP.
Пакет между Linkmeup_R3 и Provier_R2
Заметьте, что метки VPN здесь нет — пакет перекочевал из VPN в публичную сеть.
4) На Linkmeup_R2 с пакета снимается транспортная метка MPLS (происходит PHP) и на Linkmeup_R1 уже передаётся чистый IP-пакет.
5) Этот чистый IP-пакет уходит с Linkmeup_R1 в Internet (BGP сообщил маршрут до сети 101.0.0.0/20)
6) Internet знает маршрут до 100.0.0.0/23 так же по BGP и передаёт пакет обратно.
7) Linkmeup_R1 знает, что адресат находится за 3.3.3.3 — помните, мы объявляли эту сеть в BGP?
Соответственно, по MPLS он доходит до Linkmeup_R3.
8) Сеть 100.0.1.0/30 находится в VRF TARS, но мы ведь прописывали её статически в интерфейс FE1/0. Так что пакет передаётся благополучно на интерфейс.
9) Ну а дальше обратная трансляция на TARS_2 и последняя миля до родного дома.
Тут мы опустим сценарий с 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 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
Проверяем:
Было бы странно, если бы не заработало.
1) От PC2 до Linkmeup_R3 он доходит без видимых изменений (только заголовок MAC меняется). На PC2 маршрут по умолчанию настроен вручную. На C3PO_2 он изучен по OSPF от Linkmeup_R3.
2) На интерфейсе FE0/1 пакет входит в VRF C3PO и приобретает сервисную метку.
3) Маршрут по умолчанию в VRF импортирован из BGP и он ведёт к 1.1.1.1 через 10.0.23.2:
4) От Linkmeup_R3 до Linkmeup_R2 пакет идёт по MPLS с двумя метками: внутренней сервисной — 27 и внешней транспортной — 18. Это видно из скриншота выше.
Не забывайте делать поправку на PHP — от Penultimate Router (Linkmeup_R2) — к Egress PE (Linkmeup_R1) — пакет пойдёт с одной сервисной меткой, потому что транспортная была снята в результате PHP.
5) На Linkmeup_R1 происходит Route leaking из VRF C3PO в глобальную таблицу — так пакет покидает VRF.
Также здесь происходит трансляция. Linkmeup_R1 записывает информацию об этом факте в свою таблицу трансляций для VRF C3PO:
6) В Интернет пакет уходит уже, конечно, без меток MPLS и с публичным адресом отправителя — 101.0.0.2 в заголовке
7) Ответный пакет на Linkmeup_R1 попадает по глобальной таблице маршрутизации — Интернету известен адрес 101.0.0.2. На этом узле происходит обратная трансляция. Адрес назначения меняется на 192.168.2.2 и искать его нужно уже в VRF C3PO — так сказала таблица NAT.
8) А дальше процесс вам уже известен — две метки, долгий путь до Linkmeup_R3 и далее до PC2.
Common Services
До сих пор мы обсуждали задачу передачи трафика из VPN в публичные сети и обратно.
Ещё один подход к предоставлению доступа в Интернет — вывести его в отдельный VRF.
Строго говоря — он наиболее масштабируемый, потому что нет необходимости настраивать что-то индивидуально для каждого клиентского VRF.
Важное условие — NAT происходит в сети клиента и в VRF Internet импортируются только маршруты к публичным префиксам клиента.
Common Services, который часто называют Shared Services — это продолжение вопроса о взаимодействии между VRF, который мы рассмотрели ранее. Основная идея в том, что экспорт/импорт совершается засчёт особой настройки route-target. Только на этот раз нужно ограничить список передаваемых префиксов, чтобы избежать пересечения адресных пространств и разрешить только публичные маршруты.
Рассмотрим задачу снова на примере 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.