Aggiungere IPv6 privato a un laboratorio OpenVPN, un punto di controllo alla volta

Avete già un client che si connette su IPv4 e raggiunge un carico di lavoro IPv4 privato dietro il server. L'obiettivo è raggiungere un carico di lavoro IPv6 privato attraverso lo stesso tunnel senza toccare il trasporto esterno. Quest'ordine conta: il percorso esterno resta IPv4 e cambiano solo il piano di indirizzamento interno, la rotta del client e il percorso di ritorno dal server alla LAN. Cinque punti di controllo, ciascuno con qualcosa di concreto da guardare prima di procedere.

Punto di controllo uno: la connessione che già funziona

Connettere il client e confermare il percorso IPv4 prima di aggiungere qualsiasi cosa. Un tunnel funzionante vi dà una linea di base che separa un nuovo errore IPv6 da un vecchio problema di connettività. Vi dice anche quale istanza del server state effettivamente modificando.

Annotate il pool, la topologia e le rotte inviate su cui già fate affidamento. Il lavoro IPv6 estende quella configurazione; non la sostituisce.

Punto di controllo due: scegliete i prefissi interni

Scegliete una ULA /48 per il sito e ritagliate due /64: una per i client del tunnel, una per il segmento LAN che ospita il carico IPv6. Generate l'ID globale a 40 bit invece di copiare un prefisso di esempio, e verificate entrambe le sottoreti contro ogni rete che il sito già instrada:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Due /64 indipendenti impediscono che il pool dei client venga ritagliato dal segmento LAN, cosa che conta più avanti quando scrivete la rotta di ritorno. I valori sopra sono un esempio sviluppato, non un prefisso da riusare.

Punto di controllo tre: aggiungete l'helper e il push della rotta

Leggete la configurazione attuale del server prima di aggiungere qualcosa. Una seconda copia di una direttiva esistente non si fonde con la prima, e l'errore risultante nomina la direttiva, non IPv6. Con l'helper IPv4 già presente, due righe lo estendono. Ognuna risponde a una domanda diversa:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

La prima è un helper comodo che configura l'interfaccia e il pool dei client. La seconda nomina la destinazione LAN che il client deve raggiungere. Assegnare un indirizzo IPv6 a un client non gli dice quali reti esistono dietro il server, quindi servono entrambe le righe.

L'helper non convive con un pool IPv6 statico né con nopool. Se il deployment assegna deliberatamente indirizzi in modo statico, mantenete quella politica e progettate esplicitamente l'equivalente IPv6 invece di eliminare la politica per adattarla a un esempio.

Punto di controllo quattro: inoltro e rotta di risposta

Attivate l'inoltro IPv6 sul server tramite il titolare della configurazione del sistema, non con una scrittura runtime una tantum che dimenticherete. La forma runtime è utile per un test rapido. La configurazione persistente va in un file drop-in che il titolare della rete della distribuzione legge:

sysctl -w net.ipv6.conf.all.forwarding=1

L'inoltro cambia il comportamento IPv6 dell'host oltre l'instradamento dei pacchetti. Un host che accettava gli annunci del router come client smette di farlo allo stesso modo quando inizia a inoltrare. Una macchina il cui uplink IPv6 dipende dai RA ha quindi bisogno di un piano esplicito per quell'uplink.

Poi date alla LAN una rotta di ritorno verso il pool del tunnel. Il gateway IPv6 del carico è il router della LAN, non il server VPN, quindi la rotta va su quel router e punta all'indirizzo LAN del server:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Mantenete i tipi ICMPv6 che il collegamento richiede, incluso il feedback MTU del percorso. Una regola firewall IPv4 non implica una regola IPv6, e un blocco totale di IPv6 rompe la scoperta dei vicini in modi che sembrano un guasto di instradamento.

Punto di controllo cinque: leggete il client, poi provate

Riconnettete il client e leggete gli indirizzi che ha davvero ricevuto invece di dedurli dall'indirizzo helper del server. L'elenco delle interfacce mostra entrambe le famiglie sullo stesso dispositivo:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Una rotta che sceglie il tunnel dimostra che il client sa dove inviare il pacchetto. Non dimostra che il server lo inoltri, che il router della LAN abbia la rotta di ritorno o che l'applicazione sia autorizzata a rispondere.

Provate l'applicazione stessa su ciascuna famiglia a turno, poi ripetete dopo una riconnessione e dopo un riavvio dell'host. Una rotta o un sysctl che sopravvive solo fino al riavvio è un test, non un progetto.

Pubblicate un record AAAA solo quando il percorso IPv6 risponde da un capo all'altro. Un DNS interrogato su IPv4 può comunque restituire un indirizzo IPv6, quindi un nome risolvibile non è prova che qualcosa sia in ascolto. La guida RFC 4193 per le ULA copre la generazione dell'ID globale che rende questi prefissi vostri e non una copia.