UDR Azure ke gatway VPN: satu destinasi, bukan semua keluar

Anda menambah laluan yang ditentukan pengguna untuk satu awalan luaran, menghalakannya ke gatway VPN, dan trafik masih keluar melalui laluan internet Azure. Atau ia keluar dengan betul dan balasannya tidak pernah kembali. Kedua-dua hasil datang daripada kesilapan yang sama: menganggap hop seterusnya Azure sebagai keseluruhan reka bentuk. Jadual laluan hanya menentukan pintu keluar mana yang diambil oleh paket di dalam Azure. Apa yang berlaku selepas terowong, dan bagaimana jawapannya kembali, ialah separuh kedua yang perlu anda bina.

Hop seterusnya ialah gatway, bukan IP peranti

UDR menghantar awalan yang sepadan kepada jenis hop seterusnya, dan VirtualNetworkGateway ialah jenis, bukan alamat. Orang menampal IP persendirian gatway ke dalam laluan VirtualAppliance lalu tertanya-tanya mengapa tiada apa yang sepadan, kerana jenis itu menjangkakan NIC atau pengimbang beban dalaman. Dokumentasi penghalaan Microsoft juga mengehadkan hop seterusnya gatway kepada rangkaian maya yang gatwaynya ialah gatway VPN. ExpressRoute, Route Server dan hab Virtual WAN tidak dialamatkan oleh pilihan itu.

Semak apa yang sebenarnya ada pada rangkaian maya sebelum menulis laluan. Jika reka bentuk menghala melalui hab, laluan itu milik pemilik penghalaan hab, bukan spoke yang kebetulan anda edit.

Baca laluan berkesan sebelum mengubah apa-apa

Azure menggabungkan laluan sistem, awalan yang dipelajari BGP dan UDR ke dalam jadual laluan berkesan bagi setiap NIC, dan awalan padanan terpanjang menang tidak kira dari mana asalnya. Untuk awalan yang sama, UDR mengalahkan laluan BGP. Susunan itulah sebabnya UDR lama daripada eksperimen terdahulu boleh menimpa awalan yang baru anda pelajari melalui terowong secara senyap.

Lihat jadual berkesan dahulu, kemudian tentukan sama ada anda menambah laluan atau menggantikannya:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Baca juga lajur sumber, bukan hanya awalan. Laluan dengan awalan betul dan sumber salah memberitahu anda objek mana yang perlu diedit, dan menyelamatkan anda daripada menambah laluan kedua yang kalah kepada yang pertama.

Tulis laluan mengikut awalan dan subnet sebenar

Gunakan awalan sebenar destinasi, diambil daripada perkhidmatan yang benar-benar anda capai, bukan julat awam yang disalin daripada catatan forum. Mulakan dengan satu perkhidmatan yang diluluskan sebelum mempertimbangkan laluan lalai yang memindahkan semua keluar. Kemudian lampirkan jadual laluan pada subnet beban kerja. Subnet gatway mempunyai keperluannya sendiri, dan melampirkan jadual anda di situ merosakkan gatway dan bukan menghala beban kerja.

Cipta laluan, kemudian ikat jadual pada subnet yang menempatkan beban kerja:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Penyebaran juga penting. Dengan penyebaran BGP diaktifkan pada jadual itu, awalan yang dipelajari muncul bersama yang anda tulis, dan awalan yang dipelajari lebih khusus boleh mengalahkan UDR yang lebih luas. Lumpuhkan penyebaran hanya apabila anda mahu set UDR menjadi berwibawa untuk subnet itu.

Selesaikan separuh di premis atau aliran mati di sana

Gatway di premis mesti menerima sumber Azure, memajukannya ke destinasi dan membenarkan aplikasi. Laluan seterusnya boleh menjadi pintu keluar internet atau hop persendirian lain, tetapi keputusan itu terletak pada pelan, bukan pada jadual laluan Azure. Kegagalan biasa ialah laluan balik. Destinasi internet tidak akan menghala sumber Azure persendirian kembali kepada anda, jadi balasan pergi ke gatway lalainya sendiri dan mati, atau tidak keluar sama sekali.

Dua reka bentuk menyelesaikannya dan kedua-duanya tidak boleh ditukar ganti. Terjemahkan sumber di pintu keluar, supaya destinasi membalas ke alamat awam yang dimiliki rangkaian di premis. Atau kekalkan sumber dan bina hubungan balik yang dihalakan supaya balasan kembali melalui terowong. Pilih satu dan catat alamat mana yang akan dilihat oleh aplikasi.

Pemilih dan senarai benarkan adalah berasingan daripada semua ini. Memilih hop seterusnya Azure tidak meluaskan pemilih trafik VPN, dan tidak mengubah senarai sumber dibenarkan sesuatu perkhidmatan luaran.

Sahkan dengan sumber yang diperhatikan destinasi

Hantar permintaan daripada beban kerja sebenar dan bukan daripada hos lompat di subnet lain, kemudian baca alamat sumber yang diperhatikan destinasi. Nilai tunggal itu memberitahu anda reka bentuk balik mana yang terpakai. Semak laluan balasan seterusnya, dan pastikan trafik pengurusan biasa ke VM masih berfungsi, kerana laluan lalai yang ditambah secara tidak sengaja muncul sebagai sesi SSH yang terputus jauh sebelum ia muncul sebagai aplikasi yang rosak.

Transit melalui awalan terpilih jauh lebih sempit daripada terowong paksa. Kekalkan ia sempit dan pengunduran ialah memadam satu laluan.