Использование VPN S2S в качестве резервного копирования для частного пиринга ExpressRoute

В статье " Проектирование аварийного восстановления с помощью частного пиринга ExpressRoute" мы обсудили необходимость решения для подключения к резервному копированию при использовании частного пиринга ExpressRoute. Мы также обсудили, как использовать геоизбыточные каналы ExpressRoute для обеспечения высокой доступности. В этой статье объясняется, как использовать и поддерживать VPN типа "сеть — сеть" (S2S) в качестве резервного копирования для частного пиринга ExpressRoute.

В отличие от геоизбыточных каналов ExpressRoute, вы можете использовать только комбинацию аварийного восстановления ExpressRoute и VPN в активно-пассивной установке. Основная проблема использования любого сетевого подключения резервного копирования в пассивном режиме заключается в том, что пассивное подключение часто завершается сбоем вместе с основным подключением. Распространенной причиной сбоев пассивного подключения является отсутствие активного обслуживания. В этой статье рассматривается, как проверить и активно поддерживать S2S VPN-соединение, которое резервирует частный пиринг ExpressRoute.

В этой статье вы также узнаете, как проверить подключение с точки зрения Azure и внутреннего пограничного сегмента сети. Возможность проверки с обеих сторон помогает независимо от того, управляете вы или нет локальными сетевыми устройствами, которые взаимодействуют с сетевыми сущностями Microsoft.

Пример топологии

В нашей настройке у нас есть локальная сеть, подключенная к виртуальной сети Центра Azure, через канал ExpressRoute и VPN-подключение S2S. Виртуальная сеть Концентратора Azure, в свою очередь, соединена одноранговыми соединениями с конечной виртуальной сетью, как показано на схеме:

В настройке канал ExpressRoute завершается на паре маршрутизаторов пограничных вычислений клиента (CE) в локальной среде. Локальная сеть подключена к маршрутизаторам CE с парой брандмауэров, работающих в режиме ведущий-ведомый. VPN-подключение S2S заканчивается непосредственно на брандмауэрах.

В следующей таблице перечислены ключевые IP-префиксы топологии.

В следующей таблице перечислены ASN топологии:

Высокий уровень доступности без асимметричности

Настройка высокого уровня доступности

В статье «Настройка сосуществующих подключений ExpressRoute и межсайтового VPN» объясняется, как настроить сосуществующие подключения VPN ExpressRoute и S2S. Как упоминалось в статье "Проектирование высокого уровня доступности с помощью ExpressRoute", наша программа установки обеспечивает избыточность сети для устранения любой единой точки сбоя до конечных точек, что повышает высокий уровень доступности ExpressRoute. Кроме того, первичные и вторичные подключения каналов ExpressRoute активны и объявляют локальные префиксы одинаково с помощью обоих подключений.

Локальное объявление маршрута основного маршрутизатора CE через основное соединение через канал ExpressRoute показано следующим образом (команды Junos):

user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

Локальное объявление маршрута вторичного маршрутизатора CE через дополнительное подключение канала ExpressRoute отображается следующим образом (команды Junos):

user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

Чтобы повысить доступность подключения к резервному копированию, VPN S2S также настраивается в активном режиме. Конфигурация VPN-шлюза Azure показана следующим образом. Обратите внимание, что в рамках VPN-конфигурации VPN ip-адреса однорангового узла BGP шлюза --10.17.11.76 и 10.17.11.77-также перечислены.

Локальный маршрут объявляется брандмауэром основным и вторичным одноранговым узлам BGP VPN-шлюза. Объявления маршрутов показаны следующим образом (Junos):

user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

Настройка симметричного потока трафика

Мы отметили, что при объявлении заданного локального маршрута через ExpressRoute и VPN S2S Azure предпочтет путь ExpressRoute. Чтобы принудить Azure предпочесть VPN-путь S2S через сосуществующий ExpressRoute, необходимо объявить более конкретные маршруты (более длинный префикс с маской большей подсети) через VPN-подключение. Наша цель — использовать VPN-подключения только в качестве резервного копирования. Таким образом, поведение выбора пути по умолчанию в Azure соответствует нашей цели.

Мы обязаны гарантировать, что трафик, предназначенный для Azure из локальной среды, также предпочитает путь ExpressRoute через VPN типа "сеть — сеть". Приоритет по умолчанию для маршрутизаторов CE и брандмауэров в нашей локальной инфраструктуре составляет 100. Таким образом, настроив локальные предпочтения для маршрутов, полученных через частные пиринги ExpressRoute, на значение больше 100, мы можем сделать так, чтобы трафик, предназначенный для Azure, предпочитал использовать канал ExpressRoute.

Конфигурация BGP основного маршрутизатора CE, завершающего основное соединение канала ExpressRoute, показана следующим образом. Обратите внимание, что значение локального предпочтения маршрутов, объявленных через сеанс iBGP, настроено на 150. Аналогичным образом необходимо убедиться, что локальные предпочтения вторичного маршрутизатора CE, завершающего вторичное подключение канала ExpressRoute, также настроены на 150.

user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
  bgp {
    group ibgp {
        type internal;
        local-preference 150;
        neighbor 192.168.11.1;
    }
    group ebgp {
        peer-as 12076;
        bfd-liveness-detection {
            minimum-interval 300;
            multiplier 3;
        }
        neighbor 192.168.11.18;
    }
  }
}

Таблица маршрутизации локальных брандмауэров подтверждает, что для локального трафика, предназначенного для Azure, предпочтительный путь выполняется через ExpressRoute в устойчивом состоянии.

user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.17.11.0/25      *[BGP/170] 2d 00:34:04, localpref 150
                      AS path: 12076 I, validation-state: unverified
                    > to 192.168.11.0 via reth1.11
                      to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                    [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119
10.17.11.76/32     *[Static/5] 2d 21:12:16
                     > via st0.118
10.17.11.77/32     *[Static/5] 2d 00:41:56
                    > via st0.119
10.17.11.128/26    *[BGP/170] 2d 00:34:04, localpref 150
                       AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.0 via reth1.11
                       to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                     [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119

В приведенной выше таблице маршрутизации для маршрутов виртуальной сети хаба и спиц--10.17.11.0/25 и 10.17.11.128/26--мы видим, что канал ExpressRoute предпочтительнее, чем VPN-подключения. 192.168.11.0 и 192.168.11.2 — это IP-адреса в интерфейсе брандмауэра для маршрутизаторов CE.

Проверка обмена маршрутами по VPN S2S

Ранее в этой статье мы провели проверку разглашения маршрутов на локальной площадке брандмауэров к основным и вторичным пиринговым узлам BGP VPN-шлюза. Кроме того, давайте подтвердим маршруты Azure, полученные брандмауэрами из основных и вторичных одноранговых узлов BGP VPN-шлюза.

user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.76                             65515 I
  10.17.11.128/26         10.17.11.76                             65515 I

{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.77                             65515 I
  10.17.11.128/26         10.17.11.77                             65515 I

Аналогичным образом давайте проверим наличие префиксов локального сетевого маршрута, полученных VPN-шлюзом Azure.

PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight

Network      NextHop       AsPath      Weight
-------      -------       ------      ------
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.76   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.77   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769

Как было показано ранее, VPN-шлюз имеет маршруты, полученные как основными, так и вторичными узлами BGP VPN-шлюза. Он также имеет видимость маршрутов, полученных через первичные и вторичные подключения ExpressRoute (те, которые с as-path предустановлены с 12076). Чтобы подтвердить маршруты, полученные через VPN-подключения, необходимо знать локальный IP-адрес однорангового узла BGP подключений. IP-адрес, который мы рассматриваем в нашей настройке, это 192.168.11.88, и мы видим маршруты, которые мы получили от него.

Затем давайте проверим маршруты, распространяемые VPN-шлюзом Azure к одноранговому узлу BGP брандмауэра (192.168.11.88).

PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn |  select Network, NextHop, AsPath, Weight

Network         NextHop     AsPath Weight
-------         -------     ------ ------
10.17.11.0/25   10.17.11.76 65515       0
10.17.11.128/26 10.17.11.76 65515       0
10.17.11.0/25   10.17.11.77 65515       0
10.17.11.128/26 10.17.11.77 65515       0

Отсутствие обнаружения обмена маршрутами указывает на сбой подключения. См. устранение неполадок: подключение VPN типа "межсайтовое" Azure не может подключиться и перестает работать для помощи в устранении неполадок с VPN-подключением.

Тестирование отработки отказа

Теперь, когда мы подтвердили успешный обмен маршрутами через VPN-подключение (плоскость управления), можно переключить трафик (плоскость данных) с подключения ExpressRoute на VPN-подключение.

Прежде чем выполнить переключение трафика, давайте отследим текущий путь в настройке с локального тестового сервера на тестовую виртуальную машину в периферийной виртуальной сети.

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2    <1 ms    <1 ms    11 ms  192.168.11.0
  3    <1 ms    <1 ms    <1 ms  192.168.11.18
  4     *        *        *     Request timed out.
  5     6 ms     6 ms     5 ms  10.17.11.132

Trace complete.

Основные и вторичные подсети подключения ExpressRoute типа "точка-точка" нашей настройки: 192.168.11.16/30 и 192.168.11.20/30. На представленном выше маршруте трассировки на шаге 3 мы видим, что попадаем на 192.168.11.18, который является IP-адресом интерфейса основного MSEE. Наличие интерфейса MSEE подтверждает, что, как и ожидалось, текущий путь проходит через ExpressRoute.

Как указано в пирингах контуров Reset ExpressRoute, используйте следующие команды PowerShell, чтобы отключить как основной, так и вторичный пиринг контура ExpressRoute.

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

Время переключения на резервный канал зависит от времени конвергенции BGP. В нашей конфигурации переключение на резервный канал занимает несколько секунд (менее 10). После переключения повторная трассировка покажет следующий путь:

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2     *        *        *     Request timed out.
  3     6 ms     7 ms     9 ms  10.17.11.132

Trace complete.

Результат трассировки подтверждает, что подключение резервного копирования через VPN S2S активно и может обеспечить непрерывность службы, если не удается выполнить как первичные, так и вторичные подключения ExpressRoute. Чтобы завершить тестирование отказоустойчивости, давайте включим подключения ExpressRoute обратно и восстановим поток трафика, используя следующий набор команд.

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

Чтобы убедиться, что трафик переключится обратно в ExpressRoute, повторите трассировку и убедитесь, что он проходит через частный пиринг ExpressRoute.

Дальнейшие действия

ExpressRoute предназначен для обеспечения высокой доступности без единой точки сбоя в сети Майкрософт. По-прежнему канал ExpressRoute ограничен одним географическим регионом и поставщиком услуг. S2S VPN может быть хорошим пассивным решением резервного копирования для восстановления после аварии в канале ExpressRoute. Для надежного решения пассивного резервного подключения важно регулярное обслуживание пассивной конфигурации и периодическая проверка соединения. Важно не позволить конфигурации VPN стать устаревшей, а периодически (скажем, каждый квартал) повторять шаги проверки и тестирования отказоустойчивости, описанные в этой статье во время окна обслуживания.

Сведения о включении мониторинга и оповещений на основе метрик VPN-шлюза см. в разделе "Настройка оповещений о метриках VPN-шлюза".

Чтобы ускорить конвергенцию BGP после сбоя ExpressRoute, настройте BFD через ExpressRoute.