Common Services
До сих пор мы обсуждали задачу передачи трафика из VPN в публичные сети и обратно. Ещё один подход к предоставлению доступа в Интернет — вывести его в отдельный VRF. Строго говоря — он наиболее масштабируемый, потому что нет необходимости настраивать что-то индивидуально для каждого клиентского VRF. Важное условие — NAT происходит в сети клиента и в VRF Internet импортируются только маршруты к публичным префиксам клиента.
Common Services, который часто называют Shared Services — это продолжение вопроса о взаимодействии между VRF, который мы рассмотрели ранее. Основная идея в том, что экспорт/импорт совершается засчёт особой настройки route-target. Только на этот раз нужно ограничить список передаваемых префиксов, чтобы избежать пересечения адресных пространств и разрешить только публичные маршруты.
Рассмотрим задачу снова на примере TARS, потому что у них уже есть публичные сети.
На шлюзе мы создаём VRF Internet.
Обратите внимание, что route-target на импорт и на экспорт в этот раз разные и сейчас станет понятно почему. 2) Перенести интерфейс в сторону Интернета в VRF:
3) Перенести BGP-соседство с маршрутизатором в Интернете в address-family ipv4 vrf Internet:
4) Объявляем маршрут по умолчанию:
5) В клиентском VRF TARS нужно также настроить RT:
Итак, помимо собственного 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:
Первые три строки запрещают анонсы всех частных сетей. Четвёртая разрешает все остальные. В нашем случае вполне можно было бы обойтись одной строкой: ip prefix-list 1 permit 100.0.0.0/23 le 32 — вся подсеть Linkmeup, но приведённый нами пример более универсальный — он допускает существование других публичных сетей и соответственно один prefix-list может быть применён для всех VRF. Следующая конструкция применяет расширенное community к тем префиксам, что попали в prefix-list 1, иными словами устанавливает RT:
Осталось дело за малым — применить route-map к VRF:
После обновления маршрутов BGP (можно форсировать командой clear ip bgp all 64500) видим, что в VRF Internet остался только публичный маршрут:
И, собственно, проверка доступности Интернета с PC1 (NAT уже настроен на TARS_2):
Уважаемые читатели, вы только что ознакомились с другим подходом к Route Leaking'у.
Полная конфигурация всех узлов для Common Services.
Наиболее доступно тема Common Services описана Jeremy Stretch. Но у него нет указания на то, что префиксы нужно фильтровать. Вообще, у них там в ихних америках, все друг друга знают и уважают. Поэтому Джереми охотно ссылается на Ивана Пепельняка, а точнее его заметку о Common Services, а Иван в свою очередь на Джереми. Статьи их дополняют друг друга, но опять же до конца тему не раскрывают. А вот и третья ссылка, которая в купе с первыми двумя позволяет сложить какое-то представление о том, как работает Common Services.
Last updated
