ExpressRoute plus VPN: domain kegagalan mana yang Anda cakup?

Tunnel IPsec yang berjalan di atas peering privat ExpressRoute menambahkan enkripsi pada transport yang sudah ada. Tunnel kedua meningkatkan ketersediaan endpoint, dan sama sekali tidak melakukan apa pun untuk jalur operator di bawah keduanya. Perbedaan itu mudah hilang ketika dasbor menampilkan dua tunnel hijau dan tinjauan desain mengajukan pertanyaan lain: kegagalan mana yang harus dilewati koneksi ini? Jawab itu lebih dulu, lalu hitung tunnel, karena jumlah indikator hijau adalah sifat lapisan enkripsi dan jumlah domain kegagalan adalah sifat seluruh jalur.

Mulailah dari kegagalan, bukan dari tunnel hijau

Tulis empat baris sebelum menggambar apa pun: satu endpoint VPN atau instance peer gagal, satu router lokal atau koneksi mil pertama gagal, jalur ExpressRoute bersama gagal, dan IPsec menjadi tidak tersedia sementara peering privat masih membawa lalu lintas. Setiap baris menyebutkan apa yang harus dipertahankan desain, dan masing-masing dijawab oleh mekanisme berbeda.

Microsoft mendokumentasikan VPN site-to-site dengan IP privat di atas peering privat ExpressRoute, dan koeksistensi yang didukung dengan koneksi site-to-site berbasis internet. Koeksistensi itu adalah desain lapisan bawah yang berbeda, dan tidak muncul hanya karena Anda menambahkan satu lagi endpoint tunnel privat.

Domain kegagalan 1: endpoint VPN

Dua tunnel pada satu gateway biasanya pasangan active-active yang berakhir pada sumber daya sisi Azure yang sama. Keduanya melindungi dari masalah satu tunnel atau instance, dan tidak melindungi dari sumber daya itu menjadi tidak tersedia, dikonfigurasi ulang, atau kehabisan kapasitas. Redundansi endpoint berarti endpoint kedua yang didukung, dengan jalurnya sendiri dan konfigurasinya sendiri, ditambah rute yang dapat mencapainya.

Periksa apa yang sebenarnya Anda terapkan, bukan apa yang dikatakan diagram, karena portal mengelompokkan sumber daya ini dengan cara yang menyembunyikan hubungannya:

az network vpn-connection show -g rg-connectivity -n vpn-to-hub   --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub   --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'

Jika kedua tunnel menunjuk ke satu gateway dengan satu IP publik, Anda memiliki redundansi endpoint dari jenis tertentu dan terbatas. Itu mungkin persis yang diminta persyaratan, dan seharusnya dinyatakan begitu alih-alih digambarkan sebagai koneksi redundan.

Domain kegagalan 2: jalur lokal dan operator

Di bawah enkripsi ada kenyataan fisik dan komersial: perangkat tepi pelanggan, sambungan silang, jaringan penyedia, dan lokasi peering. panduan ketersediaan ExpressRoute secara eksplisit menyatakan bahwa redundansi ujung ke ujung mencakup segmen pelanggan dan penyedia layanan, bukan hanya sisi Microsoft. Dua jalur logis yang berbagi router, catu daya, atau koneksi mil pertama tetap berbagi ketergantungan itu.

Di sinilah sebuah desain biasanya gagal dalam tinjauan yang jujur. Dua sirkuit dari penyedia yang sama, berakhir di gedung yang sama, pada peralatan dari pesanan pembelian yang sama, bukanlah dua domain kegagalan. Keduanya satu domain kegagalan dengan dua faktur.

Tanyakan kepada operator secara tertulis: jalur mana yang menyimpang, di mana, dan apa perilaku terdokumentasi ketika segmen bersama gagal? Jaminan lisan saat panggilan desain tidak bertahan menghadapi gangguan yang sedang Anda rancang.

Domain kegagalan 3: rute yang bertahan tanpa IPsec

Peering privat dan IPsec dapat menawarkan rute yang bersaing ke prefiks aplikasi yang sama. Jika rute yang dilindungi hilang, rute langsung ExpressRoute yang tersisa mungkin masih dapat digunakan, tanpa lapisan enkripsi yang disediakan tunnel. Apakah itu dapat diterima adalah keputusan kebijakan, dan itulah keputusan yang paling sering dibiarkan implisit.

Persyaratan enkripsi dan persyaratan ketersediaan dapat benar-benar bertentangan di sini. «Rute apa pun yang bertahan dihitung sebagai keberhasilan» adalah pernyataan ketersediaan yang diam-diam menjawab pertanyaan enkripsi dengan «tidak». Tuliskan mana yang menang, untuk prefiks mana, dan siapa yang menyetujuinya.

az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table

Bandingkan rute yang dipelajari dengan prefiks yang Anda harapkan. Jalur cadangan yang membawa beban administratif kecil mungkin sepenuhnya memadai untuk beban itu dan jauh dari kapasitas yang dibutuhkan permintaan produksi, jadi catat asumsi kapasitas di samping rute.

Catat tiga baris terpisah, bukan satu putusan

Simpan redundansi endpoint, redundansi transport, dan pemulihan bencana sebagai entri terpisah dalam catatan desain, masing-masing dengan mekanismenya, verifikasinya, dan pemiliknya. Ketika tinjauan insiden bertanya mengapa koneksi bertahan dari restart gateway tetapi tidak dari pemutusan serat, tiga baris menjawab dalam satu kalimat; satu kotak centang «redundan» tidak bisa.

Lalu uji baris yang dapat Anda uji dengan murah. Gagalkan satu tunnel dan pastikan lalu lintas berpindah dan dienkripsi ulang. Tarik satu rute dan pastikan jalur yang bertahan adalah yang Anda maksud, lalu pastikan apakah masih terenkripsi. Dokumentasikan kegagalan yang tidak dapat Anda simulasikan, karena baris yang belum diuji adalah asumsi dan harus diberi label demikian.

Keluaran yang berguna adalah tabel singkat plus satu kalimat per baris. Jika suatu baris tidak memiliki mekanisme, itulah temuannya, dan jauh lebih murah menemukannya dalam tinjauan desain daripada selama gangguan operator yang tidak akan pernah dilewati kedua tunnel.