Azure P2S: un client Windows perde le rotte dopo un cambio di VNet

Due portatili si autenticano allo stesso gateway Azure point-to-site e solo uno raggiunge la VNet appena connessa. Entrambi mostrano Connected, quindi l'autenticazione non è la differenza; lo sono le rotte di destinazione che detengono. Parti dal client che fallisce, confronta una sola destinazione e solo dopo decidi se il divario appartiene al pacchetto del gateway o alla tabella di routing locale.

Parti dal client che fallisce, non dal gateway

Conferma la topologia prima di incolpare il portatile. Controlla quali VNet sono connesse alla VNet del gateway e se la nuova rete è peerata direttamente o raggiunta tramite un tunnel site-to-site separato. Se la nuova VNet non è affatto connessa alla VNet del gateway, nessun pacchetto client può instradare verso di essa, e il portatile funzionante è l'anomalia da spiegare. Annota la risposta, perché decide se stai eseguendo il debug di un client o di un gateway.

Una volta che la topologia è corretta, affianca i due portatili. Stesso gateway, stesso pool di indirizzi, stesso protocollo e stessa versione del client sono il confronto che vuoi; qualsiasi altra cosa è una seconda variabile da eliminare in seguito.

Confronta una destinazione con route print

Scegli un IP di risorsa consentito e confronta entrambi i portatili due volte: disconnessi e poi connessi. Su Windows, route print -4 elenca le rotte IPv4 con prefisso di destinazione, interfaccia, next hop e metrica. Registra la riga che vincerebbe davvero per quella destinazione invece di contare le voci che contengono la parola VPN.

La selezione avviene prima per prefisso più lungo, poi per metrica, quindi una rotta locale più specifica può battere la rotta del tunnel senza sembrare sbagliata. Se la destinazione prevista è dentro 10.24.0.0/16, un client sano mostra una rotta corrispondente sull'interfaccia VPN, mentre il client che fallisce invia lo stesso indirizzo al proprio gateway predefinito.

Un prefisso locale in conflitto può produrre lo stesso sintomo. Prima di aggiungere qualsiasi cosa, decidi quale dei due casi hai: nessuna rotta del tunnel, oppure una rotta del tunnel che perde contro una più specifica.

TTL expired non è un bug di distribuzione delle rotte

Un ping che restituisce TTL expired in transit indica che il pacchetto ha esaurito la sua quota di hop, il che di solito significa un loop di inoltro e non un driver VPN guasto. Il ping di Windows accetta un TTL fino a 255, e alzare il valore non ripara un loop; ritarda solo lo stesso errore. Tratta il messaggio come un sintomo del percorso, non come prova sulla distribuzione delle rotte.

Usa tracert -4 10.24.1.10 per vedere dove il percorso si ripete. Se gli stessi due hop compaiono più e più volte, cerca una rotta che rimandi il traffico diretto al tunnel dentro il tunnel o verso un router locale che lo rinvia indietro.

Rigenera il pacchetto sul gateway che lo possiede

Microsoft documenta che i pacchetti client Windows devono essere scaricati e installati di nuovo dopo modifiche topologiche rilevanti. Preleva il pacchetto corrente dal gateway Azure che serve questo profilo, poi applicalo con la procedura supportata per quel client. Sostituire l'eseguibile di un'applicazione VPN non correlata non è la stessa operazione che rigenerare impostazioni specifiche del gateway. Riscaricare il pacchetto costa poco; indovinare le rotte locali no.

Riconnettiti e rileggi la rotta per la destinazione originale. Conserva le righe prima e dopo con il record della modifica, così il risultato è più preciso di ho reinstallato il client.

Gli scenari di routing di Azure P2S separano le VNet peerate direttamente dalle reti raggiunte tramite altri tunnel, e un nuovo pacchetto non può rendere transitivo il peering. Alcuni scenari Windows site-to-site o BGP richiedono anche rotte remote configurate a mano, quindi il refresh del pacchetto non è un meccanismo universale di distribuzione delle rotte.

Mantieni temporanea una rotta temporanea

Una rotta manuale può isolare una rotta client mancante, ma costruiscila dal progetto reale: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, senza il flag persistente, così scompare al riavvio. Scegli l'indice di interfaccia e il next hop dall'adattatore VPN connesso, non da una supposizione.

Non lasciare una rotta sperimentale come proprietario concorrente permanente. Aggiornamenti futuri del profilo possono aggiungere lo stesso prefisso con un'altra metrica, e allora la voce manuale decide in silenzio quale percorso vince. Annota il passo di rimozione nella modifica.

Una volta attiva la rotta corretta, prova l'applicazione di destinazione invece di un ping. Se i pacchetti raggiungono Azure ma il servizio fallisce ancora, controlla il gruppo di sicurezza di rete e il percorso di ritorno, perché sono indipendenti dal fatto che il portatile abbia appreso il prefisso.