Waar u NSG's toepast voor Azure site-to-site VPN-verkeer

De site-to-site-tunnel staat, de lokale client bereikt sommige Azure-hosts en andere niet, en iemand heeft een netwerkbeveiligingsgroep aan GatewaySubnet gehangen om dat op te lossen. Stop daar. Azure ondersteunt geen NSG op GatewaySubnet, en de groep ziet het interne pakket niet zoals een workloadregel dat doet. Zet het beleid op het doelsubnet of de NIC, laat het bronadres kloppen dat na ontsleuteling bestaat, en verifieer daarna met een nieuwe verbinding in plaats van een oude.

Plaats de NSG waar Azure hem beoordeelt

De ondersteunde grens voor workloadfiltering is het doelsubnet of de doelsubnetwerkinterface. Een gatewaysubnet is infrastructuur, en Azure documenteert dat NSG's daar niet worden ondersteund en de werking van de gateway kunnen schaden.

Er is ook een logisch probleem met de plaatsing. De NSG op GatewaySubnet zou de buitenste IPsec-uitwisseling beoordelen, waarvan de adressen bij de twee gateways horen. Uw toepassingsregel heeft de privébron binnen de tunnel nodig, en dat pakket bestaat pas nadat de gateway het ontsleutelt. Hang de groep aan het workloadsubnet en de regel ziet het adres waarvoor hij is geschreven.

Controleer de huidige koppelingen voordat u iets wijzigt, zodat u weet wat u verplaatst:

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

Vind het bronadres na ontsleuteling

De interne bron is het privéadres van de lokale client, of het adres dat een apparaat of de NAT van de VPN na vertaling presenteert. Het is niet het openbare adres van de lokale VPN-gateway, dat bij de buitenste uitwisseling hoort.

Wanneer NAT deel uitmaakt van het ontwerp, bevestig dan de gepresenteerde bron in plaats van hem aan te nemen. Een pakketopname op de Azure-VM, of het bronveld in het verbindingslog van de service, beslecht de vraag sneller dan het lezen van de lokale configuratie. Schrijf de regel daarna tegen dat adres en de echte doelpoort.

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

Gebruik één regel per service die u wilt blootstellen, en houd de poortenlijst kort. Een regel die alle poorten uit het lokale bereik toestaat, maakt de NSG een formaliteit.

Controleer het standaardbereik VirtualNetwork

De servicetag VirtualNetwork is breder dan het lokale virtuele netwerk. De definitie omvat verbonden lokale adresruimten, peeringnetwerken en andere gateway-verbonden prefixen. Daarom kan een standaard toestemmingsregel die tot VirtualNetwork is beperkt al tunnelverkeer toestaan dat een beheerder als extern beschouwde.

Lees de standaardregels voordat u smalle toevoegt, en lees elke regel met hogere prioriteit die als eerste kan matchen. Een expliciete toestemming toevoegen verwijdert geen bredere regel die de stroom al toestaat. Waar het beleid een weigering vereist, plaats die op een prioriteit die echt wordt beoordeeld vóór de toestemming.

Microsofts documentatie over servicetags somt op wat de tag VirtualNetwork dekt, en dat is de referentie die u aanhaalt wanneer iemand beweert dat de tag alleen het VNet-bereik betekent.

Lees de effectieve regels aan beide grenzen

Wanneer zowel een subnet-NSG als een NIC-NSG geldt, moet de stroom aan beide voldoen. Een toestemming in de ene heft een weigering in de andere niet op, en de samengevoegde weergave is wat het pakket werkelijk tegenkomt.

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

Als beveiligingsbeheerregels van Azure Virtual Network Manager meespelen, beoordeel dan ook die laag. Een administratieve Always allow-regel kan verkeer afleveren zonder NSG-beoordeling, terwijl een administratieve Deny het stopt voordat de NSG's het zien. Een beoordeling van alleen de NSG's is onvolledig voor die opzet.

Bedenk dat NSG's stateful zijn. Het bewerken van een regel beëindigt niet noodzakelijk een bestaande toegestane verbinding, dus een acceptatietest heeft een verse stroom nodig. Die eigenschap is nuttig in productie en misleidend tijdens een wijzigingsvenster.

Verifieer met een verse verbinding

Open een nieuwe sessie van de lokale client naar de servicepoort en herhaal dat vanaf een host die geweigerd zou moeten worden. Voer de stroomtest ook vanaf de VM-kant uit, zodat u weet dat de retourroute intact is.

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

Een NSG-toestemming is één toegangsbeslissing, geen route en geen listener. Als de regel de stroom toestaat en de verbinding toch mislukt, controleer dan de route van de client naar de VPN, de retourroute van Azure en de firewall van de host voordat u de groep opnieuw bewerkt. Noteer het werkelijke bronadres, de NSG-koppelingen en de bijpassende regel samen met de goedgekeurde service, want de volgende peering- of routewijziging kan veranderen wat de tag VirtualNetwork dekt.