Использование S2S VPN в качестве резервной копии для частного пиринга ExpressRoute
В статье " Проектирование аварийного восстановления с помощью частного пиринга ExpressRoute" мы обсудили необходимость решения для подключения к резервному копированию при использовании частного пиринга ExpressRoute. Мы также обсудили, как использовать геоизбыточные каналы ExpressRoute для обеспечения высокой доступности. В этой статье объясняется, как использовать и поддерживать VPN типа "сеть — сеть" (S2S) в качестве резервного копирования для частного пиринга ExpressRoute.
Примечание.
Использование VPN типа "сеть — сеть" в качестве решения резервного копирования для подключения ExpressRoute не рекомендуется при работе с конфиденциальными задержками, критически важными или ресурсоемкими рабочими нагрузками с пропускной способностью. В таких случаях рекомендуется разработать аварийное восстановление с помощью отказоустойчивости ExpressRoute с несколькими сайтами, чтобы обеспечить максимальную доступность.
В отличие от геоизбыточных каналов ExpressRoute, вы можете использовать только комбинацию аварийного восстановления ExpressRoute и VPN в активно-пассивной установке. Основная проблема использования любых резервных сетевых подключений в пассивном режиме заключается в том, что пассивное подключение часто выходит из строя вместе с основным подключением. Частая причина сбоев пассивного подключения — отсутствие активного обслуживания. Поэтому в этой статье основное внимание уделяется проверке и активному обслуживанию VPN-подключения S2S, которое выполняет резервное копирование частного пиринга ExpressRoute.
Примечание.
Если данный маршрут объявляется через ExpressRoute и VPN, Azure предпочитает маршрутизацию через ExpressRoute.
В этой статье вы также узнаете, как проверить подключение с точки зрения Azure и локальной пограничной сети. Возможность проверки с обеих сторон помогает независимо от того, управляете ли локальные сетевые устройства, одноранговые с сетевыми сущностями Майкрософт.
Пример топологии
В нашей настройке у нас есть локальная сеть, подключенная к виртуальной сети Центра Azure, через канал ExpressRoute и VPN-подключение S2S. Виртуальная сеть Концентратора Azure в свою очередь одноранговая виртуальная сеть, как показано на схеме:
В настройке канал ExpressRoute завершается на паре маршрутизаторов пограничных вычислений клиента (CE) в локальной среде. Локальная локальная локальная сеть подключена к маршрутизаторам CE с парой брандмауэров, работающих в режиме лидер-последователя. S2S VPN напрямую завершается на межсетевых экранах.
В следующей таблице перечислены ключевые IP-префиксы топологии:
| Сущность | Prefix |
|---|---|
| Локальная сеть | 10.1.11.0/25 |
| Виртуальная сеть Центра Azure | 10.17.11.0/25 |
| Периферийная виртуальная сеть Azure | 10.17.11.128/26 |
| Локальный тестовый сервер | 10.1.11.10 |
| Тестовая виртуальная машина периферийной виртуальной сети | 10.17.11.132 |
| Основная подсеть подключения ExpressRoute P2P | 192.168.11.16/30 |
| Дополнительное подключение ExpressRoute P2P | 192.168.11.20/30 |
| IP-адрес основного узла BGP шлюза VPN | 10.17.11.76 |
| IP-адрес вторичного узла BGP шлюза VPN | 10.17.11.77 |
| IP-адрес локального брандмауэра узла BGP VPN | 192.168.11.88 |
| Первичный маршрутизатор CE i/f к IP-адресу брандмауэра | 192.168.11.0/31 |
| Брандмауэр i/f, направленный на основной IP-адрес маршрутизатора CE | 192.168.11.1/31 |
| Дополнительный маршрутизатор CE (i/f) к IP-адресу брандмауэра | 192.168.11.2/31 |
| Брандмауэр i/f, направленный на дополнительный IP-адрес маршрутизатора CE | 192.168.11.3/31 |
В следующей таблице перечислены ASN топологии:
| Автономная система | ASN |
|---|---|
| Локально | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Виртуальная сеть GW (ExR) | 65515 |
| Виртуальная сеть GW (VPN) | 65515 |
Высокая доступность без асимметричности
Настройка высокой доступности
В статье "Настройка ExpressRoute" и "сеть — сеть" сосуществующие подключения объясняется, как настроить сосуществующие 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
Чтобы повысить доступность резервного подключения, S2S VPN также настроен в режиме "активный-активный". Конфигурация VPN-шлюза Azure показана следующим образом. Обратите внимание, что в рамках конфигурации 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
Примечание.
Настройка VPN S2S в активном режиме не только обеспечивает высокий уровень доступности для подключения к сети резервного копирования аварийного восстановления, но и обеспечивает более высокую пропускную способность для подключения к резервному копированию. Поэтому рекомендуется настроить VPN S2S в активно-активном режиме, так как он создаст несколько базовых туннелей.
Настройка симметричного потока трафика
Мы отметили, что при объявлении заданного локального маршрута через 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.
Проверка обмена маршрутами через S2S VPN
Ранее в этой статье мы проверили локальное объявление маршрута брандмауэрами к первичным и вторичным одноранговым узлам 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
Точно так же давайте проверим префиксы локальных сетевых маршрутов, полученные шлюзом Azure VPN.
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, и мы видим маршруты, полученные от него.
Затем давайте проверим маршруты, объявленные шлюзом Azure VPN, к локальному узлу 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.
Результат traceroute подтверждает, что резервное соединение через S2S VPN активно и может обеспечить непрерывность обслуживания в случае сбоя как основного, так и дополнительного подключения 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.