Hvor NSG-er skal brukes for Azure site-to-site VPN-trafikk

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

Sett NSG-en der Azure evaluerer den

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

Plasseringen har også et logisk problem. NSG-en på GatewaySubnet ville vurdert den ytre IPsec-utvekslingen, hvis adresser tilhører de to gatewayene. Applikasjonsregelen din trenger den private kilden inne i tunnelen, og den pakken eksisterer først etter at gatewayen dekrypterer den. Fest 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 viser etter oversetting. Det er ikke den offentlige adressen til den lokale VPN-gatewayen, som hører til den ytre utvekslingen.

Når NAT inngår i designet, bekreft den viste kilden istedenfor å 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 så regelen mot den adressen og den faktiske 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 for VirtualNetwork

Tjenestetaggen VirtualNetwork er videre enn det lokale virtuelle nettverket. Definisjonen inkluderer tilkoblede lokale adresserom, peer-nettverk og andre gateway-tilkoblede prefikser. Derfor kan en standard tillatelsesregel begrenset til VirtualNetwork allerede tillate tunneltrafikk som en operatør oppfattet som 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 videre regel som allerede tillater flyten. Der policyen krever en blokkering, plasser den på en prioritet som faktisk vurderes før tillatelsen.

Microsofts dokumentasjon om tjenestetagger lister 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 grensene

Når både en subnett-NSG og en NIC-NSG gjelder, må flyten tilfredsstille begge. En tillatelse i den ene opphever ikke en blokkering 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 administratorsikkerhetsregler fra Azure Virtual Network Manager er i bildet, gjennomgå også det laget. 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 av bare NSG-er er ufullstendig for en slik ordning.

Husk at NSG-er er stateful. Å redigere en regel avslutter ikke nødvendigvis en eksisterende tillatt forbindelse, så en akseptansetest trenger en fersk flyt. Den egenskapen er nyttig i produksjon og misvisende i et endringsvindu.

Verifiser med en fersk tilkobling

Åpne en ny økt fra den lokale klienten til tjenesteporten, og gjenta 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 på nytt. Noter den faktiske kildeadressen, NSG-tilknytningene og den samsvarende regelen sammen med den godkjente tjenesten, fordi den neste peering- eller ruteendringen kan endre hva taggen VirtualNetwork dekker.