Delega dei prefissi IPv6 su una VPN site-to-site: lista di controllo

Portare su il tunnel è la metà facile. Ho visto un collegamento site-to-site restare stabilito per giorni mentre ogni host sulla LAN remota riceveva solo silenzio, perché il prefisso delegato dietro quel gateway era configurato su un'interfaccia ma mai instradato nel tunnel. Gli indirizzi del tunnel rispondevano ai ping per tutto il tempo, ed è proprio per questo che nessuno guardava il prefisso. Ecco l'ordine che controllo quando un prefisso IPv6 delegato deve attraversare una VPN site-to-site: la mappa dei prefissi, i selettori di traffico, l'inoltro e il firewall, poi il percorso di ritorno.

Scrivi la mappa dei prefissi prima di toccare il tunnel

La delega dei prefissi assegna un blocco al router che l'ha richiesto. Non installa una rotta sul peer, non estende quel blocco on-link e non dice al gateway remoto cosa si trova dietro il router richiedente. Queste tre cose tocca a te configurarle, e appartengono a un piano di indirizzamento prima che qualsiasi file di configurazione cambi.

Per ogni sito, annota il prefisso delegato, il /64 effettivamente in uso sulla LAN, gli indirizzi del tunnel e il proprietario di ogni rotta. Il provider delega 2001:db8:a1::/56 al sito A, che serve 2001:db8:a1:10::/64 sulla sua LAN; il sito B mantiene 2001:db8:b2::/64. Se il sito A serve solo quel /64, entrambe le estremità dovrebbero indicare 2001:db8:a1:10::/64 invece dell'intero /56.

Due errori si presentano quasi ogni volta. Uno è trattare il prefisso remoto come on-link, collegandolo in bridge o mettendolo sull'interfaccia del tunnel, così il gateway risponde alla sollecitazione dei vicini per host che non riesce a raggiungere. L'altro è annunciare l'intero /56 quando è configurato un solo /64: la tabella delle rotte dichiara il blocco raggiungibile e la maggior parte degli indirizzi finisce nel vuoto.

Allinea i selettori di traffico di entrambe le estremità alle rotte

IKEv2 e WireGuard rifiutano entrambi il traffico non corrispondente, con abbastanza discrezione che il tunnel sembra ancora sano.

In strongSwan i selettori sono espliciti. Sul sito A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

La conn del sito B rispecchia le due sottoreti. Quando non concordano, il responder rifiuta il CHILD_SA con TS_UNACCEPTABLE, così il child SA non sale mai anche se l'IKE_SA è salito. Su entrambi i lati la sottorete configurata deve corrispondere a ciò che il kernel locale instrada verso il tunnel.

WireGuard trasporta le stesse informazioni in AllowedIPs, con una variante: AllowedIPs è un filtro di origine in ricezione oltre che una rotta in invio. Se la voce peer del sito B per il sito A omette 2001:db8:a1:10::/64, i pacchetti dal sito A arrivano su un handshake valido e vengono scartati come non consentiti. Ne nasce il solito schema di un handshake che continua a rinnovarsi mentre nessuna risposta parte mai. Confronta entrambe le estremità con wg show wg0 allowed-ips. Ricontrolla quell'elenco ogni volta che la delega cambia; un /64 obsoleto tiene su la sessione e rende irraggiungibile il nuovo prefisso.

Escludi prima inoltro, firewall e MTU

Prima di leggere un'altra riga di log, verifica che i gateway inoltrino davvero. sysctl net.ipv6.conf.all.forwarding deve restituire 1 su entrambi, applicato anche alle interfacce del tunnel e della LAN. C'è una trappola: una volta attivo l'inoltro, un'interfaccia con accept_ra=1 smette di accettare gli annunci del router del provider, così la macchina può perdere la rotta predefinita upstream pur instradando perfettamente dentro il tunnel. Imposta accept_ra=2 dove serve ancora l'annuncio del provider.

Le regole del firewall devono poi consentire il prefisso in entrambe le direzioni, e ICMPv6 deve sopravvivere: scoperta dei vicini, packet-too-big e destination-unreachable non sono opzionali. Se li scarti, la scoperta dell'MTU di percorso si rompe, e ottieni connessioni che si aprono e poi si bloccano alla prima risposta grande. Una coppia minima di regole è questa:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

L'MTU sta dietro a questo. Un tunnel riduce l'MTU utilizzabile sotto 1500, e IPv6 richiede che ogni collegamento trasporti almeno 1280. I ping piccoli passano, una sessione SSH si blocca su una raffica grande, e /proc/net/snmp6 mostra messaggi packet-too-big che non tornano mai indietro. Imposta esplicitamente l'MTU del tunnel, oppure limita l'MSS TCP nella tabella mangle, e lascia tornare l'ICMPv6 che segnala l'MTU più piccolo.

Prova il percorso di ritorno, non l'indirizzo del tunnel

Il guasto che costa più tempo è l'instradamento unidirezionale. Ogni gateway instrada il prefisso remoto nel tunnel, ma gli host rispondono attraverso il proprio gateway predefinito perché è lì che vive il loro /64. Portare un pacchetto a destinazione è metà percorso.

Due comandi risolvono gran parte della questione. Sul sito A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 mostra quale interfaccia userebbe una risposta da quella sorgente; esegui il controllo speculare sul sito B. Poi genera traffico da un host invece che dal gateway e confronta i contatori su entrambe le estremità.

Se la sollecitazione dei vicini per il prefisso remoto compare sul tunnel, quel prefisso è on-link da qualche parte dove non dovrebbe; risolvilo prima di modificare le rotte. Il proxy NDP copre i casi in cui il bridging è davvero necessario, non sostituisce una rotta.

Pianifica che il prefisso cambi sotto di te

La delega dei prefissi è un contratto di locazione tra il router delegante e quello richiedente, e un rinnovo può restituire un blocco diverso: un /56 diverso dopo una migrazione del provider, o un contratto più breve di quanto il tunnel sia stato attivo. Ogni punto che nomina il vecchio prefisso diventa obsoleto insieme: rotte, selettori, AllowedIPs, regole del firewall, record DNS e qualsiasi monitoraggio che codifica indirizzi letterali. Il flusso dei messaggi è nella RFC 8415.

Dove si prevede che il prefisso si sposti, mantieni un piano di indirizzamento interno che non dipenda da esso e traduci al confine. NPTv6 è l'opzione stateless e mantiene leggibile la policy interna, ma è traduzione di prefisso, non uno strato magico: i confini /64 devono allinearsi, i checksum vengono adattati, e le applicazioni che incorporano indirizzi letterali si rompono comunque. Se mantieni gli indirizzi del provider da un capo all'altro, annota il comportamento del contratto e una procedura di modifica nel piano di indirizzamento.

Chiudi con un test che resiste al tempo: un host autorizzato su ciascuna LAN raggiunge un servizio sull'altra LAN, la risposta torna attraverso il tunnel, e la stessa coppia funziona ancora dopo un riavvio del tunnel e un rinnovo della delega. Se l'ultima parte fallisce, il progetto dipende da uno stato che non sopravviverà alla settimana.