Mengapa VM peralatan VPN di Azure kehilangan jalur balik
Peralatan VPN di VM Azure membutuhkan UDR, flag penerusan kartu jaringan, dan kebijakan tamu yang sepakat. Ikuti satu permintaan cabang melalui ketiganya.
VM Azure yang menjalankan peralatan VPN berada di dalam dua sistem keputusan yang independen. Azure memutuskan dari mana sebuah paket meninggalkan subnet, menggunakan tabel rute dan pengaturan penerusan kartu jaringan. Sistem operasi peralatan itu sendiri memutuskan apakah paket yang didekripsi diteruskan. Terowongan yang naik dengan sempurna tetap bisa gagal di sistem kedua, dan di situlah sebagian besar penerapan ini berhenti.
Tiga pemilik satu jalur
Ambil jaringan cabang 192.168.50.0/24 dan subnet beban kerja 10.0.10.0/24, dengan peralatan berada di 10.0.0.4 di subnetnya sendiri. Satu permintaan menyentuh tiga konfigurasi terpisah.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Setiap baris dimiliki tim yang berbeda di sebagian besar organisasi, itulah sebabnya kegagalan ini biasanya datang sebagai tiga tiket alih-alih satu.
Rute yang menunjuk ke peralatan
Kaitkan tabel rute dengan subnet beban kerja dan beri prefiks cabang lompatan berikutnya bertipe Virtual appliance dengan 10.0.0.4 sebagai alamat. Gunakan alamat privat peralatan yang dapat dijangkau, jangan pernah titik masuk VPN publiknya. Lompatan berikutnya harus berupa alamat yang sudah dapat dijangkau subnet beban kerja. Biarkan sisa perutean beban kerja apa adanya, kecuali Anda sengaja memutuskan untuk mengganti rute bawaan.
Pertahankan peralatan di subnetnya sendiri, dan pastikan rute yang mengirim lalu lintas cabang ke peralatan tidak juga menangkap jalur keluar peralatan itu sendiri. Perulangan seperti itu terlihat seperti terowongan sehat tanpa jawaban, dan itu sangat tidak menyenangkan untuk di-debug pada pukul 2 pagi.
Flag kartu jaringan yang semua orang lupakan
Azure memiliki pengaturan penerusan IP per kartu jaringan, dan itu mati secara bawaan. Pengaturan itu ada karena kartu yang meneruskan menerima paket yang dialamatkan ke hal lain, dan membuangnya secara diam-diam adalah bawaan yang aman bagi semua orang.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true menyalakannya untuk satu antarmuka. Panduan Microsoft tentang penerusan pada kartu jaringan mensyaratkan pengaturan itu pada setiap kartu terpasang yang meneruskan lalu lintas, jadi peralatan satu kartu tetap memerlukannya pada kartu itu.
Flag itu bukan rute dan bukan aturan firewall. Menyalakannya memberi izin dan tidak lebih.
Apa yang dilakukan tamu dengan paket yang didekripsi
Setelah terowongan berakhir, tumpukan milik peralatan mengambil keputusan berikutnya. Pada tamu Linux, penerusan IPv4 adalah pengaturan waktu jalan, dan sysctl -w net.ipv4.ip_forward=1 bertahan hingga boot berikutnya. Simpanlah dalam sebuah berkas di /etc/sysctl.d/ sebagai gantinya. Peralatan vendor memiliki padanannya sendiri, dan instruksi Linux yang ditempel ke platform vendor biasanya tidak melakukan apa pun.
Kebijakan firewall tamu terpisah lagi, begitu juga grup keamanan jaringan beban kerja. Mengizinkan UDP 500 dan 4500 ke alamat publik VM melindungi terowongan; itu tidak mengatakan apa pun tentang apakah permintaan cabang yang didekripsi dapat mencapai port beban kerja.
Ikuti satu permintaan dan balasannya
Pilih satu aliran yang diizinkan dan telusuri dari awal sampai akhir. Cabang memerlukan rute untuk 10.0.10.0/24 melalui koneksi situs, peralatan memerlukan jalur pengiriman ke subnet beban kerja, dan subnet beban kerja memerlukan rute balik ke arah cabang.
Putuskan lebih awal apakah desain mempertahankan alamat sumber cabang atau menerjemahkannya. NAT mengubah apa yang dilihat beban kerja, jadi aturan aksesnya harus menggambarkan model yang benar-benar Anda pilih, bukan alamat gateway yang diduga.
Jabat tangan yang berhasil membuktikan satu mata rantai itu. Jalurnya lengkap ketika balasan kembali melalui peralatan yang sama dan kebijakan beban kerja itu sendiri mengizinkannya.