Dove applicare gli NSG al traffico VPN da sito a sito di Azure

Il tunnel da sito a sito è attivo, il client locale raggiunge alcuni host Azure e altri no, e qualcuno ha collegato un gruppo di sicurezza di rete a GatewaySubnet per risolverlo. Fermati lì. Azure non supporta un NSG su GatewaySubnet, e il gruppo non vede il pacchetto interno come fa una regola del carico di lavoro. Metti i criteri sulla subnet o sulla NIC di destinazione, fai corrispondere l’indirizzo di origine che esiste dopo la decifratura, poi verifica con una connessione nuova e non con una vecchia.

Metti l’NSG dove Azure lo valuta

Il confine supportato per il filtraggio del carico di lavoro è la subnet o l’interfaccia di rete di destinazione. Una subnet del gateway è infrastruttura, e Azure documenta che gli NSG non sono supportati lì e possono danneggiare il funzionamento del gateway.

C’è anche un problema di logica nella collocazione. L’NSG su GatewaySubnet valuterebbe lo scambio IPsec esterno, i cui indirizzi appartengono ai due gateway. La tua regola applicativa ha bisogno dell’origine privata dentro il tunnel, e quel pacchetto esiste solo dopo che il gateway lo decifra. Collega il gruppo alla subnet del carico di lavoro e la regola vedrà l’indirizzo per cui è stata scritta.

Controlla le associazioni attuali prima di cambiare qualcosa, così sai cosa stai spostando:

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

Trova l’indirizzo di origine dopo la decifratura

L’origine interna è l’indirizzo privato del client locale, o l’indirizzo che un dispositivo o il NAT della VPN presenta dopo la traduzione. Non è l’indirizzo pubblico del gateway VPN locale, che appartiene allo scambio esterno.

Quando il NAT fa parte del progetto, conferma l’origine presentata invece di presumerla. Una cattura di pacchetti sulla VM Azure, o il campo origine nel registro delle connessioni del servizio, risolve la questione più in fretta della lettura della configurazione locale. Poi scrivi la regola su quell’indirizzo e sulla porta di destinazione reale.

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

Usa una regola per servizio che vuoi esporre, e mantieni corto l’elenco delle porte. Una regola che consente tutte le porte dall’intervallo locale riduce l’NSG a una formalità.

Controlla l’ambito predefinito VirtualNetwork

Il tag di servizio VirtualNetwork è più ampio della rete virtuale locale. La sua definizione include spazi di indirizzi locali connessi, reti con peering e altri prefissi connessi al gateway. Quindi una regola di autorizzazione predefinita limitata a VirtualNetwork può già consentire traffico del tunnel che un operatore riteneva esterno.

Leggi le regole predefinite prima di aggiungerne di strette, e leggi ogni regola con priorità più alta che potrebbe corrispondere per prima. Aggiungere un’autorizzazione esplicita non rimuove una regola più ampia che già consente il flusso. Dove i criteri richiedono un rifiuto, mettilo a una priorità davvero valutata prima dell’autorizzazione.

La documentazione sui tag di servizio di Microsoft elenca cosa copre il tag VirtualNetwork, ed è il riferimento da citare quando qualcuno sostiene che il tag indichi solo l’intervallo della VNet.

Leggi le regole effettive a entrambi i confini

Quando si applicano sia un NSG di subnet sia un NSG di NIC, il flusso deve soddisfare entrambi. Un’autorizzazione in uno non annulla un rifiuto nell’altro, ed è la vista aggregata quella che il pacchetto incontra davvero.

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

Se sono in gioco le regole di amministrazione della sicurezza di Azure Virtual Network Manager, esamina anche quel livello. Una regola amministrativa Always allow può consegnare traffico senza valutazione dell’NSG, mentre una Deny amministrativa lo ferma prima che gli NSG lo vedano. Una revisione dei soli NSG è incompleta per questa disposizione.

Ricorda che gli NSG sono stateful. Modificare una regola non termina necessariamente una connessione consentita esistente, quindi un test di accettazione richiede un flusso nuovo. Questa proprietà è utile in produzione e fuorviante durante una finestra di cambiamento.

Verifica con una connessione nuova

Apri una nuova sessione dal client locale alla porta del servizio, poi ripeti da un host che dovrebbe essere negato. Esegui il test di flusso anche dal lato della VM, per sapere che il percorso di ritorno è intatto.

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

Un’autorizzazione NSG è una sola decisione di accesso, non una rotta e non un listener. Se la regola consente il flusso e la connessione fallisce ancora, controlla la rotta del client verso la VPN, la rotta di ritorno di Azure e il firewall dell’host prima di modificare di nuovo il gruppo. Annota l’indirizzo di origine reale, le associazioni NSG e la regola corrispondente insieme al servizio approvato, perché il prossimo cambiamento di peering o di rotta può alterare ciò che copre il tag VirtualNetwork.