使用 S2S VPN 作為 ExpressRoute 私人對等互連的備份
在標題為使用 ExpressRoute 私人對等互連為災害復原進行設計的文章中,我們討論了使用 ExpressRoute 私人對等互連時的備份連線能力解決方案需求。 我們也討論了如何使用異地備援 ExpressRoute 線路來達到高可用性。 在本文中,我們說明如何使用和維護站對站 (S2S) VPN 作為 ExpressRoute 私人對等互連的備份。
注意
在處理延遲敏感、任務關鍵性或頻寬密集型工作負載時,不建議使用站對站 VPN 作為 ExpressRoute 連線的備份解決方案。 在這種情況下,建議使用 ExpressRoute 多站台復原來設計災害復原,以確保可用性上限。
不同於異地備援 ExpressRoute 線路,您只能在主動-被動設定中使用 ExpressRoute 和 VPN 災害復原組合。 在被動模式中使用任何備份網路連線能力的主要挑戰是,被動連接通常會與主要連接一起失敗。 被動連接失敗的常見原因是缺乏主動維護。 因此,本文著重於如何驗證和主動維護備份 ExpressRoute 私人對等互連的 S2S VPN 連線能力。
注意
透過 ExpressRoute 和 VPN 公告指定的路由時,Azure 會偏好透過 ExpressRoute 進行路由。
在本文中,您也會瞭解如何從 Azure 觀點和內部部署網路邊緣端確認連線能力。 無論您是否管理與 Microsoft 網路實體對等互連的內部部署網路裝置,從任一端進行驗證的能力都會有所幫助。
範例拓撲
在我們的設定中,我們已透過 ExpressRoute 線路和 S2S VPN 連線,將內部部署網路連線至 Azure 中樞虛擬網路。 Azure 中樞虛擬網路接著會對等互連至輪輻虛擬網路,如下圖所示:
在設定中,ExpressRoute 線路會在內部部署的一對「客戶邊緣」(CE) 路由器上終止。 內部部署 LAN 會透過一對以領導人追蹤者模式運作的防火牆來連線至 CE 路由器。 S2S VPN 直接在防火牆上終止。
下表列出拓撲的主要 IP 前置詞:
實體 | Prefix |
---|---|
內部部署 LAN | 10.1.11.0/25 |
Azure 中樞虛擬網路 | 10.17.11.0/25 |
Azure 輪輻虛擬網路 | 10.17.11.128/26 |
內部部署測試伺服器 | 10.1.11.10 |
輪輻虛擬網路測試 VM | 10.17.11.132 |
ExpressRoute 主要連線 P2P 子網路 | 192.168.11.16/30 |
ExpressRoute 次要連線 P2P 子網路 | 192.168.11.20/30 |
VPN 閘道主要 BGP 對等 IP | 10.17.11.76 |
VPN 閘道次要 BGP 對等 IP | 10.17.11.77 |
內部部署防火牆 VPN BGP 對等 IP | 192.168.11.88 |
朝向防火牆 IP 的主要 CE 路由器 i/f | 192.168.11.0/31 |
朝向主要 CE 路由器 IP 的防火牆 i/f | 192.168.11.1/31 |
朝向防火牆 IP 的次要 CE 路由器 i/f | 192.168.11.2/31 |
朝向次要 CE 路由器 IP 的防火牆 i/f | 192.168.11.3/31 |
下表列出拓撲的 ASN:
自發系統 | ASN |
---|---|
內部部署 | 65020 |
Microsoft Enterprise Edge | 12076 |
虛擬網路 GW (ExR) | 65515 |
虛擬網路 GW (VPN) | 65515 |
沒有非對稱性的高可用性
為高可用性而設定
本文設定 ExpressRoute 和站對站並存連線說明如何設定並存 ExpressRoute 和 S2S VPN 連線。 如我們在使用 ExpressRoute 專為高可用性而設計時所討論,我們的設定會一直維護到端點的網路備援 (避免任何單一失敗點),從而改善 ExpressRoute 的高可用性。 此外,ExpressRoute 線路的主要和次要連線都設為主動模式,並以相同方式透過兩個連線來公告內部部署前置詞。
透過 ExpressRoute 線路的主要連線,主要 CE 路由器的內部部署路由公告如下所示 (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
透過 ExpressRoute 線路的次要連線,次要 CE 路由器的內部部署路由公告如下所示 (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 進行設定。 Azure VPN 閘道設定如下所示。 請注意,作為 VPN 設定 VPN 的一部分,也會列出閘道的 BGP 對等 IP 位址 (10.17.11.76 和10.17.11.77)。
防火牆會將內部部署路由公告至 VPN 閘道的主要和次要 BGP 對等。 路由公告如下所示 (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
注意
在主動-主動模式中設定 S2S VPN,不僅能為您的災害復原備份網路連線能力提供高可用性,還可提供更高的輸送量給備份連線能力。 因此,建議在主動-主動模式中設定 S2S VPN,因為其會建立多個基礎通道。
設定對稱流量流程
我們注意到,當指定的內部部署路由透過 ExpressRoute 和 S2S VPN 公告時,Azure 會偏好使用 ExpressRoute 路徑。 若要強制 Azure 優先使用 S2S VPN 路徑而非 ExpressRoute,您需要透過 VPN 連線來公告更特定的路由 (具有較大子網路遮罩的更長前置詞)。 我們的目標是將 VPN 連線僅作為備份使用。 因此,Azure 的預設路徑選取行為與我們的目標一致。
我們的責任是確保從內部部署流向 Azure 的流量也會優先使用 ExpressRoute 路徑而非站對站 VPN。 在內部部署設定中,CE 路由器和防火牆的預設本地喜好設定為 100。 因此,藉由設定透過 ExpressRoute 私人對等互連 (大於100) 所接收的路由本地喜好設定,我們可以讓目的地為 Azure 的流量優先使用 ExpressRoute 線路。
終止 ExpressRoute 線路主要連線的主要 CE 路由器 BGP 設定如下所示。 請注意,透過 iBGP 工作階段公告之路由的本地喜好設定值設定為 150。 同樣地,我們需要確保可終止 ExpressRoute 線路次要連線的次要 CE 路由器本地喜好設定也會設定為 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 是朝向 CE 路由器防火牆介面上的 IP。
透過 S2S VPN 的路由交換驗證
稍早在本文中,我們已向 VPN 閘道的主要和次要 BGP 對等驗證防火牆的內部部署路由公告。 此外,讓我們確認防火牆從 VPN 閘道的主要和次要 BGP 對等收到的 Azure 路由。
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 閘道具有 VPN 閘道的主要和次要 BGP 對等所接收的路由。 其也對透過主要和次要 ExpressRoute 連線 (AS-path 前綴為 12076 的連線) 所收到的路由具有可見性。 若要確認透過 VPN 連線所收到的路由,我們必須知道連線的內部部署 BGP 對等 IP。 在我們考慮的設定中,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
若看不到路由交換,則表示連線失敗。 請參閱疑難排解:Azure 站對站 VPN 連線無法連線並停止運作,以取得針對 VPN 連線進行疑難排解的協助。
測試容錯移轉
既然我們已確認透過 VPN 連線的成功路由交換 (控制平面),我們會將流量 (資料平面) 從 ExpressRoute 連線能力切換至 VPN 連線能力。
注意
在生產環境中,必須在排程的網路維護工作期間完成容錯移轉測試,因為這可能會造成服務干擾。
在進行流量切換之前,讓我們追蹤將設定中的目前路徑從內部部署測試伺服器路由傳送至輪輻虛擬網路中的測試 VM。
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,也就是主要 MSEE 的介面 IP。 MSEE 介面的存在,會確認目前的路徑正如同預期一般通過 ExpressRoute。
如在重設 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.
追蹤路由結果會確認透過 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 是針對高可用性而設計的,在 Microsoft 網路內不會有單一失敗點。 您仍然可以將 ExpressRoute 線路限制在單一地理區域和服務提供者。 S2S VPN 可以是 ExpressRoute 線路的良好災難復原被動備份解決方案。 針對可靠的被動備份連線解決方案,定期維護被動設定和定期驗證連線是很重要的。 請勿讓 VPN 設定變得過時,且定期 (假設是每季) 在維護視窗期間重複本文中所述的驗證和容錯移轉測試步驟。
若要啟用以 VPN 閘道計量為基礎的監視和警示,請參閱設定 VPN 閘道計量的警示。
若要在 ExpressRoute 失敗之後加速 BGP 聚合,請透過 Expressroute 設定 BFD。