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

    Если Интернет-провайдеры подключены в один глобальный VRF
    В этом случае на маршрутизаторе в глобальном VRF присутствует единственный маршрут по умолчанию. Удалённый офис может строить параллельные VPN туннели до рассматриваемого маршрутизатора через все имеющиеся Интернет-каналы. Но ответный трафик от рассматриваемого маршрутизатора будет идти в соответствии с маршрутом по умолчанию через единственный Интернет-провайдер. Следовательно, ответным трафиком будет утилизироваться только тот Интернет-провайдер, на который указывает маршрут по умолчанию. Рассмотрим пример на основании IPsec VTI-туннелей:


    Настройки туннельных интерфейсов маршрутизатора 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. В удалённых офисах два варианта граничного оборудования:

    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.



    Ассиметричная маршрутизация
    На схеме видно, мы допускаем ассиметричную маршрутизацию: запросы идут через туннели ISP1, ответы возвращаются через туннели ISP3. При нормальном режиме работы данная схема устраивает. Но ассиметричная маршрутизация почти всегда готова принести проблемы. Не обошлось без трудностей и у нас.

    Представим схему, когда отказывает 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 через дополнительные каналы связи, в частности, через дополнительного Интернет-провайдера.
    • +9
    • 13,7k
    • 2
    CBS
    64,56
    Компания
    Поделиться публикацией

    Комментарии 2

      0
      Профили ISAKMP в данном примере лишние.
        0
        Учтём, спасибо.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое