Wou NSGe fir Azure Site-to-Site VPN-Trafic uwennen

Den Site-to-Site-Tunnel steet, de lokale Client erreecht e puer Azure-Hosten an anerer net, an een huet eng Netzwierksécherheetsgrupp u GatewaySubnet gehaangen, fir dat ze beheben. Halt do un. Azure ënnerstëtzt keng NSG op GatewaySubnet, an d’Grupp gesäit den internen Pak net sou wéi eng Workload-Reegel et mécht. Setzt d’Politik op de Zil-Subnet oder d’NIC, passt d’Quelladress un, déi no der Decryptioun existéiert, a verifizéiert dann mat enger neier Verbindung an net mat enger aler.

Setzt d’NSG do, wou Azure se evaluéiert

D’ënnerstëtzte Grenz fir d’Workload-Filterung ass de Zil-Subnet oder d’Zil-Netzwierkinterface. E Gateway-Subnet ass Infrastruktur, an Azure dokumentéiert, datt NSGen do net ënnerstëtzt ginn a kënnen de Betrib vum Gateway schiedegen.

Et gëtt och e logesche Problem mat der Plaz. D’NSG op GatewaySubnet géif den äusseren IPsec-Austausch evaluéieren, deem seng Adressen zu deenen zwee Gateways gehéieren. Är Applikatiounsreegel brauch déi privat Quell bannent dem Tunnel, an dee Pak existéiert eréischt nodeems de Gateway en decryptéiert. Hängt d’Grupp un de Workload-Subnet, an d’Reegel gesäit d’Adress, fir déi se geschriwwe gouf.

Kuckt déi aktuell Associatiounen un, ier Dir eppes ännert, fir ze wëssen, wat Dir verréckelt:

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

Fannt d’Quelladress no der Decryptioun

D’intern Quell ass déi privat Adress vum lokale Client, oder d’Adress, déi en Apparat oder de NAT vum VPN no der Iwwersetzung presentéiert. Et ass net déi ëffentlech Adress vum lokale VPN-Gateway, déi zum äusseren Austausch gehéiert.

Wann NAT Deel vum Design ass, bestätegt déi presentéiert Quell, amplaz se unzehuelen. Eng Pakk-Capture op der Azure-VM, oder d’Quellfeld am Verbindungslog vum Service, entscheet d’Fro méi séier wéi d’Liesen vun der lokaler Konfiguratioun. Schreift dunn d’Reegel géint déi Adress an de richtege Zilport.

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

Benotzt eng Reegel pro Service, deen Dir wëllt exponéieren, a haalt d’Portlëscht kuerz. Eng Reegel, déi all Porte vum lokalen Beräich erlaabt, mécht d’NSG zu enger Formalitéit.

Kuckt de Standardberäich VirtualNetwork un

Den Service-Tag VirtualNetwork ass méi breet wéi dat lokal virtuelle Netz. Seng Definitioun ëmfaasst verbonne lokal Adressraim, gepeerete Netzwierker an aner Prefixen, déi mam Gateway verbonne sinn. Dofir kann eng Standard-Erlaabnesreegel, déi op VirtualNetwork begrenzt ass, schonn Tunnel-Trafic erlaben, deen en Operateur als extern ugesinn huet.

Liest d’Standardreegelen, ier Dir enk bäisetzt, a liest all Reegel mat héijer Prioritéit, déi als éischt kënne passen. Eng explizit Erlaabnes bäisetzen hëlt keng méi breet Reegel ewech, déi de Floss schonn erlaabt. Wou d’Politik en Oflehnung verlaangt, setzt se op eng Prioritéit, déi tatsächlech virun der Erlaabnes evaluéiert gëtt.

Dem Microsoft seng Dokumentatioun iwwer Service-Tags zielt op, wat den Tag VirtualNetwork ofdeckt, an dat ass d’Referenz, déi een zitéiert, wann een argumentéiert, den Tag bedeit just de VNet-Beräich.

Liest déi effektiv Reegelen op béide Grenzen

Wann souwuel eng Subnet-NSG wéi och eng NIC-NSG gëllen, muss de Floss déi zwou erfëllen. Eng Erlaabnes an der enger hieft keng Oflehnung an der anerer op, an déi aggregéiert Vue ass dat, op wat de Pak tatsächlech stéisst.

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

Wann d’Sécherheets-Administratorreegelen vum Azure Virtual Network Manager am Spill sinn, kuckt déi Schicht och un. Eng administrativ Always allow-Reegel kann Trafic ouni NSG-Evaluatioun liwweren, wärend en administrativen Deny en stoppt, ier d’NSGen en gesinn. Eng Iwwerpréiwung nëmmen vun den NSGen ass onkomplett fir sou eng Opstellung.

Denkt drun, datt NSGen stateful sinn. Eng Reegel z’änneren hält net onbedéngt eng existéierend erlaabte Verbindung op, dofir brauch en Akzeptanztest e frësche Floss. Dës Eegenschaft ass a Produktioun nëtzlech an an engem Ännerungsfenster irreféierend.

Verifizéiert mat enger frëscher Verbindung

Maacht eng nei Sessioun vum lokale Client op de Serviceport op, a widderhëlt se dann vun engem Host, dee sollt ofgelehnt ginn. Féiert den Flosstest och vun der VM-Säit aus, fir ze wëssen, datt de Wee zréck intakt ass.

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

Eng NSG-Erlaabnes ass eng eenzeg Zougangsentscheedung, net eng Route an net en Listener. Wann d’Reegel de Floss erlaabt an d’Verbindung trotzdem feelt, kuckt de Wee vum Client an de VPN, dem Azure säi Wee zréck an d’Firewall vum Host un, ier Dir d’Grupp nach eng Kéier ännert. Notéiert déi tatsächlech Quelladress, d’NSG-Associatiounen an déi passend Reegel zesumme mam genehmegte Service, well déi nächst Peering- oder Routenännerung ka veränneren, wat den Tag VirtualNetwork ofdeckt.