IPv6 su VPN: un prefisso delegato non è un pool di indirizzi
Un client ha bisogno di un indirizzo, il router dietro di lui ha bisogno di una rete. Ponete prima la domanda sul ruolo, poi il passo di indirizzamento, poi la verifica della rotta di ritorno.
Lo stesso giorno arrivano due richieste: un portatile ha bisogno di IPv6 sul tunnel e un piccolo sito vuole IPv6 per i dispositivi dietro il suo router. A entrambe si risponde con un indirizzo, e la seconda passa poi una settimana a fallire. I ruoli sono diversi, e così i meccanismi, la configurazione e la verifica che dimostra che funziona. Questa guida li tiene separati.
Primo passo: decidete quale ruolo state servendo
Un singolo host ha bisogno di un indirizzo sulla sua interfaccia di tunnel, con una rotta verso il lato remoto e nulla a valle da numerare. Un router dietro il tunnel ha bisogno di un’intera rete che possa distribuire, più una rotta sul lato remoto che riporti quegli indirizzi verso di lui. Ciò che sta dietro il tunnel guida ogni decisione successiva.
Rispondete a questa domanda prima di aprire qualsiasi configurazione. Tutto ciò che segue questo passo dipende da quale risposta avete dato.
Secondo passo: assegnazione degli indirizzi per un singolo host
Assegnate l’indirizzo del tunnel, confermate la lunghezza di prefisso attesa dal prodotto e verificate che il client installi una rotta per l’intervallo remoto invece di inviarlo al gateway predefinito locale. Un /128 su un’interfaccia di tunnel è normale per un collegamento punto a punto, mentre un /64 lì rivendica una rete che nessuno ha delegato. Due uscite risolvono la questione: la tabella degli indirizzi e la tabella delle rotte, lette su entrambe le estremità. Leggetele insieme, perché una rotta che punta all’interfaccia sbagliata è l’errore più comune in questo passo.
Verificate con le tabelle degli indirizzi e delle rotte su entrambe le estremità, poi inviate una richiesta. Se la richiesta esce correttamente e non torna nulla, il guasto è nella rotta del lato remoto e non nell’indirizzo del client.
Terzo passo: delega per un router dietro il tunnel
La delega del prefisso è un meccanismo separato dall’assegnazione degli indirizzi, con la propria richiesta e il proprio contratto di locazione. Il lato che delega deve essere configurato per fornire un prefisso abbastanza grande per la rete a valle, e il router richiedente deve numerare la propria interfaccia interna da quel prefisso.
Non date per scontato che il pool che serve i client mobili possa delegare. Molti prodotti VPN assegnano indirizzi singoli e non hanno affatto un ruolo di delega, e un prefisso del provider che arriva al vostro bordo non viene passato automaticamente a un pari. Annotate quale ruolo serve ogni pool, perché i due si configurano in luoghi diversi.
Quarto passo: rendete esplicita la rotta di ritorno
Entrambe le estremità devono concordare quale pari trasporta quale prefisso. Sul lato remoto aggiungete la rotta per la rete delegata che punta al tunnel e confermate che nessun intervallo sovrapposto la rivendichi già.
Un prefisso valido senza rotta di ritorno produce un piano di indirizzamento ordinato e nessuna connettività. Una rotta senza regola di accesso espone più del sito di quanto previsto, quindi abbinate i due cambiamenti nella stessa finestra e tenete uno stato applicato a metà lontano dagli utenti.
Quinto passo: verificate da dietro il router
Eseguite i controlli in ordine: l’indirizzo dell’interfaccia di tunnel sul client, il prefisso delegato sull’interfaccia interna, la rotta del lato remoto verso quel prefisso e infine una richiesta da un dispositivo dietro il router. Usate una destinazione che controllate, così un blocco silenzioso è distinguibile da una rotta mancante. Qualunque passo vi sorprenda è quello da correggere prima di proseguire.
Fate l’ultimo controllo due volte, una dal router stesso e una da un dispositivo dietro di esso. Un router che raggiunge la destinazione mentre i suoi client non ci riescono è un problema di delega o di inoltro, non un problema a monte.
Ripristino
Conservate la configurazione di indirizzamento precedente prima della modifica e annotate quale dei due meccanismi avete modificato. Rimuovere un prefisso delegato senza rimuovere la rotta lascia un buco nero, e rimuovere la rotta senza il prefisso lascia indirizzi che nulla può raggiungere. Annotate i due cambiamenti separatamente, perché annullarne uno lasciando l’altro rende un sito irraggiungibile in una sola direzione.
Se un prodotto si rivela non supportare il ruolo che vi serve, fermatevi e cambiate il progetto invece di allungare un campo del client per contenere un intervallo per cui non è mai stato pensato. Un caso di assistenza gestito con il meccanismo sbagliato costa più di quanto sarebbe costato il cambio di progetto.