VPN IP privat Azure melalui ExpressRoute tanpa NVA

Mitonya adalah bahwa mengenkripsi lalu lintas melalui peering privat ExpressRoute memerlukan appliance jaringan virtual. Tidak demikian. Azure mendukung Site-to-Site VPN Gateway yang endpoint terowongannya adalah alamat RFC1918 privat yang dibawa melintasi sirkuit, dan appliance bersifat opsional, bukan struktural. Yang disembunyikan mitos appliance adalah bagian yang benar-benar menggigit: mengaktifkan endpoint privat pada satu objek alih-alih dua, dan membiarkan rute peering langsung diam-diam menang atas jalur terenkripsi.

Dari mana mitos itu berasal

Klaim itu punya asal-usul yang terhormat. Bertahun-tahun resep praktis untuk IPsec melalui peering privat adalah NVA, karena gateway terkelola hanya mengekspos endpoint publik. Itu berubah, dan jawaban yang ditulis sebelum perubahan masih dikutip di utas tempat tidak ada yang memeriksa tanggalnya. Koreksinya sempit: gateway VPN dengan alamat privat ada, dan itu mengubah endpoint, bukan logika perutean di sekitarnya.

Tidak satu pun dari ini memensiunkan NVA. Ini memensiunkan asumsi bahwa appliance adalah satu-satunya jalan menuju persyaratan.

Aktifkan endpoint privat di kedua tingkat

Mulailah dari koneksi peering privat ExpressRoute yang berfungsi dan tertaut ke VNet yang berisi gateway VPN. Sisi lokal harus sudah menjangkau alamat privat yang relevan melalui sirkuit itu, karena terowongan akan memakai alamat tersebut sebagai transport. Lalu prasyarat gateway: prosedur Microsoft untuk VPN IP privat memerlukan gateway yang dibangun di atas sumber daya IP publik Standard. Pengalamatan terowongan privat tidak menghapus persyaratan itu, yang mengejutkan orang yang menganggap «privat» berarti «tidak ada IP publik di mana pun».

Sekarang aktifkan flag di kedua tempat. Konfigurasi gateway punya sakelar sendiri untuk IP privat, dan koneksi Site-to-Site individual punya sakelar kedua yang membuat koneksi itu memakai alamat privat. Menyetel satu tanpa yang lain adalah konfigurasi tidak lengkap yang paling umum; terowongan entah gagal terbentuk atau terbentuk ke endpoint yang salah.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Pastikan nama properti terhadap versi CLI yang Anda pasang, karena label portal dan properti CLI tidak selalu memakai kata yang sama. Gateway aktif-aktif mengekspos dua alamat terowongan privat, dan perangkat lokal perlu kedua peer dikonfigurasi jika Anda ingin redundansi itu berarti sesuatu. BGP tidak diperlukan hanya untuk menaikkan terowongan beralamat privat ini, meskipun biasanya menjadi bagian dari cara Anda mendistribusikan prefiks.

Mitos kedua: terowongan yang terbentuk mengenkripsi lalu lintas Anda

Dua jalur kini mencapai jaringan aplikasi: jalur peering privat langsung dan jalur melalui VPN. Keduanya berfungsi. Hanya satu yang menerapkan lapisan IPsec ini. Microsoft mendokumentasikan bahwa ketika prefiks identik diiklankan melalui ExpressRoute dan melalui VPN, Azure lebih memilih jalur ExpressRoute langsung, jadi terowongan yang sehat dengan penghitung yang sehat tidak membuktikan apa pun tentang ke mana paket aplikasi pergi.

Metode pengarahan yang didokumentasikan adalah rentang penutup pada ExpressRoute dengan rentang terlindungi yang lebih spesifik pada VPN, atau prefiks terpisah pada kedua jalur. Sebagai ilustrasi, peering privat dapat membawa 10.40.0.0/16 sementara VPN mengiklankan 10.40.12.0/24. Prefiks yang lebih spesifik menang dan sisa rentang tetap langsung.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Lakukan pemeriksaan yang sama pada arah lokal, karena preferensi router Anda menentukan arah keluar lalu lintas keluar. Dan pertahankan transport terowongan itu sendiri pada jalur ExpressRoute; rute yang menarik endpoint privat gateway ke dalam terowongan membuat terowongan bergantung pada dirinya sendiri.

Putuskan apa yang terjadi saat terowongan putus

Rute VPN yang lebih spesifik hilang saat terowongan putus, sedangkan rute langsung yang lebih luas tetap ada. Lalu lintas kemudian mengalir tanpa enkripsi dan semuanya tampak sehat, yang merupakan mode kegagalan terburuk untuk persyaratan yang ada untuk menjamin enkripsi. Jika persyaratan melarang fallback itu, perutean dan kebijakan akses harus menyatakannya secara eksplisit alih-alih mengandalkan ketersediaan terowongan.

Catat prefiks mana yang boleh tetap dapat dijangkau langsung dan mana yang harus berhenti saat jalur terenkripsi tidak ada. Lalu uji kasus yang diizinkan dengan lalu lintas nyata dan bandingkan penghitung koneksi, karena tabel rute saja tidak akan memberi tahu Anda apakah persyaratan enkripsi masih berlaku.

Kerangka itu juga memungkinkan Anda mengevaluasi NVA berdasarkan fitur sebenarnya, seperti beberapa terowongan, throughput, atau inspeksi vendor, alih-alih membelinya karena endpoint-nya privat.