Onde aplicar os NSG ao tráfego VPN site a site do Azure

O túnel site a site está ativo, o cliente local alcança alguns hosts do Azure e outros não, e alguém anexou um grupo de segurança de rede ao GatewaySubnet para corrigir isso. Pare aí. O Azure não suporta um NSG no GatewaySubnet, e o grupo não vê o pacote interno como uma regra de carga de trabalho. Coloque a política na sub-rede ou na NIC de destino, faça corresponder o endereço de origem que existe após a desencriptação e, em seguida, verifique com uma ligação nova e não com uma antiga.

Coloque o NSG onde o Azure o avalia

O limite suportado para a filtragem de carga de trabalho é a sub-rede ou a interface de rede de destino. A sub-rede do gateway é infraestrutura, e o Azure documenta que os NSG não são suportados ali e podem prejudicar o funcionamento do gateway.

Também há um problema de lógica na colocação. O NSG no GatewaySubnet avaliaria a troca IPsec exterior, cujos endereços pertencem aos dois gateways. A regra da aplicação precisa da origem privada dentro do túnel, e esse pacote só existe depois de o gateway o desencriptar. Anexe o grupo à sub-rede de carga de trabalho e a regra verá o endereço para o qual foi escrita.

Verifique as associações atuais antes de alterar algo, para saber o que está a mover:

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

Encontre o endereço de origem após a desencriptação

A origem interna é o endereço privado do cliente local, ou o endereço que um equipamento ou o NAT da VPN apresenta após a tradução. Não é o endereço público do gateway VPN local, que pertence à troca exterior.

Quando o NAT faz parte do desenho, confirme a origem apresentada em vez de a assumir. Uma captura de pacotes na VM do Azure, ou o campo de origem no registo de ligações do serviço, resolve a questão mais depressa do que ler a configuração local. Depois escreva a regra para esse endereço e para a porta de destino 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

Use uma regra por serviço que pretenda expor e mantenha a lista de portas curta. Uma regra que permite todas as portas do intervalo local transforma o NSG numa formalidade.

Verifique o âmbito predefinido VirtualNetwork

A etiqueta de serviço VirtualNetwork é mais ampla do que a rede virtual local. A sua definição inclui espaços de endereços locais ligados, redes com peering e outros prefixos ligados ao gateway. Por isso, uma regra de permissão predefinida limitada a VirtualNetwork já pode permitir tráfego de túnel que um operador considerava externo.

Leia as regras predefinidas antes de acrescentar estreitas, e leia cada regra de prioridade mais alta que possa corresponder primeiro. Acrescentar uma permissão explícita não remove uma regra mais ampla que já permite o fluxo. Onde a política exigir uma negação, coloque-a numa prioridade que seja realmente avaliada antes da permissão.

A documentação de etiquetas de serviço da Microsoft lista o que a etiqueta VirtualNetwork abrange, e é a referência a citar quando alguém argumenta que a etiqueta significa apenas o intervalo da VNet.

Leia as regras efetivas nos dois limites

Quando se aplicam tanto um NSG de sub-rede como um NSG de NIC, o fluxo tem de satisfazer ambos. Uma permissão num não anula uma negação no outro, e a vista agregada é o que o pacote realmente encontra.

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

Se estiverem em jogo regras de administrador de segurança do Azure Virtual Network Manager, reveja também essa camada. Uma regra administrativa Always allow pode entregar tráfego sem avaliação do NSG, enquanto uma Deny administrativa o impede antes de os NSG o verem. Uma revisão apenas do NSG é incompleta para essa disposição.

Lembre-se de que os NSG são stateful. Editar uma regra não termina necessariamente uma ligação permitida existente, pelo que um teste de aceitação precisa de um fluxo novo. Essa propriedade é útil em produção e enganadora durante uma janela de alteração.

Verifique com uma ligação nova

Abra uma sessão nova do cliente local para a porta do serviço e depois repita a partir de um anfitrião que devia ser negado. Execute também o teste de fluxo do lado da VM, para saber que o caminho de retorno está intacto.

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

Uma permissão do NSG é uma única decisão de acesso, não uma rota nem um ouvinte. Se a regra permitir o fluxo e a ligação continuar a falhar, verifique a rota do cliente para a VPN, a rota de retorno do Azure e a firewall do anfitrião antes de voltar a editar o grupo. Registe o endereço de origem real, as associações do NSG e a regra correspondente junto do serviço aprovado, porque a próxima alteração de peering ou de rota pode alterar o que a etiqueta VirtualNetwork abrange.