Kvar du bør bruke NSG-ar for Azure site-to-site VPN-trafikk

Site-to-site-tunnelen er oppe, den lokale klienten når nokre Azure-vertar og ikkje andre, og nokon har knytt ei nettverkssikkerheitsgruppe til GatewaySubnet for å rette det. Stopp der. Azure støttar ikkje ein NSG på GatewaySubnet, og gruppa ser ikkje den indre pakken slik ein arbeidslastregel gjer. Legg policyen på målsubnettet eller NIC-en, match kjeldeadressa som finst etter dekryptering, og verifiser deretter med ei ny tilkopling i staden for ei gammal.

Legg NSG-en der Azure vurderer han

Den støtta grensa for arbeidslastfiltrering er målsubnettet eller målrettverksgrensesnittet. Eit gateway-subnett er infrastruktur, og Azure dokumenterer at NSG-ar ikkje er støtta der og kan svekkje drifta av gatewayen.

Det er òg eit logisk problem med plasseringa. NSG-en på GatewaySubnet ville vurdere den ytre IPsec-utvekslinga, der adressene høyrer til dei to gatewayane. Applikasjonsregelen din treng den private kjelda inne i tunnelen, og den pakken finst først etter at gatewayen dekrypterer han. Knytt gruppa til arbeidslastsubnettet, og regelen ser adressa han vart skriven for.

Kontroller dei gjeldande tilknytingane før du endrar noko, slik at du veit kva du flyttar:

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

Finn kjeldeadressa etter dekryptering

Den indre kjelda er den private adressa til den lokale klienten, eller adressa ein appliance eller VPN-NAT presenterer etter omsetjing. Det er ikkje den offentlege adressa til den lokale VPN-gatewayen, som høyrer til den ytre utvekslinga.

Når NAT er ein del av designet, stadfest den presentererte kjelda i staden for å anta ho. Ein pakkefangst på Azure-VM-en, eller kjeldefeltet i tilkoplingsloggen til tenesta, avgjer spørsmålet raskare enn å lese den lokale konfigurasjonen. Skriv deretter regelen mot den adressa og den verkelege målporten.

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

Bruk éin regel per teneste du vil eksponere, og hald portlista kort. Ein regel som tillèt alle portar frå det lokale området, gjer NSG-en til ein formalitet.

Kontroller standardomfanget VirtualNetwork

Tenestetaggen VirtualNetwork er breiare enn det lokale virtuelle nettverket. Definisjonen omfattar tilkopla lokale adresserom, peerde nettverk og andre gateway-tilkopla prefiks. Derfor kan ein standard tillatingsregel avgrensa til VirtualNetwork allereie tillate tunneltrafikk som ein operatør trudde var ekstern.

Les standardreglane før du legg til smale, og les kvar regel med høgare prioritet som kan matche først. Å leggje til ei eksplisitt tillating fjernar ikkje ein breiare regel som allereie tillèt flyten. Der policyen krev ei avvising, plasser ho på ein prioritet som faktisk vert vurdert før tillatinga.

Microsoft sin dokumentasjon om tenestetaggar listar opp kva taggen VirtualNetwork dekkjer, og det er referansen du siterer når nokon hevdar at taggen berre betyr VNet-området.

Les dei effektive reglane ved begge grenser

Når både ein subnett-NSG og ein NIC-NSG gjeld, må flyten oppfylle begge. Ei tillating i den eine overstyrer ikkje ei avvising i den andre, og det samla bildet er det pakken faktisk møter.

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

Dersom Azure Virtual Network Manager-administratorsikkerheitsreglar er i spel, gå gjennom det laget òg. Ein administrativ Always allow-regel kan levere trafikk utan NSG-vurdering, medan ein administrativ Deny stoppar han før NSG-ane ser han. Ein gjennomgang som berre ser på NSG-ar, er ufullstendig for den ordninga.

Hugs at NSG-ar er stateful. Redigering av ein regel avsluttar ikkje nødvendigvis ei eksisterande tillaten tilkopling, så ein aksepttest treng ein fersk flyt. Den eigenskapen er nyttig i produksjon og villeiande i eit endringsvindauge.

Verifiser med ei fersk tilkopling

Opne ei ny økt frå den lokale klienten til tenesteporten, og repetér deretter frå ein vert som skal avvisast. Køyr flyttesten frå VM-sida òg, slik at du veit at returvegen er intakt.

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

Ei NSG-tillating er eitt tilgangsvedtak, ikkje ei rute og ikkje ein lyttar. Dersom regelen tillèt flyten og tilkoplinga framleis feilar, kontroller ruta til klienten inn i VPN-en, returruta til Azure og brannmuren på verten før du redigerer gruppa igjen. Noter den faktiske kjeldeadressa, NSG-tilknytingane og den matchende regelen saman med den godkjende tenesta, fordi den neste peering- eller ruteendringa kan endre kva taggen VirtualNetwork dekkjer.