Una rotta VPN ancorata a un indice di interfaccia si rompe alla riconnessione

La rotta ha funzionato per settimane e poi ha iniziato a inviare traffico nel nulla, con la destinazione invariata e nulla di modificato. Ciò che è cambiato è il numero: una rotta creata rispetto a un indice di interfaccia preciso fa riferimento a un adattatore che non esiste più dopo una riconnessione, e il prefisso di destinazione continua a puntare a un’infrastruttura che è stata sostituita. Aggiungere persistenza a quel comando non aiuta, perché il problema non è mai stato se la rotta sopravvivesse a un riavvio. La soluzione è legare l’intenzione alla connessione, che per progettazione sopravvive ai cambi di adattatore.

Verificate a cosa punta davvero la rotta

Iniziate leggendo la voce di rotta e gli adattatori fianco a fianco. Una rotta con il salto successivo sull’interfaccia VPN e un indice che non corrisponde a nessun adattatore attuale è la firma di questo guasto; lo stesso prefisso su un altro indice è o un residuo o la rotta che volete davvero. Leggete entrambi gli elenchi prima di modificarne uno, perché il confronto interessante è tra il numero nella rotta e i numeri che esistono adesso. Se l’indice della rotta compare nell’elenco degli adattatori, l’indice non è il vostro problema e la ricerca passa a metriche, criteri o all’estremità remota. Se non compare, non c’è altro da diagnosticare: la rotta è legata a un’infrastruttura che non esiste più.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

La colonna Store distingue una voce che persiste tra i riavvii da una che scompare con l’adattatore, e questa differenza determina se il guasto tornerà domani. Una voce nell’archivio persistente che punta a un indice svanito è il caso peggiore, perché sopravvive ai riavvii senza mai corrispondere a nulla.

Legate il prefisso al profilo, non all’adattatore

Un VPN nativo di Windows può portare il proprio elenco di rotte, così la connessione riutilizza l’adattatore corretto ogni volta che sale. La rotta segue allora il profilo invece di un numero che avete osservato una volta, e nessuno script deve indovinare un indice dopo ogni chiamata. Aggiungere un prefisso è anche reversibile tramite il comando di rimozione corrispondente, il che mantiene la modifica verificabile. Il prefisso è memorizzato con la connessione invece che in uno script di avvio, così un profilo copiato a un altro utente porta l’intenzione con sé.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

Il riferimento di Add-VpnConnectionRoute documenta l’associazione alla connessione, e l’ambito della rubrica conta: un profilo per utente e un profilo per tutti gli utenti sono oggetti diversi. Questo meccanismo appartiene al client VPN di Windows stesso, quindi un adattatore di fornitore gestito dal proprio servizio può prendere le sue rotte da una fonte di criteri del tutto diversa.

Pulite le vecchie rotte prima di aggiungere quella nuova

Due rotte con lo stesso prefisso e proprietari diversi sono peggio di una rotta sbagliata, perché il vincitore dipende da metriche che nessuno ha annotato. Ispezionate ciò che esiste già per il prefisso, comprese le voci nell’archivio persistente, e rimuovete solo ciò che appartiene al tentativo fallito. Un residuo di un progetto precedente è comune in quest’area, dato che la rotta che fallisce di solito ha sostituito qualcosa che funzionava. Annotate quali voci appartengono a quale connessione prima di rimuovere qualsiasi cosa, e tenete l’elenco nel registro delle modifiche.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Fate corrispondere prefisso, salto successivo, archivio e proprietario insieme invece di cancellare tutto ciò che sembra simile. Un’altra connessione può legittimamente dipendere da una parte di quello spazio, e una cancellazione ampia trasforma una riparazione ordinata in un incidente di supporto.

Riconnettetevi in un ordine diverso

Riproducete la condizione invece di sperare che il primo tentativo fosse rappresentativo. Disconnettete, riconnettetevi e confermate il percorso selezionato verso la stessa risorsa remota mentre il tunnel è attivo; con più VPN in gioco, alzateli in un ordine diverso e osservate se il percorso scelto cambia. L’ordine è la variabile che quasi tutti saltano, ed è quella che espone una rotta legata alla connessione sbagliata.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

Il risultato che volete non è che un adattatore conservi il suo numero una volta. È che la rotta compaia con qualunque numero riceva la connessione, ogni volta, e scompaia quando la connessione si chiude. Riconnettersi due volte è il modo meno costoso di distinguere questi esiti.

Sappiate cosa la rotta non può fare

Una rotta di profilo fornisce un percorso e nient’altro. Non apre un firewall remoto, non crea una rotta di ritorno all’estremità remota e non risolve due sedi che usano lo stesso intervallo di indirizzi; ognuna di queste è una configurazione separata con un proprietario separato. Confermare il percorso è quindi l’inizio del test di accettazione e non tutto il test.

Tenete l’elenco dei prefissi con il profilo e annotate sotto quale ambito è stato aggiunto, così la persona successiva può leggere il progetto previsto invece di dedurlo da una tabella di routing. Le rotte che esistono solo nella memoria di qualcuno sono quelle che vengono ricostruite male dopo la riconnessione successiva. Un commento di una riga nelle note di distribuzione costa meno di un pomeriggio di riscoperta.