Unde se aplică NSG-urile pentru traficul VPN site-to-site din Azure

Tunelul site-to-site este activ, clientul local ajunge la unele gazde Azure și la altele nu, iar cineva a atașat un grup de securitate de rețea la GatewaySubnet pentru a remedia asta. Opriți-vă acolo. Azure nu acceptă un NSG pe GatewaySubnet, iar grupul nu vede pachetul intern așa cum o face o regulă de sarcină. Puneți politica pe subrețeaua sau pe NIC-ul de destinație, potriviți adresa de sursă care există după decriptare și apoi verificați cu o conexiune nouă, nu cu una veche.

Puneți NSG-ul acolo unde Azure îl evaluează

Limita acceptată pentru filtrarea sarcinii este subrețeaua sau interfața de rețea de destinație. O subrețea de gateway este infrastructură, iar Azure documentează că NSG-urile nu sunt acceptate acolo și pot afecta funcționarea gateway-ului.

Există și o problemă de logică la plasare. NSG-ul de pe GatewaySubnet ar evalua schimbul IPsec exterior, ale cărui adrese aparțin celor două gateway-uri. Regula aplicației are nevoie de sursa privată din interiorul tunelului, iar acel pachet există doar după ce gateway-ul îl decriptează. Atașați grupul la subrețeaua de sarcină și regula va vedea adresa pentru care a fost scrisă.

Verificați asocierile curente înainte de a schimba ceva, ca să știți ce mutați:

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

Găsiți adresa de sursă după decriptare

Sursa internă este adresa privată a clientului local sau adresa pe care un aparat sau NAT-ul VPN o prezintă după traducere. Nu este adresa publică a gateway-ului VPN local, care aparține schimbului exterior.

Când NAT face parte din proiectare, confirmați sursa prezentată în loc să o presupuneți. O captură de pachete pe VM-ul Azure, sau câmpul sursă din jurnalul de conexiuni al serviciului, lămurește întrebarea mai repede decât citirea configurației locale. Apoi scrieți regula pentru acea adresă și portul de destinație real.

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

Folosiți o regulă pentru fiecare serviciu pe care vreți să îl expuneți și păstrați lista de porturi scurtă. O regulă care permite toate porturile din intervalul local transformă NSG-ul într-o formalitate.

Verificați domeniul implicit VirtualNetwork

Eticheta de serviciu VirtualNetwork este mai largă decât rețeaua virtuală locală. Definiția sa include spații de adrese locale conectate, rețele cu peering și alte prefixe conectate prin gateway. Prin urmare, o regulă implicită de permitere limitată la VirtualNetwork poate permite deja trafic de tunel pe care un operator îl credea extern.

Citiți regulile implicite înainte de a le adăuga pe cele înguste și citiți fiecare regulă cu prioritate mai mare care s-ar putea potrivi prima. Adăugarea unei permisiuni explicite nu elimină o regulă mai largă care permite deja fluxul. Unde politica cere o blocare, puneți-o la o prioritate care este într-adevăr evaluată înainte de permisiune.

Documentația Microsoft despre etichetele de serviciu enumeră ce acoperă eticheta VirtualNetwork, și aceasta este referința de citat când cineva susține că eticheta înseamnă doar intervalul VNet.

Citiți regulile efective la ambele granițe

Când se aplică atât un NSG de subrețea, cât și un NSG de NIC, fluxul trebuie să le îndeplinească pe amândouă. O permisiune într-unul nu anulează o blocare în celălalt, iar pachetul întâlnește efectiv vederea agregată.

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

Dacă sunt implicate regulile de administrator de securitate din Azure Virtual Network Manager, revizuiți și acel strat. O regulă administrativă Always allow poate livra trafic fără evaluare NSG, în timp ce o Deny administrativă îl oprește înainte ca NSG-urile să îl vadă. O revizuire doar a NSG-urilor este incompletă pentru această configurație.

Amintiți-vă că NSG-urile sunt cu stare. Editarea unei reguli nu încheie neapărat o conexiune permisă existentă, așa că un test de acceptare are nevoie de un flux nou. Această proprietate este utilă în producție și înșelătoare într-o fereastră de schimbare.

Verificați cu o conexiune nouă

Deschideți o sesiune nouă de la clientul local la portul serviciului, apoi repetați de la o gazdă care ar trebui respinsă. Rulați testul de flux și din partea VM-ului, ca să știți că drumul de întoarcere este intact.

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

O permisiune NSG este o singură decizie de acces, nu o rută și nu un ascultător. Dacă regula permite fluxul și conexiunea tot eșuează, verificați ruta clientului în VPN, ruta de întoarcere a Azure și firewall-ul gazdei înainte de a edita din nou grupul. Înregistrați adresa de sursă reală, asocierile NSG și regula potrivită împreună cu serviciul aprobat, deoarece următoarea schimbare de peering sau de rută poate modifica ce acoperă eticheta VirtualNetwork.