Azure P2S: um cliente Windows fica sem rotas após uma mudança de VNet

Dois portáteis autenticam-se no mesmo gateway Azure point-to-site, e apenas um alcança a VNet recém-conectada. Ambos mostram Connected, portanto a autenticação não é a diferença; as rotas de destino que mantêm é que são. Comece pelo cliente que falha, compare um único destino e só depois decida se a lacuna pertence ao pacote do gateway ou à tabela de rotas local.

Comece pelo cliente que falha, não pelo gateway

Confirme a topologia antes de culpar o portátil. Verifique quais VNets estão conectadas à VNet do gateway e se a nova rede está emparelhada diretamente ou é alcançada por um túnel site-to-site separado. Se a nova VNet não estiver conectada à VNet do gateway de todo, nenhum pacote de cliente pode encaminhar para lá, e o portátil que funciona é a anomalia a explicar. Anote a resposta, porque ela decide se você está depurando um cliente ou um gateway.

Quando a topologia estiver correta, coloque os dois portáteis lado a lado. O mesmo gateway, o mesmo pool de endereços, o mesmo protocolo e a mesma versão do cliente são a comparação que você quer; qualquer outra coisa é uma segunda variável que terá de eliminar depois.

Compare um destino com route print

Escolha um IP de recurso permitido e compare os dois portáteis duas vezes: desligados e depois ligados. No Windows, route print -4 lista as rotas IPv4 com prefixo de destino, interface, próximo salto e métrica. Registre a linha que realmente venceria para esse destino em vez de contar entradas que contenham a palavra VPN.

A seleção é primeiro o prefixo mais longo e depois a métrica, então uma rota local mais específica pode vencer a rota do túnel sem parecer errada. Se o destino pretendido estiver dentro de 10.24.0.0/16, um cliente saudável mostra uma rota correspondente na interface VPN, enquanto o cliente que falha envia o mesmo endereço ao seu gateway padrão.

Um prefixo local em conflito pode produzir o mesmo sintoma. Antes de adicionar qualquer coisa, decida qual dos dois casos você tem: nenhuma rota de túnel, ou uma rota de túnel que perde para uma mais específica.

TTL expired não é um bug de distribuição de rotas

Um ping que devolve TTL expired in transit diz que o pacote esgotou a sua cota de saltos, o que geralmente significa um laço de encaminhamento e não um driver VPN quebrado. O ping do Windows aceita TTL até 255, e aumentar o valor não conserta um laço; apenas adia o mesmo erro. Trate a mensagem como sintoma do caminho, não como prova sobre a distribuição de rotas.

Use tracert -4 10.24.1.10 para ver onde o caminho se repete. Se os mesmos dois saltos aparecerem repetidamente, procure uma rota que devolva o tráfego destinado ao túnel para o túnel ou para um roteador local que o reenvie de volta.

Regenere o pacote no gateway que o possui

A Microsoft documenta que os pacotes de cliente Windows devem ser baixados e instalados novamente após mudanças de topologia relevantes. Obtenha o pacote atual do gateway Azure que atende este perfil e aplique-o com o processo suportado para esse cliente. Substituir o executável de uma aplicação VPN não relacionada não é a mesma operação que regenerar configurações específicas do gateway. Baixar o pacote outra vez é barato; adivinhar rotas locais não é.

Reconecte e releia a rota do destino original. Guarde as linhas de antes e depois com o registro da mudança para que o resultado seja mais preciso do que reinstalei o cliente.

Os cenários de encaminhamento do Azure P2S separam as VNets emparelhadas diretamente das redes alcançadas por outros túneis, e um pacote novo não pode tornar o emparelhamento transitivo. Alguns cenários Windows site-to-site ou BGP também exigem rotas remotas configuradas à mão, portanto atualizar o pacote não é um mecanismo universal de distribuição de rotas.

Mantenha uma rota temporária temporária

Uma rota manual pode isolar uma rota de cliente em falta, mas construa-a a partir do desenho real: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, sem o sinalizador persistente, para que desapareça ao reiniciar. Escolha o índice de interface e o próximo salto no adaptador VPN conectado, não numa suposição.

Não deixe uma rota experimental como proprietário concorrente permanente. Atualizações futuras do perfil podem adicionar o mesmo prefixo com outra métrica, e então a entrada manual decide em silêncio qual caminho vence. Registre o passo de remoção na mudança.

Depois de a rota correta estar ativa, teste a aplicação de destino em vez de um ping. Se os pacotes chegam ao Azure mas o serviço continua a falhar, verifique o grupo de segurança de rede e o caminho de retorno, porque são independentes de o portátil ter aprendido o prefixo.