UDR Azure ke gateway VPN: satu tujuan, bukan semua lalu lintas keluar

Anda menambahkan rute yang ditentukan pengguna untuk satu prefiks eksternal, mengarahkannya ke gateway VPN, dan lalu lintas tetap keluar melalui jalur internet Azure. Atau keluar dengan benar dan balasannya tidak pernah kembali. Kedua hasil itu berasal dari kesalahan yang sama: menganggap hop berikutnya di Azure sebagai keseluruhan desain. Tabel rute hanya menentukan keluar mana yang diambil paket di dalam Azure. Apa yang terjadi padanya setelah terowongan, dan bagaimana jawabannya kembali, adalah paruh kedua yang harus Anda bangun.

Hop berikutnya adalah gateway, bukan IP perangkat

UDR mengirim prefiks yang cocok ke tipe hop berikutnya, dan VirtualNetworkGateway adalah tipe, bukan alamat. Orang menempelkan IP privat gateway ke rute VirtualAppliance lalu bertanya-tanya mengapa tidak ada yang cocok, karena tipe itu mengharapkan NIC atau penyeimbang beban internal. Dokumentasi perutean Microsoft juga membatasi hop berikutnya gateway ke jaringan virtual yang gatewaynya adalah gateway VPN. ExpressRoute, Route Server, dan hub Virtual WAN tidak dialamatkan oleh opsi itu.

Periksa apa yang sebenarnya dimiliki jaringan virtual sebelum menulis rute. Jika desain merutekan melalui hub, rute itu milik pemilik perutean hub, bukan spoke yang kebetulan Anda edit.

Baca rute efektif sebelum mengubah apa pun

Azure menggabungkan rute sistem, prefiks yang dipelajari BGP, dan UDR menjadi tabel rute efektif per NIC, dan prefiks cocok terpanjang menang ke mana pun asalnya. Untuk prefiks yang sama, UDR mengalahkan rute BGP. Urutan itulah sebabnya UDR lama dari eksperimen sebelumnya dapat diam-diam menimpa prefiks yang baru saja Anda pelajari melalui terowongan.

Lihat tabel efektif lebih dulu, lalu putuskan apakah Anda menambah rute atau menggantinya:

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

Baca juga kolom sumber, bukan hanya prefiks. Rute dengan prefiks benar dan sumber salah memberi tahu Anda objek mana yang harus diedit, dan menyelamatkan Anda dari menambahkan rute kedua yang kalah dari yang pertama.

Tulis rute terhadap prefiks dan subnet yang sebenarnya

Gunakan prefiks sebenarnya tujuan, diambil dari layanan yang benar-benar Anda capai, bukan rentang publik yang disalin dari kiriman forum. Mulailah dengan satu layanan yang disetujui sebelum mempertimbangkan rute default yang memindahkan semua lalu lintas keluar. Lalu lampirkan tabel rute ke subnet beban kerja. Subnet gateway punya persyaratannya sendiri, dan melampirkan tabel Anda di sana merusak gateway alih-alih mengarahkan beban kerja.

Buat rutenya, lalu ikat tabel ke subnet yang menghosting 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

Propagasi juga penting. Dengan propagasi BGP diaktifkan pada tabel itu, prefiks yang dipelajari muncul bersama yang Anda tulis, dan prefiks yang dipelajari lebih spesifik dapat mengalahkan UDR yang lebih luas. Nonaktifkan propagasi hanya bila Anda ingin himpunan UDR menjadi otoritatif untuk subnet itu.

Selesaikan paruh lokal atau aliran mati di sana

Gateway lokal harus menerima sumber Azure, meneruskannya ke tujuan, dan mengizinkan aplikasi. Jalur lanjutnya bisa berupa jalan keluar internet atau hop privat lain, tetapi keputusan itu ada di rencana, bukan di tabel rute Azure. Kegagalan yang biasa adalah jalur balik. Tujuan di internet tidak akan merutekan sumber Azure privat kembali kepada Anda, jadi balasannya pergi ke gateway default-nya sendiri dan mati, atau tidak keluar sama sekali.

Dua desain menyelesaikannya dan keduanya tidak dapat dipertukarkan. Terjemahkan sumber di titik keluar, sehingga tujuan membalas ke alamat publik yang dimiliki jaringan lokal. Atau pertahankan sumber dan bangun hubungan balik yang dirutekan agar balasan kembali melalui terowongan. Pilih satu dan catat alamat mana yang akan dilihat aplikasi.

Selektor dan daftar izin terpisah dari semua ini. Memilih hop berikutnya di Azure tidak memperlebar selektor lalu lintas VPN, dan tidak mengubah daftar sumber yang diizinkan pada layanan eksternal.

Verifikasi dengan sumber yang diamati tujuan

Kirim permintaan dari beban kerja sebenarnya, bukan dari host lompat di subnet lain, lalu baca alamat sumber yang diamati tujuan. Satu nilai itu memberi tahu Anda desain balik mana yang terpasang. Periksa jalur balasan berikutnya, dan pastikan lalu lintas manajemen biasa ke VM masih berfungsi, karena rute default yang ditambahkan tanpa sengaja muncul sebagai sesi SSH yang rusak jauh sebelum muncul sebagai aplikasi yang rusak.

Transit melalui prefiks terpilih jauh lebih sempit daripada terowongan paksa. Jaga agar tetap sempit dan pengembaliannya adalah menghapus satu rute.