Azure P2S: un cliente Windows queda sen rutas tras un cambio de VNet

Dous portátiles autentícanse na mesma pasarela Azure point-to-site e só un chega á VNet conectada recentemente. Ambos mostran Connected, así que a autenticación non é a diferenza; son as rutas de destino que manteñen. Comeza polo cliente que falla, compara un só destino e só despois decide se o oco é do paquete da pasarela ou da táboa de rutas local.

Comeza polo cliente que falla, non pola pasarela

Confirma a topoloxía antes de culpar o portátil. Comproba que VNet están conectadas á VNet da pasarela e se a rede nova está emparellada directamente ou se chega por un túnel site-to-site á parte. Se a VNet nova non está conectada á VNet da pasarela en absoluto, ningún paquete de cliente pode encamiñar cara a ela, e o portátil que funciona é a anomalía que hai que explicar. Anota a resposta, porque decide se depuras un cliente ou unha pasarela.

Cando a topoloxía cuadre, pon os dous portátiles un xunto ao outro. A mesma pasarela, o mesmo conxunto de enderezos, o mesmo protocolo e a mesma versión do cliente son a comparación que queres; calquera outra cousa é unha segunda variable que terás que eliminar despois.

Compara un destino con route print

Escolle un IP de recurso permitido e compara ambos portátiles dúas veces: desconectados e despois conectados. En Windows, route print -4 lista as rutas IPv4 co prefixo de destino, a interface, o seguinte salto e a métrica. Anota a fila que realmente gañaría para ese destino en vez de contar entradas que conteñan a palabra VPN.

A selección é primeiro o prefixo máis longo e despois a métrica, así que unha ruta local máis específica pode gañar á ruta do túnel sen parecer incorrecta. Se o destino previsto está dentro de 10.24.0.0/16, un cliente san mostra unha ruta coincidente na interface VPN, mentres que o cliente que falla envía o mesmo enderezo á súa pasarela predeterminada.

Un prefixo local en conflito pode producir o mesmo síntoma. Antes de engadir nada, decide cal dos dous casos tes: ningunha ruta de túnel, ou unha ruta de túnel que perde fronte a unha máis específica.

TTL expired non é un fallo de distribución de rutas

Un ping que devolve TTL expired in transit di que o paquete esgotou a súa cota de saltos, o que normalmente significa un bucle de reenvío e non un controlador VPN roto. O ping de Windows acepta un TTL de ata 255, e subir o valor non repara un bucle; só atrasa o mesmo erro. Trata a mensaxe como un síntoma da ruta, non como proba sobre a distribución de rutas.

Usa tracert -4 10.24.1.10 para ver onde se repite o camiño. Se os mesmos dous saltos aparecen unha e outra vez, busca unha ruta que devolva o tráfico dirixido ao túnel ao túnel ou a un encamiñador local que o reenvíe de volta.

Rexenera o paquete na pasarela que o posúe

Microsoft documenta que os paquetes de cliente de Windows deben descargarse e instalarse de novo tras cambios de topoloxía relevantes. Obtén o paquete actual da pasarela de Azure que serve este perfil e aplícao co proceso admitido para ese cliente. Substituír o executable dunha aplicación VPN non relacionada non é a mesma operación que rexenerar axustes específicos da pasarela. Volver descargar o paquete é barato; adiviñar rutas locais non o é.

Volve conectarte e volve ler a ruta do destino orixinal. Garda as filas de antes e despois co rexistro do cambio para que o resultado sexa máis preciso que reinstalei o cliente.

Os escenarios de encamiñamento de Azure P2S separan as VNet emparelladas directamente das redes ás que se chega por outros túneles, e un paquete novo non pode facer transitivo o emparellamento. Algúns escenarios Windows site-to-site ou BGP tamén necesitan rutas remotas configuradas a man, así que refrescar o paquete non é un mecanismo universal de distribución de rutas.

Mantén temporal unha ruta temporal

Unha ruta manual pode illar unha ruta de cliente ausente, pero constrúea desde o deseño real: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, sen o indicador persistente, para que desapareza ao reiniciar. Escolle o índice de interface e o seguinte salto do adaptador VPN conectado, non dunha suposición.

Non deixes unha ruta experimental como propietario competidor permanente. Actualizacións futuras do perfil poden engadir o mesmo prefixo con outra métrica, e entón a entrada manual decide en silencio que camiño gaña. Anota o paso de retirada no cambio.

Unha vez activa a ruta correcta, proba a aplicación de destino en lugar dun ping. Se os paquetes chegan a Azure pero o servizo segue fallando, revisa o grupo de seguridade de rede e o camiño de volta, porque son independentes de se o portátil aprendeu o prefixo.