Como um aplicativo Web do Azure chega ao local por meio de uma VPN

A solicitação de saída do Web App deixa um trabalhador que você nunca vê, de uma fonte que você não escolheu, e o firewall do escritório precisa aceitá-la. Esse é todo o problema em uma frase. A integração regional da VNet fornece à solicitação um caminho para uma rede virtual, e a VPN site a site a transporta de lá. Tudo o que dá errado depois é sobre qual intervalo de origem e qual rota o pacote realmente usou.

O que o trabalhador realmente envia

O Serviço de Aplicativo executa seu código em trabalhadores que ficam fora da visualização de rede da sua assinatura. Com a integração regional habilitada, o tráfego de saída é entregue a uma sub-rede delegada em uma VNet na mesma região, e o pacote aparece lá antes de continuar. A integração não move a aplicação para a VNet e não altera o seu endereço de entrada. Isso apenas dá aos fluxos de saída um primeiro salto diferente.

Por padrão, apenas o espaço de endereço privado segue esse caminho, portanto, os destinos comuns da Internet ainda saem diretamente do trabalhador. Rotear tudo pela VNet é uma configuração e uma decisão separadas, porque também envia suas dependências públicas através do túnel.

O tráfego de configuração, como o pull de uma imagem de contêiner na inicialização, segue suas próprias regras de roteamento e pode falhar enquanto suas chamadas de API forem bem-sucedidas.

A sub-rede de integração é a fonte que você deve permitir

O escritório vê o intervalo de endereços da sub-rede de integração ou o que quer que seu dispositivo traduza, e não os endereços de saída públicos do aplicativo. Coloque esse intervalo nos seletores de tráfego da VPN do site e na regra de firewall local. Se o túnel for baseado em políticas, seletores que o omitem descartam o pacote mesmo quando existe uma rota.

Não permita nenhum endereço de funcionário que você tenha observado. As instâncias mudam com o escalonamento e a manutenção da plataforma, e uma regra fixada em um endereço é interrompida no pior momento.

Mantenha o lado do destino restrito: um serviço, uma porta, uma direção, com o caminho de retorno permitido explicitamente.

Peering e trânsito de gateway são explícitos

Se o gateway VPN estiver em uma VNet do hub e a sub-rede de integração em um spoke, o caminho precisará do trânsito do gateway permitido no peering do hub e do uso do gateway remoto habilitado no peering do spoke. O peering por si só transporta o tráfego entre as duas VNets e nada mais. As rotas efetivas na sub-rede de integração são onde você confirma que o próximo salto do gateway realmente está lá.

Um design hub-and-spoke cuja tabela de rotas envia 0.0.0.0/0 para um firewall é uma variante comum, e esse firewall precisa de sua própria regra para o prefixo local.

Desenhe o caminho no papel antes de abrir um ticket com a equipe da rede, pois isso economiza um dia de adivinhação. Inclua a direção de retorno no desenho, já que essa é a metade que as pessoas esquecem.

O endpoint privado de entrada é a outra direção

Um ponto final privado torna a aplicação acessível a partir de uma VNet. Ele não faz nada para a chamada do aplicativo para o escritório, e as equipes configuram uma regularmente, enquanto o requisito real era o inverso.

A documentação mais antiga descreve a integração necessária por gateway construída em VPN ponto a site, um recurso diferente com requisitos próprios. A Microsoft agenda a descontinuação desse recurso para 31 de março de 2027 e, em vez disso, recomenda a integração regional.

Não copie uma configuração ponto a site herdada só porque um exemplo antigo a utilizou.

Verifique com o próprio contexto do aplicativo

Teste a partir do aplicativo implantado, não do seu laptop e não de uma VM na mesma VNet. Registre o endereço resolvido, o resultado da conexão e a resposta no nível do aplicativo separadamente, porque uma falha de DNS, um tempo limite de TCP e um ponto de rejeição de autenticação em três proprietários diferentes. Se a resolução de nomes falhar, corrija o DNS privado da VNet antes de tocar no túnel.

O status do túnel verde apenas prova que o gateway está ativo. Não diz nada sobre seletores, regras de firewall ou DNS.

Quando a solicitação finalmente funcionar, grave o intervalo de origem, a porta de destino e a zona DNS no runbook do aplicativo. A próxima pessoa a depurar isso começará na sua nota, e não na página de status do gateway.