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;

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

La rete non è molto capillare, quindi questo non è un vero e proprio piano di indirizzamento, ma più una guida ragionata all'assegnazione degli 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.

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 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 tun-ipv6
push "route-ipv6 ::/0"
push "route-ipv6 2001:470:c844:20::/64"
push "route-ipv6 2001:470:c844:30::/64"
# ...

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 tun-ipv6 è un tunnel IPv6;
• 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:20::/64" per ogni rete utente rrrr è necessario comunicare a tutti i client che è raggiungibile per mezzo del server OpenVPN; questo non esclude la possibilità che due reti utente vicine tra loro possano interconnettersi fisicamente e direttamente;

TODO: non si potrebbe comunicare un aggregato e risparmiare entrate nelle tabelle di routing dei client? Cosa comporta questo per il server OpenVPN?

Aggiungere un Gateway Utente / Client OpenVPN

Seguire la guida VPN del GOLEM per generare le chiavi.

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

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

Rispettivamente per:

• assegnare indirizzo 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 sarebbe stato "sufficiente" fare un tunnel tap a livello 2 anziché un tunnel tun a livello 3;

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

Aggiungere serverozzo

Serverozzo è un client OpenVPN / Gateway Utente come un altro. Verrà presa ad esempio la sua configurazione.

Secondo quanto stabilito nei precedenti paragrafi, il gateway di officina (serverozzo) avrà indirizzo 2001:470:c844::20 e inoltrerà i pacchetti da/per la rete 2001:470:c844:20::/64.

Pertanto, la sua configurazione prevede:

Firewall

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.

TODO

Torrent

La banda è limitata, e non è consentito traffico di materiale illegale.