Prefisso di sede IPv6: iroute-ipv6 o route-ipv6 sul server?

Due direttive con un nome quasi identico compaiono in ogni esempio funzionante, e copiarne una senza l’altra produce un tunnel che sembra corretto e scarta in silenzio il prefisso di sede. Fanno lavori diversi ai due lati dello stesso confine: una insegna al kernel del server dove vive un prefisso, e l’altra insegna a OpenVPN quale client autenticato lo trasporta. Se entrambe sono giuste, il prefisso scorre; se una sola è giusta, i pacchetti hanno una rotta ma nessun proprietario.

Due direttive, due lavori diversi

route-ipv6 è una normale installazione di rotta: il server aggiunge una rotta del kernel che punta il prefisso alla propria interfaccia di tunnel. iroute-ipv6 appartiene a un contesto specifico del client e dichiara la proprietà interna, così il daemon sa che il traffico per quel prefisso va inviato a un client preciso invece che al peer che una rotta del kernel nomina per caso.

Una riguarda la tabella di inoltro del kernel, l’altra il modello di routing interno del daemon. Tenerle separate spiega perché una configurazione che sembra completa possa comunque scartare il prefisso. Spiega anche perché la stessa rete compare due volte in ogni esempio funzionante. Nessuna delle due righe è superflua.

Nell’installazione tradizionale in spazio utente servono entrambe e si completano a vicenda. Una rotta del kernel da sola lascia il daemon incapace di scegliere un peer. Una iroute da sola lascia il kernel senza un percorso verso il tunnel. Da qui viene anche gran parte della confusione sui file per client: il file non è una voce della tabella di routing, e la voce di rotta non è una dichiarazione di proprietà.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Dove va ciascuna

La rotta va nella configurazione gestita del server, dove vale per quel processo server. La iroute va nel file specifico del client, intitolato all’identità autenticata del dispositivo di sede.

Un nome di file che non corrisponde all’identità effettiva non viene mai letto, e il sintomo è identico a una iroute mancante. Controlla l’identità che il server ha autenticato, poi controlla il nome del file carattere per carattere.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Tieni distinti il pool e il prefisso di sede, perché sovrapporli crea un enigma che nessuna direttiva può risolvere.

Di cosa ha bisogno un altro client

Un secondo client che deve raggiungere quella sede ha bisogno di un annuncio, non di proprietà. Spingi il prefisso verso i client che vuoi, nel contesto client o gruppo adatto alla tua configurazione.

Non inviarlo alla sede stessa, perché quel dispositivo ha già il prefisso come rete connessa.

Inviarlo a tutti è una scelta con conseguenze: ogni client crede allora che la sede sia raggiungibile attraverso il tunnel, compresi client a cui non hai mai voluto concedere quell’accesso. Annunciare è in pratica una decisione di accesso, anche se la direttiva sembra idraulica. La riferimento delle opzioni del server documenta iroute-ipv6 come proprietà specifica del client, e questa è la distinzione che vale la pena mantenere.

Il percorso di ritorno sul dispositivo di sede

La proprietà aiuta solo se la sede inoltra i pacchetti e la sua LAN sa come rispondere. Abilita l’inoltro IPv6 sul dispositivo di sede e verifica che gli host della sua LAN mandino il traffico del pool VPN verso la sede invece che verso una rotta predefinita che non conosce il pool.

Quel percorso di ritorno è l’equivalente IPv6 del problema della rotta mancante che si incontra con IPv4.

Verificalo da un host della LAN con una risoluzione dell’indirizzo del pool VPN, non dalla sede stessa. Una risoluzione fatta sul router risponde a una domanda diversa da quella dei tuoi utenti, e le due sono in disaccordo abbastanza spesso da valere il comando in più.

Quando la coppia non basta ancora

Alcuni deployment non usano affatto questo percorso. Il percorso dati del kernel e i server gestiti dal prodotto hanno una propria gestione delle rotte supportata, e un esempio in spazio utente potrebbe non trasferirsi direttamente.

Verifica quale percorso dati usa la tua build prima di copiare direttive da un tutorial scritto per l’altro.

Infine, ricorda l’ambito degli indirizzi: un prefisso locale unico come fd00:7a::/64 è privato per progettazione e non dice nulla sulla raggiungibilità IPv6 pubblica. Trattalo come accesso interno e tieni l’uscita internet una questione separata con una sua politica.