O tráfego de retorno do Azure P2S VPN só funciona num sentido

O ícone do túnel está verde, o NSG parece permissivo, as rotas efetivas parecem corretas e, mesmo assim, a VM não consegue abrir uma conexão de volta ao cliente conectado. A suposição habitual é que um túnel point-to-site que funciona é simétrico: se o cliente chega à VM, a VM chega ao cliente. Essa suposição é o erro do raciocínio, não da configuração. Um túnel pode transportar uma direção de um fluxo não solicitado e descartar a outra, e a correção depende de qual camada a descarta.

Mito: um túnel conectado é um túnel bidirecional

Um túnel VPN é um caminho de política, não um cabo. Cada direção é comparada com seletores, rotas e filtros, e qualquer um deles pode permitir uma direção enquanto bloqueia a outra.

Na prática, a assimetria é comum o bastante para que a direção pertença ao primeiro teste, não ao último. O cliente inicia, o gateway acompanha o fluxo e a resposta segue o estado que foi criado. Uma VM que inicia um novo fluxo não tem esse estado, então depende de que o caminho de retorno seja explicitamente roteável e permitido. Quando esse caminho falta, a tentativa de conexão morre antes de qualquer aplicação vê-la.

Teste a direção antes de testar a acessibilidade

Escolha um endereço de cliente, um endereço de VM e um protocolo. Conecte-se a partir do cliente e registre o resultado; depois inicie o mesmo teste a partir da VM e registre também. Se o primeiro funcionar e o segundo falhar, o pool de clientes, a associação do gateway e o caminho do cliente para a VNet estão todos funcionando.

O próximo passo são evidências, não mais regras. Verifique o NSG na sub-rede da VM nos dois sentidos, leia as rotas efetivas na NIC da VM e capture pacotes na VM enquanto o cliente envia tráfego. Uma requisição que chega sem resposta é um problema de filtro ou de rota de retorno; uma requisição que nunca chega é um problema de caminho. Não trate um ping falho como prova de que a VM é inacessível, porque a política de ICMP pode descartar a resposta enquanto o TCP funciona.

O caminho de retorno do IKEv2 point-to-site é o suspeito habitual

No relatório do Azure por trás deste artigo, um cliente conseguia chegar às VMs por IKEv2, mas o ICMP de entrada da VM para o cliente falhava até que o tipo de túnel do gateway fosse trocado para OpenVPN. O autor do relatório afirma que a Microsoft confirmou uma limitação no caminho IKEv2 point-to-site, em que o tráfego de retorno de uma VM para o cliente não é roteado de forma simétrica, a menos que o cliente tenha iniciado a sessão. O IKEv2 depende de seletores de tráfego, e o gateway não respeitou a direção de retorno naquele caso.

Isso não torna o OpenVPN o melhor tipo de túnel em geral. Torna o tipo de túnel uma variável na matriz de testes para essa carga de trabalho.

Trocar o tipo de túnel é uma mudança de serviço, não um interruptor. Todo cliente precisa de um perfil compatível, e o gateway pode precisar de um certificado ou de uma configuração de autenticação diferentes. Reproduza o comportamento unidirecional com um cliente de teste e uma VM de teste, mude o tipo conforme um cronograma aprovado e repita depois os mesmos testes de direção. Se o comportamento sobreviver à troca, o tipo de túnel não era a causa e você restringiu o problema sem tocar na produção.

Mito: a descoberta por broadcast cruza a borda da VNet

Uma segunda suposição falha por um motivo não relacionado. Uma rede virtual do Azure não transporta tráfego de broadcast, então uma VM não pode receber quadros de broadcast de uma rede local por meio de uma conexão site-to-site ou point-to-site. Aplicações que encontram pares por broadcast, como a navegação de arquivos antiga ou alguns protocolos de descoberta de dispositivos, nunca verão o lado remoto, não importa como as rotas sejam escritas.

Substitua a descoberta por broadcast por nomes DNS, um serviço de diretório ou uma lista explícita de pares. Se a aplicação não tem alternativa unicast, o design precisa de outro mecanismo de descoberta, não de um túnel mais amplo.

O que mudar e como provar

Se o teste de direção falhar apenas no IKEv2, registre o tipo de túnel do gateway, o pool de endereços de clientes e o teste exato de ICMP ou TCP, e depois avalie um perfil OpenVPN aprovado para os clientes afetados. Se falhar em todos os tipos de túnel, trabalhe o caminho de retorno: o endereço do cliente deve ser roteável a partir da sub-rede da VM, qualquer rota definida pelo usuário deve apontar para um próximo salto válido, e o firewall do cliente deve aceitar o fluxo de entrada. Anexe as evidências do NSG e das rotas ao ticket.

Verifique com a aplicação, não com ping. Uma troca de ICMP bem-sucedida depois de uma mudança não diz nada sobre a porta do serviço, sua autenticação ou sua resolução de nomes. Repita o teste após uma reconexão, porque um cliente que recebe um endereço diferente do pool pode mudar o resultado. Depois repita mais uma vez após o cliente dormir e acordar, já que é em uma sessão retomada que o comportamento unidirecional costuma reaparecer.