Di mana hendak menggunakan NSG untuk trafik VPN tapak ke tapak Azure

Tunnel tapak ke tapak sudah aktif, klien setempat mencapai sesetengah hos Azure dan bukan yang lain, dan seseorang telah melampirkan kumpulan keselamatan rangkaian pada GatewaySubnet untuk membetulkannya. Berhenti di situ. Azure tidak menyokong NSG pada GatewaySubnet, dan kumpulan itu tidak dapat melihat paket dalam seperti peraturan beban kerja. Letakkan dasar pada subnet atau NIC destinasi, padankan alamat sumber yang wujud selepas penyahsulitan, dan kemudian sahkan dengan sambungan baharu, bukan sambungan lama.

Letakkan NSG di tempat Azure menilainya

Sempadan yang disokong untuk penapisan beban kerja ialah subnet atau antara muka rangkaian destinasi. Subnet gerbang ialah infrastruktur, dan Azure mendokumenkan bahawa NSG tidak disokong di sana dan boleh merosakkan operasi gerbang.

Terdapat juga masalah logik dengan penempatan. NSG pada GatewaySubnet akan menilai pertukaran IPsec luar, yang alamatnya milik kedua-dua gerbang. Peraturan aplikasi anda memerlukan sumber peribadi di dalam tunnel, dan paket itu hanya wujud selepas gerbang menyahsulitnya. Lampirkan kumpulan itu pada subnet beban kerja dan peraturan akan melihat alamat yang dimaksudkan.

Semak persatuan semasa sebelum menukar apa-apa, supaya anda tahu apa yang dialihkan:

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

Cari alamat sumber selepas penyahsulitan

Sumber dalaman ialah alamat peribadi klien setempat, atau alamat yang dikemukakan oleh perkakas atau NAT VPN selepas terjemahan. Ia bukan alamat awam gerbang VPN setempat, yang tergolong dalam pertukaran luar.

Apabila NAT ialah sebahagian daripada reka bentuk, sahkan sumber yang dikemukakan dan bukannya menganggapnya. Tangkapan paket pada VM Azure, atau medan sumber dalam log sambungan perkhidmatan, menyelesaikan persoalan lebih cepat daripada membaca konfigurasi setempat. Kemudian tulis peraturan terhadap alamat itu dan port destinasi sebenar.

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

Gunakan satu peraturan bagi setiap perkhidmatan yang ingin anda dedahkan, dan pastikan senarai port pendek. Peraturan yang membenarkan semua port daripada julat setempat menjadikan NSG sebagai formaliti.

Semak skop lalai VirtualNetwork

Tag perkhidmatan VirtualNetwork lebih luas daripada rangkaian maya setempat. Definisinya merangkumi ruang alamat setempat yang bersambung, rangkaian yang di-peer dan awalan lain yang bersambung melalui gerbang. Oleh itu, peraturan kebenaran lalai yang terhad kepada VirtualNetwork mungkin sudah membenarkan trafik tunnel yang dianggap luaran oleh pengendali.

Baca peraturan lalai sebelum menambah yang sempit, dan baca setiap peraturan berkeutamaan lebih tinggi yang mungkin sepadan dahulu. Menambah kebenaran eksplisit tidak menghapuskan peraturan lebih luas yang sudah membenarkan aliran. Jika dasar memerlukan penafian, letakkannya pada keutamaan yang benar-benar dinilai sebelum kebenaran.

Dokumentasi tag perkhidmatan Microsoft menyenaraikan apa yang diliputi oleh tag VirtualNetwork, dan itulah rujukan yang dipetik apabila seseorang berhujah bahawa tag itu hanya bermaksud julat VNet.

Baca peraturan berkesan pada kedua-dua sempadan

Apabila NSG subnet dan NSG NIC kedua-duanya terpakai, aliran mesti memenuhi kedua-duanya. Kebenaran dalam satu tidak membatalkan penafian dalam yang lain, dan pandangan agregat itulah yang sebenarnya ditemui oleh paket.

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Jika peraturan pentadbir keselamatan Azure Virtual Network Manager terlibat, semak lapisan itu juga. Peraturan pentadbir Always allow boleh menyampaikan trafik tanpa penilaian NSG, manakala Deny pentadbir menghentikannya sebelum NSG melihatnya. Semakan NSG sahaja tidak lengkap untuk susunan itu.

Ingat bahawa NSG adalah stateful. Mengedit peraturan tidak semestinya menamatkan sambungan yang telah dibenarkan, jadi ujian penerimaan memerlukan aliran baharu. Sifat itu berguna dalam pengeluaran dan mengelirukan semasa tetingkap perubahan.

Sahkan dengan sambungan baharu

Buka sesi baharu daripada klien setempat ke port perkhidmatan, kemudian ulangi daripada hos yang sepatutnya dinafikan. Jalankan ujian aliran dari sisi VM juga, supaya anda tahu laluan balik masih utuh.

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

Kebenaran NSG ialah satu keputusan akses, bukan laluan dan bukan pendengar. Jika peraturan membenarkan aliran dan sambungan masih gagal, semak laluan klien ke dalam VPN, laluan balik Azure dan tembok api hos sebelum mengedit kumpulan itu semula. Catat alamat sumber sebenar, persatuan NSG dan peraturan yang sepadan bersama perkhidmatan yang diluluskan, kerana perubahan peering atau laluan seterusnya boleh mengubah apa yang diliputi oleh tag VirtualNetwork.