Quale origine IPv6 sceglie una richiesta VPN e perché è importante

Avete aggiunto un indirizzo VPN e vi aspettavate che la richiesta lo usasse, ma il server registrava ancora il prefisso vecchio. Nulla del tunnel è fallito; l’host ha fatto una scelta di indirizzo di origine prima ancora di consultare la rotta che stavate fissando. La selezione dell’origine IPv6 è una competizione ordinata e separata tra gli indirizzi candidati dell’host, e il prefisso corrispondente più lungo è solo una regola vicino alla fine di quella competizione. Ottenere il risultato che volete significa sapere quale regola ha già vinto. Le regole stesse sono noiose e precise, ed è proprio per questo che vanno lette in ordine.

Due ricerche, non una

La selezione della destinazione sceglie il salto successivo e l’interfaccia in uscita. Poi la selezione dell’origine sceglie quale degli indirizzi dell’host compare nell’intestazione, e alle due domande rispondono meccanismi diversi anche se entrambi usano prefissi. Un host con un indirizzo fisico, un indirizzo temporaneo e un indirizzo VPN ha tre candidate per qualsiasi destinazione, e la rotta verso la VPN non nomina automaticamente la terza.

Per questo una rotta corretta e un’origine errata convivono così facilmente, e per questo la stessa richiesta può comportarsi diversamente da un browser e da un binding forzato. Trattate le due ricerche come separate finché non avete prove che le colleghino.

Leggete le regole come una competizione ordinata

La RFC 6724 elenca le regole in ordine, e ciascuna scioglie solo la parità lasciata dalle precedenti. La preferenza dell’interfaccia in uscita e la corrispondenza delle etichette compaiono molto prima del confronto dei prefissi, quindi un indirizzo sull’interfaccia che usa la rotta ha già guadagnato un vantaggio che una corrispondenza di prefisso migliore non può cancellare. Anche la deprecazione e l’ambito partecipano, ed è per questo che un indirizzo vecchio talvolta smette di essere scelto senza che nessuno cambi la politica.

La lettura pratica è che non potete ragionare sul vincitore solo dalla destinazione. Elencate i candidati, percorrete le regole in ordine e vedete dove la decisione è stata realmente presa.

Notate anche che questa è la metà dell’origine del problema. Confondere i due confronti di prefisso produce spiegazioni che suonano rigorose e predicono l’indirizzo sbagliato. Dite a quale confronto vi riferite ogni volta che usate la parola prefisso in un ticket.

Il binding di un’applicazione cambia la domanda

Un’applicazione può chiedere un indirizzo di origine specifico, e una scelta esplicita valida sposta la domanda da “quale indirizzo preferirebbe l’host” a “quell’indirizzo può raggiungere la destinazione e tornare”. Gli strumenti che si legano a un’origine, o che chiedono dati ausiliari sull’indirizzo scelto, lo espongono direttamente, e sono il modo più rapido per dimostrare quale indirizzo una connessione ha realmente usato. Quell’esperimento batte la terza lettura della tabella di routing, perché riporta ciò che ha deciso il kernel e non ciò che avete configurato. Ripetetelo dopo la modifica e confrontate le due risposte.

Ciò rende il binding dell’origine sia uno strumento diagnostico sia una soluzione temporanea: legate l’indirizzo VPN e osservate se la richiesta riesce. Se riesce, il percorso è a posto e il problema era la selezione. Se fallisce, il problema era fin dall’inizio il percorso di ritorno o la politica dell’estremità remota.

Verificate che l’estremità remota accetti quell’origine

Qualunque cosa scelga l’host, deve rientrare nell’ambito protetto della VPN e nella rotta di ritorno e nelle regole di accesso dell’estremità remota. Un’origine fuori dai selettori può viaggiare nel tunnel ed essere scartata all’estremità remota, il che sembra un guasto unidirezionale e viene attribuito all’instradamento. Confrontate l’origine interna scelta con l’ambito di protezione prima di toccare le impostazioni di cifratura, perché cambiare modalità non sceglie tra indirizzi candidati.

Tenete separato anche l’indirizzo del punto terminale esterno nel vostro ragionamento. Identifica il trasporto tra i partecipanti VPN e non è l’origine del pacchetto dell’applicazione all’interno.

Decidete con quattro osservazioni

Annotate la destinazione usata, le origini locali idonee, l’origine realmente scelta e il percorso in uscita effettivo. Quattro righe bastano a spiegare quasi ogni caso, e si possono confrontare tra un host funzionante e uno guasto senza riaprire il dibattito teorico. Per il passo di selezione usate la vista supportata del sistema operativo stesso invece di un nome dello standard, perché le implementazioni aggiungono preferenze locali proprie.

Quando la risposta vi sorprende ancora, l’ordinamento sta facendo qualcosa che il vostro modello mentale non fa, e il rimedio è cambiare gli ingressi invece di discutere con l’algoritmo. Scrivete le quattro osservazioni nel ticket e il prossimo lettore potrà riprodurre la vostra conclusione.