Var NSG:er ska tillämpas för Azure site-to-site VPN-trafik

Site-to-site-tunneln är uppe, den lokala klienten når vissa Azure-värdar och andra inte, och någon har kopplat en nätverkssäkerhetsgrupp till GatewaySubnet för att åtgärda det. Stanna där. Azure stöder inte en NSG på GatewaySubnet, och gruppen ser inte det inre paketet som en arbetsbelastningsregel gör. Lägg principen på målsubnätet eller nätverkskortet, matcha källadressen som finns efter dekryptering och verifiera sedan med en ny anslutning i stället för en gammal.

Lägg NSG:n där Azure utvärderar den

Den stödda gränsen för arbetsbelastningsfiltrering är målsubnätet eller mål-nätverksgränssnittet. Ett gateway-subnät är infrastruktur, och Azure dokumenterar att NSG:er inte stöds där och kan försämra gatewayens drift.

Det finns också ett logiskt problem med placeringen. NSG:n på GatewaySubnet skulle utvärdera det yttre IPsec-utbytet, vars adresser tillhör de två gatewayerna. Din programregel behöver den privata källan inne i tunneln, och det paketet finns först efter att gatewayen dekrypterar det. Koppla gruppen till arbetsbelastningssubnätet och regeln ser den adress den skrevs för.

Kontrollera de aktuella kopplingarna innan du ändrar något, så att du vet vad du flyttar:

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

Hitta källadressen efter dekryptering

Den inre källan är den lokala klientens privata adress, eller adressen som en enhet eller VPN:ens NAT presenterar efter översättning. Det är inte den offentliga adressen för den lokala VPN-gatewayen, som hör till det yttre utbytet.

När NAT är en del av designen, bekräfta den presenterade källan i stället för att anta den. En paketinsamling på Azure-VM:en, eller källfältet i tjänstens anslutningslogg, avgör frågan snabbare än att läsa den lokala konfigurationen. Skriv sedan regeln mot den adressen och den verkliga målporten.

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

Använd en regel per tjänst du vill exponera, och håll portlistan kort. En regel som tillåter alla portar från det lokala intervallet gör NSG:n till en formalitet.

Kontrollera standardomfånget VirtualNetwork

Tjänsttaggen VirtualNetwork är bredare än det lokala virtuella nätverket. Definitionen omfattar anslutna lokala adressutrymmen, peer-nätverk och andra gateway-anslutna prefix. Därför kan en standardregel för tillåtelse begränsad till VirtualNetwork redan tillåta tunneltrafik som en operatör trodde var extern.

Läs standardreglerna innan du lägger till smala, och läs varje regel med högre prioritet som kan matcha först. Att lägga till ett uttryckligt tillåtande tar inte bort en bredare regel som redan tillåter flödet. Där principen kräver en nekan, placera den på en prioritet som faktiskt utvärderas före tillåtelsen.

Microsofts dokumentation om tjänsttaggar listar vad taggen VirtualNetwork omfattar, och det är referensen man citerar när någon hävdar att taggen bara betyder VNet-intervallet.

Läs de effektiva reglerna vid båda gränserna

När både en subnät-NSG och en NIC-NSG gäller måste flödet uppfylla båda. En tillåtelse i den ena åsidosätter inte en nekan i den andra, och den sammanlagda vyn är vad paketet faktiskt möter.

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

Om Azure Virtual Network Managers säkerhetsadministratörsregler är inblandade, granska även det lagret. En administrativ Always allow-regel kan leverera trafik utan NSG-utvärdering, medan en administrativ Deny stoppar den innan NSG:erna ser den. En granskning av enbart NSG:er är ofullständig för den ordningen.

Kom ihåg att NSG:er är stateful. Att redigera en regel avslutar inte nödvändigtvis en befintlig tillåten anslutning, så ett acceptanstest behöver ett färskt flöde. Den egenskapen är användbar i produktion och vilseledande under ett ändringsfönster.

Verifiera med en färsk anslutning

Öppna en ny session från den lokala klienten till tjänstens port och upprepa sedan från en värd som ska nekas. Kör flödestestet från VM-sidan också, så att du vet att returvägen är 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

Ett NSG-tillstånd är ett enda åtkomstbeslut, inte en rutt och inte en lyssnare. Om regeln tillåter flödet och anslutningen ändå misslyckas, kontrollera klientens rutt in i VPN:en, Azures returrutt och värdens brandvägg innan du redigerar gruppen igen. Anteckna den faktiska källadressen, NSG-kopplingarna och den matchande regeln tillsammans med den godkända tjänsten, eftersom nästa peering- eller ruttändring kan ändra vad taggen VirtualNetwork omfattar.