IPv6 ULA in una VPN: indirizzamento privato, non privacy

Gli indirizzi che sembrano privati non lo sono nel senso che la maggior parte delle persone intende, e l’indirizzamento unico locale di IPv6 ne è il caso più chiaro. Un prefisso ULA dà a una VPN un piano interno stabile per le risorse che stanno dietro. Non cifra nulla, non autentica un peer e non decide a quali servizi un client può arrivare. Trattare il prefisso come un controllo di sicurezza è l’errore che questo articolo vuole eliminare.

Che cosa fornisce davvero il prefisso

La RFC 4193 riserva fc00::/7 per uso locale, con il bit L che distingue lo spazio assegnato localmente dalla forma riservata. In pratica significa che ciò che generate è fd00::/8. La specifica definisce anche come debba essere derivato l’ID globale a 40 bit, così che siti indipendenti non scelgano lo stesso prefisso per caso. Quello spazio è progettato per restare fuori da internet pubblico, il che è una proprietà dell’instradamento e non una protezione.

All’interno di un sito, la disposizione abituale è un ID globale /48 suddiviso in sottoreti: una per i client del tunnel, una per il lato server e una per ogni LAN remota. Quella struttura è tutto il beneficio, ed è un beneficio di indirizzamento. Ogni pacchetto ha ancora bisogno di una rotta e ha ancora bisogno di una politica che lo consenta.

Confondere il prefisso con un tunnel è il modo in cui un progetto finisce per documentare indirizzi fd00 e dare per scontato che il traffico tra loro sia protetto. Non lo è, a meno che qualcos’altro non fornisca la protezione.

Perché copiare il prefisso dell’esempio fa male

Ogni tutorial usa un prefisso facile da ricordare, e ogni lettore che lo copia eredita lo stesso rischio di collisione. Due siti che in seguito si collegano con un tunnel da sito a sito con intervalli identici producono esattamente l’ambiguità nota dagli spazi privati IPv4 sovrapposti. Nessuno dei due lati è sbagliato di per sé, e la rete combinata non ha modo di sapere quale destinazione si intende.

Generare l’ID globale secondo il processo documentato richiede un minuto ed elimina la domanda. Annota il prefisso, l’input di generazione e la data accanto al piano degli indirizzi.

Il rischio non è teorico per chi unisce reti dopo un’acquisizione o collega due laboratori tramite una VPN. Non è nemmeno urgente per un singolo sito, ed è per questo che viene rinviato finché la fusione non è già pianificata.

Portata e accesso sono questioni separate

ULA non è pensato per l’ordinario indirizzamento internet instradato globalmente. Questo non rende affidabile ogni host che lo usa e non rende quegli host irraggiungibili da altre reti private connesse. I firewall e le autorizzazioni delle applicazioni decidono ancora ciò che un peer può usare, e il tunnel fornisce ancora l’autenticazione con cui è stato configurato.

Un’uscita internet ha bisogno di un proprio progetto di uscita IPv6. Assegnare un indirizzo ULA a un client non crea accesso a destinazioni globali arbitrarie, e da un client che ne riceve uno non ci si deve aspettare che navighi internet pubblico attraverso di esso.

Due siti con prefissi diversi hanno ancora bisogno di rotte di ritorno per gli intervalli dell’altro, ed entrambi i firewall hanno bisogno di regole corrispondenti. Nulla di tutto ciò deriva dalla famiglia di indirizzi. Ciò che deriva è un lavoro di documentazione: una tabella dei prefissi e dei sistemi autorizzati a rispondere su ciascuno.

Verifica il piano su entrambe le estremità

Conferma che il prefisso compaia dove pensi che compaia, poi conferma che una destinazione sia davvero raggiungibile attraverso di esso.

ip -6 address show
ip -6 route show
ping -6 -c 3 fd12:3456:789a:1::1

L’elenco degli indirizzi mostra quale interfaccia ha quale sottorete, e un client che ha ricevuto quella sbagliata di solito lo mostra qui. L’elenco delle rotte mostra se il prefisso remoto ha un percorso attraverso il tunnel invece di essere scartato. Il test risponde all’unica domanda che conta: se un pacchetto fa il viaggio di andata e ritorno.

Ripeti il controllo dopo una riconnessione, perché un client che conserva l’indirizzo ma perde la rotta produce una connessione che sembra attiva e non inoltra nulla. L’indirizzo è la parte facile, e la rotta è ciò che scompare. Salva entrambi gli output accanto al nome del profilo di connessione, così che il confronto successivo parta dalle prove.