Hvor du bør bruke NSG-er for Azure site-to-site VPN-trafikk

Site-to-site-tunnelen er oppe, den lokale klienten når noen Azure-verter og ikke andre, og noen har knyttet en nettverkssikkerhetsgruppe til GatewaySubnet for å rette det. Stopp der. Azure støtter ikke en NSG på GatewaySubnet, og gruppen ser ikke den indre pakken slik en arbeidsbelastningsregel gjør. Legg policyen på destinasjonssubnettet eller NIC-en, match kildeadressen som finnes etter dekryptering, og verifiser deretter med en ny tilkobling i stedet for en gammel.

Legg NSG-en der Azure vurderer den

Den støttede grensen for arbeidsbelastningsfiltrering er destinasjonssubnettet eller destinasjonsnettverksgrensesnittet. Et gateway-subnett er infrastruktur, og Azure dokumenterer at NSG-er ikke støttes der og kan svekke gatewayens drift.

Det er også et logisk problem med plasseringen. NSG-en på GatewaySubnet ville vurdere den ytre IPsec-utvekslingen, der adressene tilhører de to gatewayene. Applikasjonsregelen din trenger den private kilden inne i tunnelen, og den pakken finnes først etter at gatewayen dekrypterer den. Knytt gruppen til arbeidsbelastningssubnettet, og regelen ser adressen den ble skrevet for.

Kontroller de gjeldende tilknytningene før du endrer noe, slik at du vet hva du flytter:

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 kildeadressen etter dekryptering

Den indre kilden er den lokale klientens private adresse, eller adressen en appliance eller VPN-NAT presenterer etter oversettelse. Det er ikke den offentlige adressen til den lokale VPN-gatewayen, som hører til den ytre utvekslingen.

Når NAT er en del av designet, bekreft den presenterte kilden i stedet for å anta den. En pakkefangst på Azure-VM-en, eller kildefeltet i tjenestens tilkoblingslogg, avgjør spørsmålet raskere enn å lese den lokale konfigurasjonen. Skriv deretter regelen mot den adressen og den virkelige destinasjonsporten.

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 én regel per tjeneste du vil eksponere, og hold portlisten kort. En regel som tillater alle porter fra det lokale området, gjør NSG-en til en formalitet.

Kontroller standardomfanget VirtualNetwork

Tjenestetaggen VirtualNetwork er bredere enn det lokale virtuelle nettverket. Definisjonen omfatter tilkoblede lokale adresserom, peerde nettverk og andre gateway-tilkoblede prefikser. Derfor kan en standard tillatelsesregel begrenset til VirtualNetwork allerede tillate tunneltrafikk som en operatør trodde var ekstern.

Les standardreglene før du legger til smale, og les hver regel med høyere prioritet som kan matche først. Å legge til en eksplisitt tillatelse fjerner ikke en bredere regel som allerede tillater flyten. Der policyen krever en avvisning, plasser den på en prioritet som faktisk vurderes før tillatelsen.

Microsofts dokumentasjon om tjenestetagger lister opp hva taggen VirtualNetwork dekker, og det er referansen du siterer når noen hevder at taggen bare betyr VNet-området.

Les de effektive reglene ved begge grenser

Når både en subnett-NSG og en NIC-NSG gjelder, må flyten oppfylle begge. En tillatelse i den ene overstyrer ikke en avvisning i den andre, og det samlede bildet er det pakken faktisk møter.

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

Hvis Azure Virtual Network Manager-administratorsikkerhetsregler er i spill, gjennomgå det laget også. En administrativ Always allow-regel kan levere trafikk uten NSG-vurdering, mens en administrativ Deny stopper den før NSG-ene ser den. En gjennomgang som bare ser på NSG-er, er ufullstendig for den ordningen.

Husk at NSG-er er stateful. Redigering av en regel avslutter ikke nødvendigvis en eksisterende tillatt tilkobling, så en aksepttest trenger en fersk flyt. Den egenskapen er nyttig i produksjon og villedende i et endringsvindu.

Verifiser med en fersk tilkobling

Åpne en ny økt fra den lokale klienten til tjenesteporten, og gjenta deretter fra en vert som skal avvises. Kjør flyttesten fra VM-siden også, slik at du vet at returveien 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

En NSG-tillatelse er én tilgangsbeslutning, ikke en rute og ikke en lytter. Hvis regelen tillater flyten og tilkoblingen fortsatt feiler, kontroller klientens rute inn i VPN-en, Azures returrute og vertens brannmur før du redigerer gruppen igjen. Noter den faktiske kildeadressen, NSG-tilknytningene og den matchende regelen sammen med den godkjente tjenesten, fordi den neste peering- eller ruteendringen kan endre hva taggen VirtualNetwork dekker.