Front-door VRF. Ещё один практический пример
Привет habr! Про настройку VPN совместно с VRF на оборудовании Cisco существует много статей в Интернете. Здесь есть неплохая шпаргалка по настройке IPsec VPN в виде крипто-карт и VTI-туннелей совместно с VRF. В этой статье хабра приведён пример DMVPN с VRF. VRF даёт большую гибкость при настройке оборудования и вариантов её использования большое количество. Главное не забывать, что у нас есть такой инструмент. В моей заметке я решил рассмотреть ещё одну интересную задачу из нашей практики, для решения которой также пригодилось использование Front-door VRF для построения IPsec туннелей. Речь пойдёт про построение параллельных VPN-туннелей через разных Интернет-провайдеров и распределение трафика по этим туннелям.
Технология Virtual Routing and Forwarding (VRF) позволяет разделить один физический маршрутизатор на несколько логических (виртуальных). Благодаря данной технологии появляется возможность иметь на одном физическом маршрутизаторе несколько независимых таблиц маршрутизации. Технология VRF получила широкое распространение в сетях MPLS. Однако, VRF можно использовать и без MPLS. В этом случае в терминологии Cisco технология получила название VRF lite. Если быть более точным, VRF-lite — это технология, позволяющая строить два или более VPN туннеля на одном VPN концентраторе, в среде, предполагающей пересекающиеся адресные пространства. В данной заметке пересечение адресных пространств затрагиваться не будет.
Очень кратко рассмотрим, что нам даёт использование VPN совместно с VRF. Защищаемая сеть, трафик которой подлежит шифрованию, может находиться не в глобальном VRF маршрутизатора. VRF защищаемой сети называется IVRF — Inside VRF. Однако, по умолчанию, маршрутизатор строит IPsec в глобальном VRF. Интернет-провайдеры могут быть подключены к интерфейсам маршрутизатора, которые также находятся не в глобальном VRF маршрутизатора. Такое подключение Интернет-провайдеров позволяет терминировать и утилизировать VPN туннели от удалённых точек одновременно на всех имеющихся Интернет-подключениях маршрутизатора.
Настройки туннельных интерфейсов маршрутизатора R1:
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
!
interface GigabitEthernet0/1
ip address 1.1.1.1 255.255.255.252
!
interface GigabitEthernet0/2
ip address 2.2.2.2 255.255.255.252
!
interface Tunnel1
ip unnumbered GigabitEthernet0/0
tunnel source 1.1.1.1
tunnel mode ipsec ipv4
tunnel destination 3.3.3.1
tunnel path-mtu-discovery
tunnel protection ipsec profile ipsec-prof
!
interface Tunnel2
ip unnumbered GigabitEthernet0/0
tunnel source 2.2.2.1
tunnel mode ipsec ipv4
tunnel destination 3.3.3.1
tunnel path-mtu-discovery
tunnel protection ipsec profile ipsec-prof
!
ip route 0.0.0.0 0.0.0.0 1.1.1.2
ip route 0.0.0.0 0.0.0.0 2.2.2.2 10
Настройки туннельных интерфейсов маршрутизатора R2:
interface GigabitEthernet0/0
ip address 192.168.2.1 255.255.255.0
!
interface GigabitEthernet0/1
ip address 3.3.3.1 255.255.255.252
!
interface Tunnel1
ip unnumbered GigabitEthernet0/0
tunnel source 3.3.3.1
tunnel mode ipsec ipv4
tunnel destination 1.1.1.1
tunnel path-mtu-discovery
tunnel protection ipsec profile ipsec-prof
!
interface Tunnel2
ip unnumbered GigabitEthernet0/0
tunnel source 3.3.3.1
tunnel mode ipsec ipv4
tunnel destination 2.2.2.1
tunnel path-mtu-discovery
tunnel protection ipsec profile ipsec-prof
!
ip route 0.0.0.0 0.0.0.0 3.3.3.2
Для представленной конфигурации туннелированный трафик будет распределяться по Интернет-провайдерам маршрутизатора R1 следующим образом:
IPsec-пакеты Tunnel2 от R1 к R2 имеют IP-адрес источника 2.2.2.1, но проходят через канал первого Интернет-провайдера ISP1. Некоторые Интернет-провайдеры блокируют трафик с IP-адресами источника, принадлежащими «чужим» Интернет-провайдерам. Если провайдер делает указанную проверку, Tunnel2 не установится (поэтому часть линии Tunnel2 от R1 до R2 показана пунктиром).
VRF, к которым подключают каналы Интернет-провайдеров и в которых появляется туннелированный (в частности, зашифрованный) трафик, называют FVRF — Front-door VRF. При корректной настройке IPsec с VRF мы получаем связь между IVRF и FVRF средствами IPsec. Другими словами, защищаемый трафик поступает в IVRF, а после инкапсуляции в туннель автоматически оказывается в FVRF, в котором действуют другие правила маршрутизации. И это очень удобно.
Перехожу к описанию моего примера. Имеется распределённая сеть. В центральном офисе (далее ЦО) два Интернет-провайдера, каждый из которых подключён к собственному маршрутизатору Cisco. Первый Интернет-провайдер ISP1 используется для VPN до удалённых офисов, второй Интернет-провайдер ISP2 — для выхода в Интернет. Между маршрутизаторами ЦО настроен протокол резервирования первого перехода HSRP. В удалённых офисах два варианта граничного оборудования:
- Маршрутизатор Cisco. До таких офисов построены VTI-туннели.
- NPE-маршрутизатор Cisco в паре c Cisco ASA. До таких офисов построены GRE over IPsec туннели. GRE терминируются на маршрутизаторах и шифруются в IPsec на Cisco ASA.
Схема сети:
Между ЦО и удалёнными офисами маршруты передаются по EIGRP. При отказе ISP1 или маршрутизатора R1 весь трафик переходит на ISP2 и маршрутизатор R2. При отказе ISP2 или R2 выход в Интернет осуществляется через ISP1 и соответственно R1. Данная схема реализована за счёт EIGRP, HSRP и PBR. PBR используется для перенаправления трафика в Интернет через ISP2. PBR настроен с использованием трекинга работоспособности ISP2 (IP SLA PBR Object Tracking).
Задача
В ЦО подключается третий Интернет-провайдера ISP3 к маршрутизатору R1. Необходимо распределить трафик по туннелям через ISP1 и ISP3 маршрутизатора R1. Также, необходимо соблюсти некоторые требования отказоустойчивости по Интернет-провайдерам ЦО и маршрутизаторам ЦО. Расписывать все варианты отказа я не буду, упомяну только наиболее важное требование: провайдер ISP1, по которому бегает обычный трафик до удалённых офисов (зелёные туннели на схеме), должен оставаться по возможности не нагруженным. То есть, при отказе ISP2 выход в Интернет должен переходить на ISP3, а при отказе ISP3 трафик внедряемого сервиса (красные туннели на схеме) должен переходить на ISP2.
Схема сети с учётом нового канала (ISP3):
Решение
Краткое описание
Так как маршрутизатор R1 в нормальном режиме работы сети (когда все Интернет-провайдеры работоспособны) должен терминировать VPN IPsec туннели одновременно на обоих Интернет-провайдерах (ISP1 и ISP3), было принято решение вынести подключение к новому Интернет-провайдеру ISP3 в отдельный FVRF. При этом защищаемые (локальные) сети и подключение к первому Интернет-провайдеру было решено оставить в глобальном VRF.
После корректной настройки IPsec совместно с FVRF имеем параллельные работоспособные туннели через IPS1 и IPS3. Пример конфигурации IPSec c FVRF будет рассмотрен в следующем разделе. Теперь остаётся распределить потоки трафика по имеющимся туннелям. Для решения данной задачи можно выделить следующие подходы:
- Equal Cost Multi Path (ECMP). Балансировка по туннелям с использованием маршрутов с одинаковой метрикой;
- Маршрутизировать разные IP-подсети ЦО и/или удалённых офисов по разным туннелям;
- Performance Routing (PfR);
- Policy Based Routing (PBR);
- Использовать Network Address Translation (NAT) для выделения определённых IP-адресов и настройка маршрутизации для этих особенных IP-адресов.
Для моей задачи наиболее предпочтительным оказался последний вариант — подход с использованием NAT. Этот вариант позволяет с одной стороны жёстко задавать распределение трафика по туннелям (в отличие от ECMP и PfR), с другой стороны, уменьшить количество строк конфигурации (в отличие от PBR). Рассмотрим его более подробно.
На маршрутизаторах ЦО настраиваем правило трансляции сетевых адресов dynamic policy NAT. Данное правило используем, чтобы изменять IP-адреса компьютеров ЦО на некоторый «особенный» IP-адрес, когда они обращаются к некоторым заранее известным серверам в удалённых офисах. Используем именно policy NAT, чтобы изменять IP-адреса клиентов только в случаях обращения к известным IP-адресам серверов. Далее, с помощью настройки EIGRP, раздаём в удалённые офисы «особенный» IP-адрес с лучшей метрикой через туннели ISP3, а для туннелей через ISP1, которые необходимо разгрузить, наоборот, завышаем метрику для «особенного» IP-адреса.
Таким образом, запрос от клиентов ЦО попадает на сервер в удалённом офисе с изменённым IP-адресом источника. В ответ сервер генерирует трафик на изменённый IP-адрес, а роутер в удалённом офисе маршрутизирует этот поток трафика в требуемый туннель. При этом на роутерах в удалённых офисах не требуется дополнительной настройки маршрутизации: управление маршрутами осуществляется посредством EIGRP из консоли маршрутизаторов ЦО. Ниже представлена схема прохождения запроса/ответа. Реальный IP-адрес клиента: 192.168.1.100. «Особенный» IP-адрес, в который происходит преобразование IP-адреса клиента: 10.10.10.10. IP-адрес сервера в удалённом офис: 172.16.1.100.
Представим схему, когда отказывает ISP1. В этом случае запросы начинают ходить через маршрутизатор R2 и туннели ISP2, и схема прохождения запроса/ответа приобретает следующий вид:
По схеме видно, для пакетов запросов трансляция IP-адреса источника выполняется на маршрутизаторе R2. Ответные пакеты приходят через туннели ISP3 на маршрутизатор R1. Однако, чтобы выполнить процедуру UNNAT и преобразовать IP-адрес получателя в реальный IP-адрес клиента, приходится отправлять пакеты обратно на маршрутизатор R2.
Чтобы процедура UNNAT на маршрутизаторе R2 прошла успешно, ответные пакеты должны попасть сперва на интерфейс маршрутизатора, имеющий директиву ip nat outside, а далее, на интерфейс, имеющий директиву ip nat inside. В качестве интерфейса с директивой ip nat outside используется Loopback интерфейс. В качестве интерфейса с директивой ip nat inside выступает внутренний интерфейс маршрутизатора, подключенный к коммутаторам ядра сети. Если перенаправлять трафик от маршрутизатора R1 на маршрутизатор R2 по имеющимся внутренним интерфейсам, подключенным к коммутаторам ядра сети, получается, что пакеты проходят по следующей траектории: R2 внутренний интерфейс с ip nat inside, R2 Loopback интерфейс с ip nat outside и обратно на R2 внутренний интерфейс c ip nat inside. С точки зрения NAT траектория выглядит: ip nat inside → ip nat outside → ip nat inside. UNNAT не отрабатывал. Необходимо было исключить первый ip nat inside, то есть вхождение пакетов, подлежащих UNNAT через имеющийся внутренний интерфейс маршрутизатора R2. Пришлось настроить на маршрутизаторе R2 дополнительный логический субинтерфейс, не имеющий директивы ip nat inside, чтобы принимать трафик от R1, подлежащий UNNAT, а на маршрутизаторе R1 настроить соответствующие правила маршрутизации.
Описание конфигурации
IP-адресация ЦО:
| Внутренняя сеть: | 192.168.1.0/24 |
| Подключение к ISP1: | 1.1.1.1/30, шлюз 1.1.1.2 |
| Подключение к ISP2: | 2.2.2.1/30 шлюз 2.2.2.2 |
| Подключение к ISP3: | 3.3.3.1/30 шлюз 3.3.3.2 |
| IP-адрес клиента: | 192.168.1.100 |
IP-адресация удалённого офиса типа 1 (VTI-туннели):
| Внутренняя сеть: | 172.16.1.0/24 |
| Подключение к ISP: | 4.4.4.1/30 шлюз 4.4.4.2 |
| IP-адрес сервера: | 172.16.1.100 |
IP-адресация удалённого офиса типа 2 (GRE over IPsec туннели):
| Внутренняя сеть: | 172.16.2.0/24 |
| Подключение к ISP: | 5.5.5.1/30 шлюз 5.5.5.2 |
| Подсеть между маршрутизатором и Cisco ASA: | 6.6.6.2 — маршрутизатор 6.6.6.1 — Cisco ASA маска 255.255.255.252 |
| IP-адрес сервера: | 172.16.2.100 |
Схема сети:
Рассмотрим конфигурацию маршрутизатора R1. Сперва приведу пример настройки VPN-туннелей до удалённых офисов типа 1 (VTI-туннели) и типа 2 (GRE over IPsec туннели). На схеме и в конфигурации применяю следующие обозначения VPN-туннелей:
- Tunnel 10 — VTI-туннель через ISP1;
- Tunnel 11 — VTI-туннель через ISP3, настроенный с использованием VRF;
- Tunnel 20 — GRE over IPsec туннель через ISP1;
- Tunnel 21 — GRE over IPsec туннель через ISP3, настроенный с использованием VRF.
Настройка VRF и интерфейсов:
! Настройка VRF для подключения нового Интернет-провайдера ISP3
ip vrf ISP3-vrf
!
! Настройка интерфейса для подключения нового Интернет-провайдера ISP3
interface GigabitEthernet0/2
description === ISP3 ===
ip address 3.3.3.1 255.255.255.252
ip vrf forwarding ISP3-vrf
!
! Настройка маршрута по умолчанию для нового Интернет-провайдера ISP3
ip route vrf ISP3-vrf 0.0.0.0 0.0.0.0 3.3.3.2
!
! Настройка внутреннего интерфейса с HSRP
interface GigabitEthernet0/0
description === LAN ===
ip address 192.168.1.2 255.255.255.0
standby 1 ip 192.168.1.1
standby 1 priority 105
standby 1 preempt
!
! Настройка интерфейса для подключения Интернет-провайдера ISP1
interface GigabitEthernet0/1
description === ISP1 ===
ip address 1.1.1.1 255.255.255.252
!
! Настройка маршрута по умолчанию для Интернет-провайдера ISP1
ip route 0.0.0.0 0.0.0.0 1.1.1.2
Настройка VTI-туннеля через провайдера ISP1 для связи с удалёнными офисами типа 1.
! Политика ISAKMP
crypto isakmp policy 10
encr aes
hash sha
authentication pre-share
group 2
!
! Pre-shared key
crypto isakmp key STRONGKEY address 4.4.4.1 no-xauth
!
! Политика IPsec
crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac
mode tunnel
!
! Профиль IPsec
crypto ipsec profile VTI
set transform-set ESP-AES-SHA
!
! Туннельный интерфейс VTI
interface Tunnel10
description === To office Type 1 over ISP1 ===
ip unnumbered GigabitEthernet0/0
tunnel source 1.1.1.1
tunnel mode ipsec ipv4
tunnel destination 4.4.4.1
tunnel path-mtu-discovery
tunnel protection ipsec profile VTI
Настройка VTI-туннеля через провайдера ISP3 в новом VRF «ISP3-vrf» для связи с удалёнными офисами типа 1.
! Keyring
crypto keyring office1-keyring vrf ISP3-vrf
pre-shared-key address 4.4.4.1 key STRONGKEY
!
! Политика ISAKMP
crypto isakmp policy 10
encr aes
hash sha
authentication pre-share
group 2
!
! Профиль ISAKMP
crypto isakmp profile office1-ike-prof
keyring office1-keyring
match identity address 4.4.4.1 255.255.255.255 ISP3-vrf
isakmp authorization list default
local-address GigabitEthernet0/2
!
! Политика IPsec
crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac
mode tunnel
!
! Профиль IPsec
crypto ipsec profile office1-ipsec-prof
set transform-set ESP-AES-SHA
set isakmp-profile office1-ike-prof
!
! Туннельный интерфейс VTI. Инкапсулированный трафик попадает в ISP3-vrf
interface Tunnel11
description === To office Type 1 over ISP3 ===
ip unnumbered GigabitEthernet0/0
tunnel source 3.3.3.1
tunnel mode ipsec ipv4
tunnel destination 4.4.4.1
tunnel path-mtu-discovery
tunnel vrf ISP3-vrf
tunnel protection ipsec profile office1-ipsec-prof
Настройка туннеля GRE over IPsec через провайдера ISP1 для связи с удалёнными офисами типа 2.
! Политика ISAKMP
crypto isakmp policy 10
encr aes
hash sha
authentication pre-share
group 2
!
! Pre-shared key
crypto isakmp key STRONGKEY address 5.5.5.1 no-xauth
!
! Политика IPsec
crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac
mode tunnel
!
! Крипто-карта
crypto map CMAP 10 ipsec-isakmp
description === To office Type 2 over ISP1 ===
set peer 5.5.5.1
set transform-set ESP-AES-SHA
match address cryptomap_10_acl
!
! Туннельный интерфейс GRE
interface Tunnel520
description === To office Type 2 over ISP1 ===
ip unnumbered GigabitEthernet0/0
keepalive 10 3
tunnel source 1.1.1.1
tunnel destination 6.6.6.2
tunnel path-mtu-discovery
!
! Крипто-ACL
ip access-list extended cryptomap_10_acl
permit gre 1.1.1.1 host host 6.6.6.2
!
! Применяем крипто-карту к интерфейсу ISP1
interface GigabitEthernet0/1
crypto map CMAP
Настройка туннеля GRE over IPsec через провайдера ISP3 в новом VRF «ISP3-vrf» для связи с удалёнными офисами типа 2.
crypto keyring office2-keyring vrf ISP3-vrf
pre-shared-key address 5.5.5.1 key STRONGKEY
!
! Политика ISAKMP
crypto isakmp policy 10
encr aes
hash sha
authentication pre-share
group 2
!
! Профиль ISAKMP
crypto isakmp profile office2-ike-prof
vrf ISP3-vrf
keyring office2-keyring
match identity address 5.5.5.1 255.255.255.255 ISP3-vrf
isakmp authorization list default
!
! Политика IPsec
crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac
mode tunnel
!
! Крипто-карта
crypto map CMAP-vrf 10 ipsec-isakmp
description === To office Type 2 over ISP3 ===
set peer 5.5.5.1
set transform-set ESP-AES-SHA
set isakmp-profile office2-ike-prof
match address cryptomap-vrf_10_acl
!
interface Tunnel21
description === To office Type 2 over ISP3 ===
ip unnumbered GigabitEthernet0/0
keepalive 10 3
tunnel source 3.3.3.3
tunnel destination 6.6.6.2
tunnel path-mtu-discovery
tunnel vrf ISP3-vrf
!
! Крипто-ACL
ip access-list extended cryptomap-vrf_10_acl
permit gre 3.3.3.3 host host 6.6.6.2
!
! Применяем крипто-карту к интерфейсу ISP3
interface GigabitEthernet0/2
crypto map CMAP-vrf
По приведённым примерам настраиваются VPN-туннели до всех удалённых офисов. Настройки VPN туннелей на маршрутизаторе R2 в ЦО и на маршрутизаторах и Cisco ASA в удалённых офисах рассматривать не буду в виду их тривиальности.
Теперь, когда готовы VPN-туннели до всех удалённых офисов, можно перейти к рассмотрению настроек маршрутизации. В сети используется EIGRP. Сперва необходимо настроить правила dynamic policy NAT для выделения клиентов внедряемой системы.
! Loopback интерфейс будет использоваться в правиле NAT
! для указания внутреннего глобального адреса
interface Loopback1
description ===For System-Servers routing===
ip address 10.10.10.10 255.255.255.255
!
! В группе объектов прописываются IP-адреса серверов удалённых офисов
object-group network System-Servers
description === System-Servers ===
host 172.16.1.100
host 172.16.2.100
!
! Список доступа для правила NAT
ip access-list extended NAT-System-Servers
permit ip any object-group System-Servers
!
! Карта маршрутизации для правила NAT
route-map RM-NAT-System-Servers permit 10
match ip address NAT-System-Servers
!
! Правило dynamic policy NAT
ip nat inside source route-map RM-NAT-System-Servers interface Loopback1 overload
!
! Директивы ip nat inside и ip nat outside на интерфейсах
interface GigabitEthernet0/0
ip nat inside
!
interface Tunnel10
ip nat outside
!
interface Tunnel11
ip nat outside
interface Tunnel20
ip nat outside
interface Tunnel21
ip nat outside
Данные настройки NAT приводят к преобразованию IP-адресов клиентов в «особенный» IP-адрес 10.10.10.10 при обращении к серверам в удалённых офисах.
Остаётся настроить EIGRP на маршрутизаторе в ЦО таким образом, чтобы сеть 10.10.10.10/32 анонсировался в удалённые офисы с лучшей метрикой через туннели провайдера ISP3. В нашем примере это Tunnel 11 и Tunnel 21. Для управления метрикой EIGRP я решил использовать конструкцию offset-list. Напомню, с помощью директивы offset-list можно прибавлять указанное значение к анонсируемой метрике маршрута. Настройки EIGRP:
access-list 10 permit 10.10.10.10
!
router eigrp 1
network 192.168.1.0 0.0.0.255
offset-list 10 out 3000000 Tunnel10
offset-list 10 out 3000000 Tunnel20
passive-interface default
no passive-interface Tunnel10
no passive-interface Tunnel11
no passive-interface Tunnel20
no passive-interface Tunnel21
no passive-interface GigabitEthernet0/0
Описанная конфигурация делает процедуру добавления новых серверов в удалённых офисах, трафик от которых нужно маршрутизировать через туннели нового провайдера ЦО ISP3, максимально простой. При появлении нового сервера достаточно внести его IP-адрес в группу объектов «System-Servers»:
! В группе объектов прописываются IP-адреса серверов удалённых офисов
object-group network System-Servers
description === System-Servers ===
host 172.16.1.100
host 172.16.2.100
На этом я завершаю рассмотрение конфигураций маршрутизатора R1 ЦО. Конфигурация маршрутизатора R2 в ЦО и конфигурации сетевых устройств в удалённых офисах не представляют интереса в рамках данной статьи.
Заключение
Иногда перед сетевым инженером ставится простая и логичная задача, но решение задачи приводит к формированию сравнительно непростых конфигураций. В моём примере рассмотрена элементарная задача: подключить к имеющемуся маршрутизатору новый Интернет-провайдер и запустить по нему трафик некоторых сервисов из удалённых офисов. Однако, для решения данной задачи потребовалось разбивать маршрутизатор на VRF, прописывать хитрые правила трансляции IP-адресов, корректировать настройки динамической маршрутизации, исправлять последствия ассиметричной маршрутизации.
На примере данной задачи я рассмотрел использование Front-door VRF для построения IPsec туннелей. Кроме того, я показал вариант централизации настроек маршрутизации для топологии «звезда» с использованием правил NAT. Front-door VRF для построения IPsec является удобным инструментом, позволяющим строить мост для передачи трафика между VRF маршрутизатора: защищаемый трафик может находиться в IVRF или глобальном VRF, а инкапсулированный (зашифрованный) трафик оказывается в FVRF. В FVRF работают собственные правила маршрутизации, благодаря чему появляется возможность отправлять трафик FVRF через дополнительные каналы связи, в частности, через дополнительного Интернет-провайдера.
