VPN S2S no Azure conectada mas sem tráfego: leia o log IKE

O portal diz Connected, o túnel tem um contador de tempo de atividade e um trace da sua máquina virtual morre no segundo salto. O estado da conexão descreve a negociação IKE e IPsec, não se um único pacote sobrevive à camada de políticas de qualquer um dos lados. Duas falhas explicam a maioria desses tickets, e nenhuma delas se corrige mudando uma rota do Azure. As duas já estão escritas no log que o gateway produziu, e é por isso que começo por lá e não pela tabela de rotas.

O que o Connected realmente certifica

Uma conexão site-to-site conectada significa que as fases 1 e 2 foram concluídas e que as associações de segurança estão ativas. É uma afirmação sobre a negociação: os dois pares concordaram com uma proposta, trocaram chaves e instalaram o par de SA. Não diz nada sobre se os seletores de tráfego batem com as sub-redes que você considera protegidas, nem sobre se o lado remoto encaminhará o pacote para algum lugar depois de descriptografá-lo. Um túnel pode ficar ativo por semanas descartando cada fluxo interessante, e esse é exatamente o padrão que leva as pessoas a reconstruir um gateway saudável.

As duas falhas que vale conferir primeiro são um par que propõe AH em vez de ESP, e uma rede virtual numerada em um espaço que o gateway não tratará como interno.

Abra o log exportado antes de mexer nas rotas

No portal, abra o gateway de rede virtual e execute a operação VPN troubleshoot na conexão, depois baixe o pacote que ela gera e descompacte-o. Dentro há um log IKE com as trocas de fase 1 e fase 2, com carimbos de tempo e legível como texto simples. Procure nele a linha transform em vez de ler de cima para baixo, porque a entrada interessante costuma estar algumas centenas de linhas adiante. Se você não tem acesso ao portal, os mesmos diagnósticos aparecem no destino de logs do gateway quando as configurações de diagnóstico estão habilitadas.

Duas entradas carregam a maior parte do valor. A primeira diz mais ou menos expected ESP with combined authentication and cipher, received AH. A segunda é um erro de payload inválido durante a troca IKE, o que normalmente significa um campo de proposta malformado ou não suportado.

As duas descrevem o que o dispositivo local ofereceu, então ambas são configurações do lado do par. Regerar o lado Azure da conexão não muda a proposta que o seu firewall envia, e fazer isso mesmo assim é a hora mais desperdiçada deste fluxo de trabalho. No par, coloque a fase 2 em ESP com autenticação e cifra combinadas e deixe que ele negocie o algoritmo, e depois verifique se uma caixa do fornecedor com um nome como combined mode está selecionando silenciosamente uma proposta AH por baixo.

Confirme o espaço de endereços da rede virtual

O gateway espera que a rede virtual esteja em faixas privadas. Uma rede numerada em um bloco público, por exemplo uma que começa com 111.x, pode levantar o túnel enquanto o Azure se recusa a tratar esse espaço como interno, então a conexão parece saudável e nenhum fluxo é aceito. Confirme o espaço de endereços antes de passar uma tarde nos seletores. Se a numeração é um requisito rígido de uma alocação antiga, a correção é uma mudança no plano de endereços e não outro gateway.

Anote a sobreposição com as faixas locais enquanto você está na lâmina de espaço de endereços, porque prefixos sobrepostos produzem uma falha diferente que, do cliente, parece semelhante.

Verifique os prefixos nas duas direções

O recurso de gateway de rede local contém os prefixos locais, e eles precisam corresponder às sub-redes que o dispositivo remoto realmente protege. Um resumo que inclua endereços que o dispositivo descarta deixará passar alguns fluxos e falhará em outros, o que soa como uma falha de roteamento intermitente e não como um descompasso de configuração. Verifique também o lado remoto: uma ponta listando um /16 enquanto a outra lista três /24 dentro dele é a falha parcial clássica. Nenhuma das listas é autoritativa sozinha, então compare as duas lado a lado em vez de confiar na que você consegue ver.

Uma mudança de prefixo nem sempre é percebida sozinha, então planeje salvar novamente ou recriar o objeto de conexão e depois confirme que os novos prefixos aparecem dos dois lados.

Teste um caminho, não um ping

O trace que separa um túnel que funciona de uma rota que funciona é assim: o primeiro salto é o gateway local, depois alguns saltos que não respondem e então o host remoto responde. Se o trace nunca chega ao host, teste a porta TCP que a aplicação realmente usa, porque o ICMP é filtrado com frequência suficiente para que um ping malsucedido prove muito pouco. Execute o mesmo trace de um host remoto em direção a uma máquina virtual no Azure. A assimetria entre os dois resultados é o caminho mais rápido para achar uma rota de retorno faltando ou uma regra que permite só uma direção.

Escreva a proposta do par, os dois espaços de endereços e a hora de criação da conexão no ticket, para que o próximo engenheiro saiba quais valores foram reconstruídos e quais nunca foram tocados.

Se o log voltar vazio, pode ser que o gateway não esteja terminando a sua conexão de jeito nenhum. Confirme que o endereço do par no gateway de rede local corresponde ao dispositivo de onde você lê o log, porque dois gateways em uma assinatura se confundem facilmente durante uma reconstrução. Esse erro custa um dia e não deixa rastro em log nenhum.