Hvor du skal anvende NSG'er for Azure site-to-site VPN-trafik

Site-to-site-tunnelen er oppe, den lokale klient når nogle Azure-værter og ikke andre, og nogen har knyttet en netværkssikkerhedsgruppe til GatewaySubnet for at rette det. Stop der. Azure understøtter ikke en NSG på GatewaySubnet, og gruppen kan ikke se den indre pakke, som en arbejdsbelastningsregel kan. Læg politikken på destinationsundernettet eller NIC'en, match kildeadressen der findes efter dekryptering, og verificér derefter med en ny forbindelse i stedet for en gammel.

Læg NSG'en, hvor Azure evaluerer den

Den understøttede grænse for arbejdsbelastningsfiltrering er destinationsundernettet eller destinationsnetværksgrænsefladen. Et gateway-undernet er infrastruktur, og Azure dokumenterer, at NSG'er ikke understøttes der og kan forringe gatewayens drift.

Der er også et logisk problem med placeringen. NSG'en på GatewaySubnet ville evaluere den ydre IPsec-udveksling, hvis adresser tilhører de to gateways. Din applikationsregel har brug for den private kilde inde i tunnelen, og den pakke findes først, når gatewayen dekrypterer den. Knyt gruppen til arbejdsbelastningens undernet, og reglen ser den adresse, den blev skrevet til.

Kontrollér de nuværende tilknytninger, før du ændrer noget, så du ved, hvad 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

Find kildeadressen efter dekryptering

Den indre kilde er den lokale klients private adresse, eller den adresse en appliance eller VPN-NAT præsenterer efter oversættelse. Det er ikke den offentlige adresse på den lokale VPN-gateway, som hører til den ydre udveksling.

Når NAT er en del af designet, skal du bekræfte den præsenterede kilde i stedet for at antage den. En pakkefangst på Azure-VM'en eller kildefeltet i serviceens forbindelseslog afgør spørgsmålet hurtigere end at læse den lokale konfiguration. Skriv derefter reglen mod den adresse og den rigtige destinationsport.

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

Brug en regel pr. tjeneste, du vil eksponere, og hold portlisten kort. En regel, der tillader alle porte fra det lokale område, gør NSG'en til en formalitet.

Kontrollér standardomfanget VirtualNetwork

Servicetagget VirtualNetwork er bredere end det lokale virtuelle netværk. Dets definition omfatter tilsluttede lokale adresserum, peered netværk og andre gateway-tilsluttede præfikser. Det betyder, at en standard-tilladelsesregel afgrænset til VirtualNetwork allerede kan tillade tunnel-trafik, som en operatør troede var ekstern.

Læs standardreglerne, før du tilføjer snævre, og læs hver regel med højere prioritet, der kan matche først. At tilføje en eksplicit tilladelse fjerner ikke en bredere regel, der allerede tillader flowet. Hvor politikken kræver et afslag, skal du placere det på en prioritet, der faktisk evalueres før tilladelsen.

Microsofts dokumentation om servicetags viser, hvad VirtualNetwork-tagget dækker, og det er referencen, du citerer, når nogen hævder, at tagget kun betyder VNet-området.

Læs de effektive regler ved begge grænser

Når både en undernet-NSG og en NIC-NSG gælder, skal flowet opfylde begge. En tilladelse i den ene tilsidesætter ikke et afslag i den anden, og det samlede billede er, hvad pakken faktisk møder.

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

Hvis Azure Virtual Network Manager-administratorsikkerhedsregler er i spil, skal du også gennemgå det lag. En administrativ Always allow-regel kan levere trafik uden NSG-evaluering, mens en administrativ Deny stopper den, før NSG'erne ser den. En gennemgang, der kun ser på NSG'er, er ufuldstændig for den opsætning.

Husk, at NSG'er er stateful. Redigering af en regel afslutter ikke nødvendigvis en eksisterende tilladt forbindelse, så en accepttest kræver et friskt flow. Den egenskab er nyttig i produktion og vildledende i et ændringsvindue.

Verificér med en frisk forbindelse

Åbn en ny session fra den lokale klient til serviceporten, og gentag derefter fra en vært, der bør afvises. Kør flowtesten fra VM-siden også, så du ved, at returvejen 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-tilladelse er én adgangsbeslutning, ikke en rute og ikke en listener. Hvis reglen tillader flowet, og forbindelsen stadig fejler, skal du kontrollere klientens rute ind i VPN'en, Azures returrute og værtens firewall, før du redigerer gruppen igen. Notér den faktiske kildeadresse, NSG-tilknytningerne og den matchende regel sammen med den godkendte tjeneste, fordi den næste peering- eller ruteændring kan ændre, hvad VirtualNetwork-tagget dækker.