IPv6 @ GOLEM

PAGINA IN COSTRUZIONE

Un ottimo utilizzo della VPN, oltre che per collegare macchine interne tra di loro, è l'uso per collegarsi alla rete Internet IPv6, visto che ancora, in Italia, gli utenti domestici non sono serviti.

In figura è mostrata la visione logica della rete che si vuole realizzare:

• HE (Hurricane Electric) è il provider fornitore IPv6;
• OVH è il nostro provider per il VPS;
• VPS è il nostro VPS;
• serverozzo è il gateway in Officina Informatica;

Iniziare: rete /64

Come iniziare?

Ci si registra su TunnelBroker e viene assegnata d'ufficio una rete IPv6 /64.

Il broker comunica i dettagli del suo PoP (Point of Presence):

IPv4: 216.66.84.42
IPv6: 2001:470:1f12:69::1

L'IPv6 sarà utilizzato sul collegamento tunnel virtuale, collegato all'interfaccia del VPS che chiameremo he6in4. Dalla nostra parte, he6in4 avrà come indirizzo 2001:470:1f12:69::2.

Attiviamo il tunnel, aggiungendo questo al /etc/network/interfaces:

auto he6in4
iface he6in4 inet6 v4tunnel
        address 2001:470:1f12:69::2
        netmask 64
        endpoint 216.66.84.42
        gateway 2001:470:1f12:69::1
        ttl 64

Possiamo adesso verificare la connettività tra il VPS e il PoP del broker con:

$ ip -6 addr
$ ping 2001:470:1f12:69::1

e la connettività con l'Internet IPv6 con:

$ ping 2a00:1450:4002:80a::200e

che, per completezza, è l'IPv6 di ipv6.google.com

Nella maggior parte dei casi il server DNS IPv4 usato sin'ora ha anche il supporto per risolvere nomi IPv6.

Rete /48

Siccome una rete IPv6 fisica (per esempio, una rete domestica) ha dimensione /64, e noi vogliamo tante reti, per l'officina e per i soci, richiediamo manualmente una /48. Non ci piace essere spreconi, ma ci piace rispettare anche le RFC: a new era of Internet: [1] [2]

Ci è stata assegnata la rete 2001:470:c844::/48, che significa:

• tutto il traffico di Internet IPv6 diretto a un indirizzo che cade in 2001:470:c844::/48 verrà instradato verso il nostro VPS;
• abbiamo a disposizione ben 2^80 indirizzi per pianificare la nostra rete come più ci aggrada;

Lo so, dopo anni bui di NAT dopo NAT e carenza di indirizzi, questa sembra fantascienza.

Piano di indirizzamento

Chiamarlo piano di indirizzamento è fargli un complimento immeritato; chiamiamola guida ragionata all'assegnazione dei nostri indirizzi.

Sia dato l'indirizzo IPv6:

127                   79     63                         0
    2001 : 0470 : c844 : rrrr : xxxx : xxxx : xxxx : xxxx

Siccome abbiamo 80 bit a disposizione e la rete più piccola che possiamo fare secondo RFC è di 64 bit, possiamo fare ben 2^16 reti (rrrr nell'esempio). Per semplicità (perché alla fine è a questo che servono tutti questi indirizzi in IPv6), poniamo rrrr = zzzy, dove:

• zzz (12 bit) identifica l'utente;
• y (4 bit) identifica la sottorete personale dell'utente (2^4 = 16 sottoreti personali)

Queste sottoreti personali possono essere instradate direttamente dal VPS, ma se l'utente lo desidera (e, compatibilmente con altri vincoli, è fortemente invitato a desiderarlo per evitare che le tabelle di routing scoppino) può aggregare qualunque prefisso da /64 al più corto /60.

Sono così riservate:

000y Servizio (16 reti)
001y non usata
002y Officina (16 reti)
003y Socio-A (16 reti)
004y Socio-B (16 reti)
005y ...

Il numero di rete rrrr sarà usato:

• per instradare tutto il traffico diretto a 2001:470:c844:rrrr::/64 verso il gateway dell'utente;
• per assegnare l'indirizzo 2001:470:c844::rrrr/64 al gateway dell'utente nella rete di servizio;

Si noti la "piccola" differenza.

Nella prima rete di servizio (2001:470:c844::/64) ci sono:

• il VPS
• il serverozzo
• tutti i gateway dei soci

I gateway dei soci non sono diversi da serverozzo, e tuttavia la loro configurazione può essere più semplice se invece che da gateway fungono come semplici end-point.

Così organizzate, le risorse si esauriranno in questo ordine:

• la banda a disposizione del VPS (100M/100M);
• la capacità computazionale e di memoria del VPS per l'inoltro dei pacchetti;
• gli IPv6 (gli IPv6 non finiranno mai)

Non essendo una rete a maglie, ma semplicemente un albero, il routing è definito staticamente. Se la rete si evolverà e le singole "isole" dovessero iniziare a connettersi a maglia in maniera incontrollata, potranno essere impiegati algoritmi dinamici, ma considerata la vastità del bacino d'utenza...

OpenVPN

Nel tunnel di OpenVPN è presente la prima rete di servizio 2001:470:c844::/64 (con rrrr = 0000).

Disegnata così sembra una rete layer 2, ma in realtà è possibile solo traffico dal layer 3 in su. Per il layer 2 viene usato il protocollo interno di OpenVPN.

Configurazione del server OpenVPN sul VPS server:

port xxxxx
proto udp

dev tun

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
dh /etc/openvpn/keys/dh2048.pem

server 10.0.0.0 255.255.255.0
server-ipv6 2001:470:c844::1/64
ifconfig-ipv6 2001:470:c844::1 2001:470:c844::2

topology subnet

push "route-ipv6 ::/0"
push "route-ipv6 2001:470:c844::/48"

client-config-dir /etc/openvpn/staticclients

comp-lzo
keepalive 10 120
persist-key
persist-tun

user nobody
group nogroup

verb 3
status openvpn-status.log

In particolare:

• server 10.0.0.0 255.255.255.0 va messo comunque anche se non si intende utilizzare l'IPv4 nel tunnel; è una limitazione (teorica) al numero di indirizzi IPv6 utilizzabili, ma comunque (in pratica) il server scoppierebbe ben prima;
• ifconfig-ipv6 2001:470:c844::1 2001:470:c844::2 il server OpenVPN sarà accessibile attraverso il tunnel tramite l'indirizzo 2001:470:c844::2
• push "route-ipv6 ::/0" il server OpenVPN comunica ai client che è il default gateway per l'Internet IPv6; naturalmente, ogni client è libero di usare il gateway che preferisce, ma se non ha connettività IPv6 non potrà far altro che utilizzare questo;
• push "route-ipv6 2001:470:c844::/48" è necessario comunicare a tutti i client che la nostra rete è raggiungibile per mezzo del server OpenVPN; questo non esclude la possibilità che due reti utente vicine tra loro possano interconnettersi fisicamente e direttamente;

In teoria basta la sola rotta di default, ma in pratica non funziona (si suppone per come è fatto il protocollo openVPN a livello 2)

Aggiungere un Gateway Utente / Client OpenVPN

Verrà presa ad esempio la configurazione del gateway di officina serverozzo, che, secondo quanto stabilito nei precedenti paragrafi avrà indirizzo 2001:470:c844::20 e inoltrerà i pacchetti da/per la rete 2001:470:c844:20::/64.

Generare chiave SSL

Seguire la guida VPN del GOLEM per generare le chiavi, e eventualmente provare la configurazione per il tunnel IPv4 (sconsigliato, ormai meglio passare tutto a IPv6).

Configurazione del server OpenVPN

Comunicare al client il suo indirizzo IPv6 statico

Sul server OpenVPN, nel file di configurazione del client /etc/openvpn/staticclients/hostname, scrivere le seguenti righe:

ifconfig-ipv6-push 2001:470:c844::20/64
iroute-ipv6 2001:470:c844:20::/64

Rispettivamente per:

• assegnare indirizzo statico al gateway utente / client openvpn;
• permettere al client di inoltrare sul tunnel i pacchetti provenienti dalla rete alle sue spalle; questo serve al protocollo di openVPN per il layer 2, altrimenti non vengono fatti passare pacchetti con indirizzo sorgente diverso da quelli della rete di servizio; in alternativa si poteva fare un tunnel tap e utilizzare Ethernet a livello 2;

Inoltrare i pacchetti per la nuova rete

Sul server OpenVPN, impostare la rotta per la nuova rete.

Utilizzare l'apposito script di configurazione /root/route-ipv6.sh e lanciarlo con argomento add:

# ip -6 route add 2001:470:c844:20::/64 via 2001:470:c844::20

Configurazione del client

Connessione alla VPN

Usare questo file di configurazione sul client openvpn:

client
dev tun
proto udp
remote golem.linux.it xxxxx
resolv-retry infinite
nobind

user nobody
group nogroup

ns-cert-type server
ca /etc/openvpn/golem.linux.it/ca.crt
cert /etc/openvpn/golem.linux.it/serverozzo.crt
key /etc/openvpn/golem.linux.it/serverozzo.key

keepalive 30 120
persist-key
persist-tun

comp-lzo

verb 3

Se il client OpenVPN è un nodo foglia della rete, cioè non funge da gateway perché si deve collegare solo lui (es. smartphone), allora c'è già connettività IPv6 e non serve fare altro.

Se invece il client è il gateway della rete (es. serverozzo, o di casa di uno dei soci), allora bisogna configurarlo come segue.

Impostare il client OpenVPN come gateway IPv6 per l'isola

Abilitare inoltro pacchetti IPv6

Nel file /etc/sysctl.conf:

net.ipv6.conf.all.forwarding=1

Installare e configurare radvd

radvd è il demone di router advertisement. Per la configurazione automatica degli indirizzi e del gateway in IPv6 non è necessario un complesso server DHCP, ma vista la vastità dello spazio di indirizzamento (anche la rete più piccola ha ben 2^64 indirizzi disponibili) basta il più semplice radvd. Un router con radvd, a intervalli regolari, trasmette un messaggio in broadcast a tutti gli host della rete, informandoli sul prefisso di rete da utilizzare; a questo punto gli host possono autoconfigurarsi col metodo che preferiscono (es. SLAAC con o senza estensione per la privacy).

Questa configurazione di radvd non prevede la trasmissione di un server DNS.

Per il momento tutto funziona ugualmente, perché tanto:

• tutte le reti sono ancora miste IPv4 / IPv6;
• il server DNS IPv4 può essere interrogato anche per ottenere traduzioni di nomi IPv6;

Installare radvd:

# apt install radvd

Configurare il file /etc/radvd.conf:

interface br0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 2;
        MaxRtrAdvInterval 10;
        prefix 2001:470:c844:20::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
};

dove

• interface br0 indica l'interfaccia interna su cui fare advertise;
• prefix 2001:db8::/64 indica la rete a valle;

Firewall

Per il VPS

Inoltrare solo i pacchetti da/per le reti note.

Non ancora testato!

# ip6tables -P FORWARD DROP
# ip6tables -A FORWARD -d 2001:470:c844::/48 -i he6in4 -j ACCEPT
# ip6tables -A FORWARD -s 2001:470:c844::/48 -o he6in4 -j ACCEPT

Per gli host

Gli indirizzi IPv6 sono tutti pubblici, perciò è bene che tutti gli host, compresi quelli domestici che sin'ora sono stati dietro a un (s)comodo NAT, attivino degli strumenti atti a prevenire accessi indesiderati dall'esterno.

# ip6tables -P INPUT DROP
# ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Salvare queste impostazioni, per esempio con iptables-save e iptables-restore, altrimenti verranno perse al riavvio.

Si può fare anche qualcosa direttamente sul gateway, così da non dover replicare la configurazione su ogni host.

TODO: Questa sezione è da espandere!

Torrent

La banda è limitata, e non è consentito traffico di materiale illegale. Occore limitare il traffico bit-torrent almeno al gateway finale (VPS).

TODO: Questa sezione è da fare!