Привет 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 туннели от удалённых точек одновременно на всех имеющихся Интернет-подключениях маршрутизатора.


VRF, к которым подключают каналы Интернет-провайдеров и в которых появляется туннелированный (в частности, зашифрованный) трафик, называют FVRF – Front-door VRF. При корректной настройке IPsec с VRF мы получаем связь между IVRF и FVRF средствами IPsec. Другими словами, защищаемый трафик поступает в IVRF, а после инкапсуляции в туннель автоматически оказывается в FVRF, в котором действуют другие правила маршрутизации. И это очень удобно.

Перехожу к описанию моего примера. Имеется распределённая сеть. В центральном офисе (далее ЦО) два Интернет-провайдера, каждый из которых подключён к собственному маршрутизатору Cisco. Первый Интернет-провайдер ISP1 используется для VPN до удалённых офисов, второй Интернет-провайдер ISP2 – для выхода в Интернет. Между маршрутизаторами ЦО настроен протокол резервирования первого перехода HSRP. В удалённых офисах два варианта граничного оборудования:

1. Маршрутизатор Cisco. До таких офисов построены VTI-туннели.
2. 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 будет рассмотрен в следующем разделе. Теперь остаётся распределить потоки трафика по имеющимся туннелям. Для решения данной задачи можно выделить следующие подходы:

1. Equal Cost Multi Path (ECMP). Балансировка по туннелям с использованием маршрутов с одинаковой метрикой;
2. Маршрутизировать разные IP-подсети ЦО и/или удалённых офисов по разным туннелям;
3. Performance Routing (PfR);
4. Policy Based Routing (PBR);
5. Использовать 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.




Описание конфигурации

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 через дополнительные каналы связи, в частности, через дополнительного Интернет-провайдера.