Menggunakan S2S VPN (VPN Situs-ke-Situs) sebagai cadangan untuk peering privat ExpressRoute
Dalam artikel berjudul Merancang untuk pemulihan bencana dengan peering privat ExpressRoute, kami membahas kebutuhan akan solusi konektivitas cadangan saat menggunakan peering privat ExpressRoute. Kami juga membahas cara menggunakan sirkuit ExpressRoute geo-redundan untuk ketersediaan tinggi. Dalam artikel ini, kami menjelaskan cara menggunakan dan memelihara VPN situs-ke-situs (S2S) sebagai cadangan untuk peering privat ExpressRoute.
Catatan
Menggunakan VPN situs-ke-situs sebagai solusi cadangan untuk konektivitas ExpressRoute tidak disarankan saat berhadapan dengan beban kerja yang sensitif terhadap latensi, misi-kritis, atau bandwidth intensif. Dalam kasus seperti itu, disarankan untuk merancang pemulihan bencana dengan ketahanan multi-situs ExpressRoute untuk memastikan ketersediaan maksimum.
Tidak seperti sirkuit ExpressRoute geo-redundan, Anda hanya dapat menggunakan kombinasi pemulihan bencana ExpressRoute dan VPN dalam penyiapan pasif aktif. Tantangan utama menggunakan konektivitas jaringan cadangan apa pun dalam mode pasif adalah bahwa sambungan pasif akan sering gagal bersama sambungan utama. Alasan umum kegagalan sambungan pasif adalah kurangnya pemeliharaan aktif. Oleh karena itu, dalam artikel ini, fokusnya adalah pada cara memverifikasi dan secara aktif mempertahankan konektivitas VPN S2S yang mencadangkan peering privat ExpressRoute.
Catatan
Ketika rute tertentu diiklankan melalui ExpressRoute dan VPN, Azure akan lebih suka perutean daripada ExpressRoute.
Dalam artikel ini, Anda juga mempelajari cara memverifikasi konektivitas dari perspektif Azure dan sisi tepi jaringan lokal. Kemampuan untuk memvalidasi dari kedua sisi membantu terlepas dari apakah Anda mengelola perangkat jaringan lokal yang melakukan peering dengan entitas jaringan Microsoft atau tidak.
Contoh topologi
Dalam penyiapan kami, kami memiliki jaringan lokal yang terhubung ke jaringan virtual hub Azure melalui sirkuit ExpressRoute dan koneksi VPN S2S. Jaringan virtual hub Azure pada gilirannya di-peering ke jaringan virtual spoke, seperti yang ditunjukkan dalam diagram:
Dalam pengaturan, sirkuit ExpressRoute dihentikan pada sepasang router tepi pelanggan (CE) di lokal. LAN lokal terhubung ke router CE dengan sepasang firewall yang beroperasi dalam mode leader-follower. S2S VPN (VPN Situs-ke-Situs) langsung dihentikan pada firewall.
Tabel berikut mencantumkan awalan IP kunci dari topologi jaringan:
| Entitas | Awalan |
|---|---|
| LAN Lokal | 10.1.11.0/25 |
| Jaringan virtual Azure Hub | 10.17.11.0/25 |
| Jaringan virtual azure spoke | 10.17.11.128/26 |
| Server pengujian lokal | 10.1.11.10 |
| VM pengujian jaringan virtual spoke | 10.17.11.132 |
| Subnet P2P koneksi utama ExpressRoute | 192.168.11.16/30 |
| Subnet P2P koneksi sekunder ExpressRoute | 192.168.11.20/30 |
| VPN gateway primer BGP peer IP | 10.17.11.76 |
| VPN gateway primer BGP peer IP | 10.17.11.77 |
| Firewall lokal VPN BGP peer IP | 192.168.11.88 |
| Router CE primer i/f menuju IP firewall | 192.168.11.0/31 |
| Firewall i/f menuju IP router CE primer | 192.168.11.1/31 |
| Router CE primer i/f menuju IP firewall | 192.168.11.2/31 |
| Router CE primer i/f menuju IP firewall | 192.168.11.3/31 |
Tabel berikut ini mencantumkan ASN (Nomor Sistem Otonom) dari topologi:
| Sistem otonom | ASN (Nomor Sistem Otonom) |
|---|---|
| Lokal | 65020 |
| Tepi Perusahaan Microsoft | 12076 |
| Jaringan Virtual GW (ExR) | 65515 |
| Jaringan Virtual GW (VPN) | 65515 |
Ketersediaan tinggi tanpa asimetrisitas
Mengonfigurasi ketersediaan tinggi
Artikel Mengonfigurasi koneksi expressRoute dan Situs-ke-Situs yang berdampingan menjelaskan cara menyiapkan koneksi ExpressRoute dan S2S VPN yang berdampingan. Seperti yang kami sebutkan dalam Merancang ketersediaan tinggi dengan ExpressRoute, pengaturan kami memastikan redundansi jaringan untuk menghilangkan satu titik kegagalan hingga titik akhir, yang meningkatkan ketersediaan tinggi ExpressRoute. Selain itu, koneksi utama dan sekunder sirkuit ExpressRoute aktif dan mengiklankan awalan lokal dengan cara yang sama melalui kedua koneksi.
Iklan rute lokal router CE utama melalui koneksi utama sirkuit ExpressRoute ditampilkan sebagai berikut (perintah 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
Iklan rute lokal router CE sekunder melalui koneksi sekunder sirkuit ExpressRoute ditampilkan sebagai berikut (perintah 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
Untuk meningkatkan ketersediaan tinggi sambungan cadangan, VPN Situs-ke-Situs juga dikonfigurasi dalam mode aktif-aktif. Konfigurasi gateway Azure VPN ditampilkan sebagai berikut. Catatan sebagai bagian dari VPN konfigurasi VPN alamat IP peer BGP gateway--10.17.11.76 dan 10.17.11.77--juga terdaftar.
Rute lokal diiklankan oleh firewall ke rekan BGP utama dan sekunder gateway VPN. Iklan rute ditampilkan sebagai berikut (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
Catatan
Mengonfigurasi VPN S2S dalam mode aktif-aktif tidak hanya menyediakan ketersediaan tinggi untuk konektivitas jaringan cadangan pemulihan bencana Anda, tetapi juga menyediakan throughput yang lebih tinggi untuk konektivitas cadangan. Oleh karena itu, mengonfigurasi VPN S2S dalam mode aktif-aktif disarankan karena akan membuat beberapa terowongan yang mendasar.
Mengonfigurasi untuk arus lalu lintas simetris
Kami mencatat bahwa ketika rute lokal tertentu diiklankan melalui ExpressRoute dan S2S VPN, Azure akan lebih memilih jalur ExpressRoute. Untuk memaksa Azure lebih memilih jalur VPN S2S daripada ExpressRoute yang sudah ada, Anda perlu mengiklankan rute yang lebih spesifik (awalan yang lebih panjang dengan subnet mask yang lebih besar) melalui koneksi VPN. Tujuan kami adalah menggunakan koneksi VPN sebagai cadangan saja. Jadi, perilaku pemilihan jalur default Azure sejalan dengan tujuan kami.
Merupakan tanggung jawab kami untuk memastikan bahwa lalu lintas yang ditujukan ke Azure dari lokal juga lebih memilih jalur ExpressRoute daripada VPN Situs-ke-situs. Preferensi lokal default router dan firewall CE dalam pengaturan lokal kami adalah 100. Jadi, dengan mengonfigurasi preferensi lokal rute yang diterima melalui peering privat ExpressRoute lebih besar dari 100, kita dapat membuat lalu lintas yang ditujukan untuk Azure lebih memilih sirkuit ExpressRoute.
Konfigurasi BGP router CE utama yang mengakhiri koneksi utama sirkuit ExpressRoute ditampilkan sebagai berikut. Perhatikan nilai preferensi lokal rute yang diiklankan selama sesi iBGP dikonfigurasi menjadi 150. Demikian pula, kita perlu memastikan preferensi lokal router CE sekunder yang mengakhiri sambungan sekunder sirkuit ExpressRoute juga dikonfigurasi menjadi 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;
}
}
}
Tabel perutean firewall lokal mengonfirmasi bahwa untuk lalu lintas lokal yang ditujukan ke Azure jalur pilihan melebihi ExpressRoute dalam keadaan stabil.
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
Dalam tabel rute di atas, untuk rute jaringan virtual hub dan spoke--10.17.11.0/25 dan 10.17.11.128/26--kami melihat sirkuit ExpressRoute lebih disukai daripada koneksi VPN. 192.168.11.0 dan 192.168.11.2 adalah IP pada firewall antarmuka menuju router CE.
Validasi pertukaran rute melalui VPN S2S (Situs-ke-Situs)
Sebelumnya dalam artikel ini, kami memverifikasi iklan rute lokal firewall ke peer BGP (Protokol Batas Gerbang) primer dan sekunder gateway VPN. Selain itu, mari kita konfirmasi rute Azure yang diterima oleh firewall dari peer BGP (Protokol Batas Gerbang) primer dan sekunder gateway 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
Demikian pula mari kita verifikasi untuk awalan rute jaringan lokal yang diterima oleh gateway 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
Seperti yang terlihat sebelumnya, gateway VPN memiliki rute yang diterima oleh serekan BGP primer dan sekunder gateway VPN. Ini juga memiliki visibilitas atas rute yang diterima melalui sambungan ExpressRoute primer dan sekunder (yang dengan jalur-AS yang telah ditentukan sebelumnya dengan 12076). Untuk mengkonfirmasi rute yang diterima melalui sambungan VPN, kita perlu mengetahui IP peer BGP (Protokol Batas Gerbang) lokal dari sambungannya. Dalam penyiapan kami yang sedang dipertimbangkan, IP adalah 192.168.11.88 dan kami melihat rute yang diterima darinya.
Selanjutnya, mari kita verifikasi rute yang diiklankan oleh gateway VPN Azure ke peer BGP firewall lokal (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
Kegagalan untuk melihat pertukaran rute menunjukkan kegagalan sambungan. Lihat Pemecahan Masalah: Koneksi VPN situs-ke-situs Azure tidak dapat tersambung dan berhenti berfungsi untuk bantuan dalam memecahkan masalah koneksi VPN.
Kegagalan pengujian
Sekarang setelah kami mengonfirmasi pertukaran rute yang berhasil melalui koneksi VPN (sarana kontrol), kami diatur untuk mengalihkan lalu lintas (data plane) dari konektivitas ExpressRoute ke konektivitas VPN.
Catatan
Di lingkungan produksi pengujian failover harus dilakukan selama jendela kerja pemeliharaan jaringan terjadwal karena dapat mengganggu layanan.
Sebelum melakukan pengalihan lalu lintas, mari kita lacak rute jalur saat ini di pengaturan kami dari server pengujian lokal ke VM pengujian di jaringan virtual spoke.
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.
Subnet sambungan titik-ke-titik ExpressRoute primer dan sekunder dari pengaturan kami adalah, masing-masing, 192.168.11.16/30 dan 192.168.11.20/30. Dalam rute pelacakan di atas, pada langkah 3 kita melihat bahwa kita mencapai 192.168.11.18, yang merupakan IP antarmuka MSEE utama. Kehadiran antarmuka MSEE mengkonfirmasi bahwa seperti yang diharapkan jalur kami saat ini adalah melalui ExpressRoute.
Seperti yang dilaporkan dalam reset peering sirkuit ExpressRoute, mari kita gunakan perintah PowerShell berikut untuk menonaktifkan peering utama dan sekunder sirkuit ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Waktu pengalihan kegagalan tergantung pada waktu konvergensi BGP (Protokol Batas Gerbang). Dalam pengaturan kami, pengalihan kegagalan membutuhkan beberapa detik (kurang dari 10). Setelah pengalihan, pengulangan traceroute memperlihatkan jalur berikut:
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.
Hasil traceroute mengkonfirmasi bahwa sambungan cadangan melalui VPN S2S (Situs-ke-Situs) aktif dan dapat memberikan kelangsungan layanan jika sambungan ExpressRoute primer dan sekunder gagal. Untuk menyelesaikan pengujian failover, mari kita aktifkan sambungan ExpressRoute kembali dan menormalkan arus lalu lintas, menggunakan serangkaian perintah berikut.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Untuk mengonfirmasi bahwa lalu lintas dialihkan kembali ke ExpressRoute, ulangi traceroute dan pastikan lalu lintas tersebut akan melalui peering privat ExpressRoute.
Langkah berikutnya
ExpressRoute dirancang untuk ketersediaan tinggi tanpa satu titik kegagalan pun dalam jaringan Microsoft. Tetap saja sirkuit ExpressRoute terbatas pada satu wilayah geografis dan penyedia layanan. VPN S2S (Situs-ke-Situs) dapat menjadi solusi cadangan pasif pemulihan bencana yang baik untuk sirkuit ExpressRoute. Untuk solusi sambungan cadangan pasif yang dapat diandalkan, pemeliharaan rutin konfigurasi pasif dan validasi berkala sambungan adalah penting. Sangat penting untuk tidak membiarkan konfigurasi VPN menjadi kedaluarsa, dan untuk secara berkala (katakanlah setiap kuartal) ulangi langkah-langkah pengujian validasi dan failover yang dijelaskan dalam artikel ini selama jendela pemeliharaan.
Untuk mengaktifkan pemantauan dan pemberitahuan berdasarkan metrik gateway VPN, lihat Menyiapkan pemberitahuan pada metrik VPN Gateway.
Untuk mempercepat konvergensi BGP (Protokol Batas Gerbang) setelah kegagalan ExpressRoute, Konfigurasikan BFD (Deteksi Penerusan Dua Arah) melalui ExpressRoute.