Waar om NSG'e vir Azure site-tot-site VPN-verkeer toe te pas

Die site-tot-site-tonnel is op, die plaaslike kliënt bereik sommige Azure-gashere en ander nie, en iemand het ’n netwerksekuriteitsgroep aan GatewaySubnet gekoppel om dit op te los. Moenie daar stop nie. Azure ondersteun nie ’n NSG op GatewaySubnet nie, en die groep sien nie die binnepakket soos ’n werklasreël dit sien nie. Sit die beleid op die bestemmingsubnet of die NIC, pas die bronadres wat ná ontsyfering bestaan, en verifieer daarna met ’n nuwe verbinding, nie ’n ou een nie.

Sit die NSG waar Azure dit evalueer

Die ondersteunde grens vir werklasfiltrering is die bestemmingsubnet of die bestemmingsnetwerkkoppelvlak. ’n Gateway-subnet is infrastruktuur, en Azure dokumenteer dat NSG'e daar nie ondersteun word nie en die gateway se werking kan benadeel.

Daar is ook ’n logikaprobleem met die plasing. Die NSG op GatewaySubnet sou die buitenste IPsec-uitruiling evalueer, en daardie adresse behoort aan die twee gateways. Jou toepassingsreël het die private bron binne die tonnel nodig, en daardie pakket bestaan eers nadat die gateway dit ontsyfer. Koppel die groep aan die werklassubnet, dan sien die reël die adres waarvoor dit geskryf is.

Kontroleer die huidige assosiasies voordat jy iets verander, sodat jy weet wat jy skuif:

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 die bronadres ná ontsyfering

Die binneste bron is die plaaslike kliënt se private adres, of die adres wat ’n toestel of VPN-NAT ná vertaling voorhou. Dit is nie die publieke adres van die plaaslike VPN-gateway nie, want dit hoort by die buitenste uitruiling.

Wanneer NAT deel van die ontwerp is, bevestig die voorgestelde bron eerder as om dit te aanvaar. ’n Pakketopname op die Azure-VM, of die bronveld in ’n verbindingslog van die diens, beslis die vraag vinniger as om die plaaslike konfigurasie te lees. Skryf dan die reël teen daardie adres en die werklike bestemmingspoort.

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 een reël per diens wat jy wil blootstel, en hou die poortlys kort. ’n Reël wat alle poorte vanaf die plaaslike reeks toelaat, maak die NSG ’n formaliteit.

Kontroleer die verstek VirtualNetwork-omvang

Die VirtualNetwork-diensetiket is wyer as die plaaslike virtuele netwerk. Die definisie sluit gekoppelde plaaslike adresruimtes, peered netwerke en ander gateway-gekoppelde prefikse in. Dit beteken ’n verstek-toelaatreël wat op VirtualNetwork gemik is, kan reeds tonnelverkeer toelaat wat ’n operateur as ekstern beskou het.

Lees die verstekreëls voordat jy smal reëls byvoeg, en lees elke hoërprioriteitsreël wat eerste kan pas. ’n Eksplisiete toelating verwyder nie ’n breër reël wat die vloei reeds toelaat nie. Waar beleid ’n weiering vereis, plaas dit op ’n prioriteit wat werklik voor die toelating geëvalueer word.

Microsoft se dokumentasie oor diensetikette lys wat die VirtualNetwork-etiket dek, en dit is die verwysing om aan te haal wanneer iemand aanvoer dat die etiket net die VNet-omvang beteken.

Lees die effektiewe reëls by albei grense

Wanneer beide ’n subnet-NSG en ’n NIC-NSG geld, moet die vloei aan albei voldoen. ’n Toelating in die een hef nie ’n weiering in die ander op nie, en die saamgevoegde beeld is wat die pakket werklik teëkom.

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

As Azure Virtual Network Manager se sekuriteitadmin-reëls in werking is, hersien daardie laag ook. ’n Admin Always allow-reël kan verkeer lewer sonder NSG-evaluering, terwyl ’n admin Deny dit stop voordat die NSG'e dit sien. ’n Slegs-NSG-hersiening is onvolledig vir daardie reëling.

Onthou dat NSG'e toestandvast is. Om ’n reël te wysig beëindig nie noodwendig ’n bestaande toegelate verbinding nie, so ’n aanvaardingstoets het ’n vars vloei nodig. Daardie eienskap is nuttig in produksie en misleidend tydens ’n veranderingsvenster.

Verifieer met ’n vars verbinding

Maak ’n nuwe sessie van die plaaslike kliënt na die dienspoort oop, en herhaal dan vanaf ’n gasheer wat geweier moet word. Voer die vloeitoets ook van die VM-kant uit, sodat jy weet die terugpad is ongeskonde.

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

’n NSG-toelating is een toegangsbesluit, nie ’n roete en nie ’n luisteraar nie. As die reël die vloei toelaat en die verbinding steeds misluk, kontroleer die kliënt se roete in die VPN, Azure se terugroete en die gasheer se firewall voordat jy die groep weer wysig. Teken die werklike bronadres, die NSG-assosiasies en die passende reël saam met die goedgekeurde diens aan, want die volgende peering- of roeteverandering kan verander wat die VirtualNetwork-etiket dek.