Ogni comparativo di VPS su questo sito lo riporta: «un solo /128 IPv6 di default», «/64 IPv6», «niente IPv6 sul piano base». Si legge come un dettaglio di scheda tecnica. Per un server WireGuard self-hosted non lo è: decide se i tuoi peer possano avere IPv6 del tutto.
A WireGuard non importa quale stack usi
Partiamo dal facile. La documentazione di WireGuard è esplicita: «Any combination of IPv4 and IPv6 can be used, for any of the fields.» - qualsiasi combinazione di IPv4 e IPv6 può essere usata, per qualsiasi campo.
L'endpoint può essere IPv4 mentre il tunnel trasporta IPv6, o viceversa. Non c'è una modalità IPv6 separata da attivare né un secondo demone da avviare. Un tunnel dual-stack è semplicemente due indirizzi sulla stessa interfaccia.
Che cosa significano /64 e /128 in concreto
È qui che la scheda dell'hoster inizia a contare.
Un /128 è un solo indirizzo. È l'IPv6 del tuo server e nulla più. Puoi dare connettività IPv6 al server, ma non ti resta alcun indirizzo da distribuire: i tuoi peer non possono averne uno ciascuno.
Un /64 è un blocco. È la dimensione di assegnazione standard per un segmento di rete, e ti lascia libero di assegnare un indirizzo a ogni peer dall'interno.
Un hoster che pubblicizza «IPv6 incluso» con un solo /128 dice il vero e comunque non fornisce ciò che serve a un server VPN. È la riga da rileggere due volte in una tabella comparativa, compresa la nostra.
AllowedIPs fa due mestieri diversi
È la parte che si fraintende, ed è documentata senza ambiguità. Lo stesso campo si comporta diversamente a seconda del verso:
«nell'invio dei pacchetti, la lista di IP consentiti si comporta come una sorta di tabella di routing»
«nella ricezione dei pacchetti, la lista di IP consentiti si comporta come una sorta di lista di controllo degli accessi»
WireGuard chiama l'insieme una Cryptokey Routing Table - «la semplice associazione di chiavi pubbliche e IP consentiti».
La conseguenza per IPv6 è diretta: se vuoi che il traffico IPv6 di un peer passi dal tunnel, ::/0 deve comparire nel suo AllowedIPs. Mettere solo 0.0.0.0/0 instrada unicamente l'IPv4, e il traffico IPv6 del peer esce dalla sua connessione normale, fuori dal tunnel e con il suo indirizzo reale.
È una fuga, e non è un difetto di WireGuard. È la lista di controllo degli accessi che fa esattamente ciò che le è stato detto.
La configurazione in pratica
Sul server, assegna all'interfaccia un indirizzo IPv4 e uno IPv6 dalla tua allocazione. Su ogni peer, elenca entrambi gli stack in AllowedIPs. Per far passare tutto dal tunnel è 0.0.0.0/0, ::/0; per una ripartizione, elenca i prefissi specifici di ciascuno stack.
Due cose da tenere a mente. Il forwarding va abilitato per entrambe le famiglie, non solo IPv4: sono impostazioni sysctl distinte, e attivarne una non fa nulla per l'altra. E anche le regole del firewall esistono in doppio: iptables e ip6tables sono tabelle diverse, quindi un masquerade o un kill switch scritto solo per IPv4 lascia IPv6 senza protezione.
Verificare invece di supporre
Una volta configurato, controlla dal client che il tuo IPv6 pubblico sia quello del server e non il tuo. Un tunnel che trasporta correttamente l'IPv4 mentre lascia trapelare l'IPv6 appare perfettamente sano dall'interno: l'handshake riesce, il traffico scorre e nei log non si lamenta nulla.
Se il tuo hoster ti dà solo un /128, le opzioni oneste sono restare in IPv4 nel tunnel e bloccare l'IPv6 sui peer perché non possa trapelare, oppure cambiare hoster. Un dual stack configurato a metà è peggio di nessun IPv6.
★ Datacenter GDPR di Norimberga · ✓ IPv4 dedicato incluso · 200+ Mbps garantiti
Ospita la tua VPN sul tuo VPS → ContaboAccesso root completo · IPv4 pubblico · scegli la tua regione→
