A verificação de fluxo IP do Azure diz permitido, mas a VPN continua falhando

Túnel site-to-site conectado, VM saudável, o cliente local não recebe nada. Você abre o Network Watcher, executa a verificação de fluxo IP e ela diz Access allowed, então o chamado é fechado como problema de VPN. Esse resultado não significa o que parece, porque a verificação de fluxo IP avalia as regras de segurança do fluxo que você descreveu e nunca testa se o Azure tem uma rota para o seu prefixo local.

A pergunta de filtragem e a pergunta de roteamento são separadas, e o Network Watcher as responde com ferramentas diferentes. Saber qual você fez é a maior parte do diagnóstico.

O que a verificação de fluxo IP realmente decide

A verificação de fluxo IP recebe uma VM, uma interface de rede, uma direção, valores da quíntupla e um protocolo, e então informa a decisão da regra NSG e do administrador de segurança para esse fluxo. Funciona em TCP e UDP, portanto não é um testador de regras ICMP e um ping bloqueado não prova nada sobre o seu serviço. Dê a ela o fluxo real em vez de um palpite. Uma conexão de entrada do ambiente local para uma porta de banco de dados é uma descrição diferente de uma conexão de saída iniciada pela VM.

Se o gateway traduz endereços, use o endereço de origem que chega à fronteira que você está avaliando, não o da configuração do cliente. Leia o resultado pelo que ele é, também. Access allowed significa que a camada de filtragem permitiria o pacote se ele chegasse, e nada mais.

O que ela não pode dizer é a rota que o Azure escolheu, se o firewall do convidado permite a porta ou se algo está escutando. Isso vive em outras camadas.

O que o próximo salto e as rotas efetivas acrescentam

O próximo salto responde a uma pergunta de encaminhamento: para este destino, qual tipo de próximo salto o Azure escolhe, em qual endereço, de qual tabela de rotas. As rotas efetivas listam o que a NIC realmente tem. Execute os dois e você obtém o caminho do lado do Azure que uma verificação de fluxo IP verde deixa em branco.

A visão geral da verificação de fluxo IP da Microsoft indica o escopo da filtragem diretamente, enquanto as páginas de próximo salto e diagnóstico de rotas cobrem o lado do encaminhamento. Cite a página correta ao escrever a conclusão.

Os comandos são curtos o bastante para executá-los de um shell. az network nic show-effective-route-table lista as rotas aplicadas à interface. az network watcher show-next-hop com origem e destino retorna o salto selecionado. Compare o prefixo que importa para você com essa tabela e depois confirme qual entrada vence.

Percorra o caminho de volta a partir da NIC da VM

Faça isso a partir da NIC da VM de destino, para o prefixo do cliente local, não para a internet. O caminho de volta é onde as falhas site-to-site se escondem, porque uma verificação de status do túnel só informa que as associações de segurança estão ativas.

Se a rota esperada estiver ausente, verifique os prefixos remotos fornecidos pela configuração do gateway, o design de conectividade da VNet e qualquer ajuste de propagação de rotas. Um objeto de gateway de rede local descreve o lado local; sua existência não prova que todo prefixo necessário esteja presente e preferido na NIC. São fatos diferentes, e apenas um deles aparece em um resumo do portal.

Leia o tipo de próximo salto em vez de copiar um exemplo

Um caminho por gateway VPN gerenciado normalmente mostra VirtualNetworkGateway como tipo de próximo salto. VirtualAppliance descreve um design de encaminhamento diferente, geralmente um firewall ou um dispositivo de rede virtual.

Não crie uma rota de dispositivo apontando para um endpoint VPN suposto só porque uma resposta antiga de fórum usava esse tipo. Se uma rota definida pelo usuário substituir o caminho pretendido, encontre o proprietário e o propósito antes de alterá-la. Uma segunda NIC também pode mudar qual interface o convidado usa, e removê-la pode quebrar outro serviço em vez de corrigir esta rota.

Passe para a fronteira que ainda falha

Quando filtragem e roteamento correspondem ao design, a falha está em outro lugar. Verifique a tabela de rotas do próprio convidado, seu firewall e se o ouvinte está vinculado ao endereço esperado. Depois verifique os seletores de tráfego protegido da VPN e o caminho de resposta local. Cada um deles é um teste separado com um resultado separado.

Encerre com uma solicitação de aplicação permitida e observações das duas pontas. Um resultado allow e um próximo salto correto são duas peças de evidência, não a prova de que a conexão tenha funcionado.