Come testare IPv6 attraverso una VPN con una risorsa tua

Una pagina pubblica di verifica IP risponde a una domanda, e di solito non a quella che hai posto. Ti dice l'indirizzo di uscita che la pagina ha osservato; non ti dice se la rotta IPv6 attraverso il tunnel funziona, se l'host ha preferito IPv6 o è tornato indietro, né se un'applicazione esclusa ha preso un altro percorso. Una risorsa autorizzata che controlli risponde correttamente alla domanda più stretta, perché vedi entrambe le estremità. La procedura qui sotto riguarda l'ottenere una conclusione che puoi difendere, non l'ottenere un risultato verde.

Passo 1: dichiara quale rotta IPv6 stai testando

Dillo in una frase. Una richiesta all'indirizzo IPv6 del server del tunnel testa il tunnel; una richiesta a un host oltre l'uscita testa l'uscita IPv6 dell'uscita; una richiesta a un indirizzo IPv6 privato testa una rotta interna.

Sono tre affermazioni diverse e una sola richiesta riuscita non può sostenerle tutte. Scegli quella che conta per la decisione che hai davanti e scrivila prima di eseguire qualcosa. Se la preoccupazione è se IPv6 perde intorno al tunnel, la domanda riguarda la selezione della rotta dell'host, non la raggiungibilità dell'uscita. Se la preoccupazione è se il lato remoto può raggiungere un servizio interno, l'uscita è irrilevante.

Passo 2: conferma che l'host seleziona quella rotta

ip -6 route get 2001:db8:1::10 stampa la rotta, l'indirizzo di origine e l'interfaccia che il kernel userebbe, ed è il fatto da cui dipende il resto del test.

Che un'interfaccia esista non è lo stesso che sia selezionata. Gli host a doppio stack hanno una tabella di precedenza, e /etc/gai.conf su Linux può cambiare quale famiglia vince per un nome che risolve a entrambe.

Passo 3: usa una destinazione e un nome legittimi

Se stai testando HTTPS, usa il nome host per cui è stato emesso il certificato e lascia attiva la verifica; passare a un indirizzo letterale per far passare il test disattiva proprio il controllo che dimostra che hai raggiunto l'host previsto. Un servizio diagnostico che controlli, che risponde su un nome noto con un certificato valido, è il bersaglio più pulito. Ti dà anche una riga di log lato server con cui correlare, cosa che un verificatore di terze parti non farà mai.

Esegui la richiesta in una forma che mostri l'indirizzo usato: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. L'opzione -6 forza la famiglia, ed è così che separi IPv6 non funziona da IPv6 non è stato preferito.

Per un controllo puro di raggiungibilità dove ICMPv6 è consentito, ping -6 -c 3 2001:db8:1::10 è sufficiente. Dimostra il percorso e nulla al di sopra.

Passo 4: correla le due estremità

Quando hai accesso a entrambe le estremità, esegui tcpdump -ni any ip6 and host 2001:db8:1::10 sul client e l'equivalente sulla risorsa, con marche temporali, e conferma che lo stesso flusso appare su entrambe. È questo che trasforma un risultato plausibile in prova: la vista del client da sola non può distinguere una risposta della risorsa da una risposta di qualcosa in mezzo. Mantieni la cattura stretta a un'unica destinazione così che l'output resti leggibile e la sessione non correlata di nessuno non finisca nel file.

Ripeti il test dopo una riconnessione se la preoccupazione è se la politica sopravvive a un riavvio. Lo stato di rotta e firewall applicato una volta alla connessione può differire dallo stato riapplicato, e la differenza si vede solo alla seconda connessione.

Testa il caso di guasto separatamente se ti serve. Un tunnel che blocca IPv6 quando cade e uno che lo lascia perdere sono progetti diversi, e solo uno dei due può essere verificato con una richiesta riuscita.

Passo 5: annota che cosa il test non ha dimostrato

Il quinto passo è annotare che cosa il test non ha dimostrato, ed è la parte che viene saltata. Un test riuscito verso un endpoint privato non dimostra l'uscita IPv6 pubblica, non dimostra il comportamento DNS e non copre le applicazioni che hai escluso dal tunnel. Ognuna di queste richiede la propria destinazione e la propria osservazione. Una nota che dice che IPv6 funziona dopo una richiesta verso un host non è un riscontro; è una congettura con una marca temporale.

Il registro che vale la pena conservare è breve: la destinazione, il nome, l'indirizzo di origine scelto dall'host, l'indirizzo remoto osservato e l'ora. Il RFC 7359 discute come verificare che una rotta IPv6 rilevante sia realmente utilizzabile, ed è lo standard a cui questa procedura si avvicina con strumenti più semplici. Se la conclusione ha bisogno di un verificatore pubblico per essere vera, il test non era abbastanza specifico.