Differenze tra le versioni di "IPv6 @ GOLEM"

Da GolemWiki.
Jump to navigation Jump to search
m (categorizzazione)
Riga 101: Riga 101:
 
== Considerazioni e descrizione generale ==
 
== Considerazioni e descrizione generale ==
  
 +
Come portare IPv6 al GOLEM?
 
[[Immagine:Tunnel-ipv6.jpeg|500px|right]]
 
[[Immagine:Tunnel-ipv6.jpeg|500px|right]]
  

Versione delle 09:05, 18 feb 2019

Golem-template-note-attention.png PAGINA IN COSTRUZIONE


Due parole su questa pagina

Questa pagina è un maldestro tentativo:

  • per riassumere le ragioni che ci hanno portato a decidere di dotarci di IPv6;
  • per documentare la nostra infrastruttura di rete;

Questa pagina potrebbe anche diventare obsoleta in poco tempo. La data di stesura è estate 2018, ed è possibile vedere i cambiamenti tramite la Cronologia di Mediawiki.

Due parole sull'IPv6

IPv6 è un "nuovo" protocollo a livello di rete che da diversi anni sta sostituendo IPv4. Le novità introdotte da IPv6 sono molteplici; tra queste, quella che balza immediatamente all'occhio è l'enorme dimensione dello spazio di indirizzamento.

Protocollo lunghezza indirizzo numero indirizzi
IPv4 32 bit <math>2^{32}</math> = 4 miliardi
IPv6 128 bit <math>2^{128}</math> = 256 miliardi di miliardi di miliardi di miliardi

Su questo pianeta vi sono circa 8 miliardi di persone [1], di cui la metà [2] è connessa a Internet, e nei paesi sviluppati hanno anche più di un dispositivo connesso. Si aggiungano i numerosissimi apparati di rete e server necessari per il funzionamento dell'infrastruttura e la fornitura di servizi, e si può facilmente intuire che IPv4 non è più sufficiente per le attuali necessità. Infatti gli IPv4 stanno finendo [3] (qui [4] il grafico aggiornato degli indirizzi rimanenti al RIPE, il registro europeo).

IPv4 vs IPv6

Notazione

  • IPv4 → 4 byte rappresentati con numeri decimali separati da un punto, es: 192.0.2.127
  • IPv6 → 16 byte, ogni byte è rappresentato da due cifre esadecimali; ogni 4 cifre esadecimali si inseriscono i due punti :; come in IPv4 è possibile omettere gli zeri in testa; la più lunga sequenza di zeri allineata a 4 può essere omessa per intero; esempi (indirizzi equivalenti):
    • 2001:0470:c844:0020:0000:0000:0000:0001
    • 2001:470:c844:20:0:0:0:1
    • 2001:470:c844:20::1

Tipi di indirizzi

  • IPv6 Reference Card by RIPE [5]

Riassunto:

IPv6 Equivalente IPv4 Significato
::1/128 127.0.0.1 Indirizzo loopback
fc00::/7 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 Indirizzo privato
fe80::/10 169.254.0.0/16 Indirizzo link-local (univoco nella rete locale, e autoassegnato)
2001:db8::/32 192.0.2.0/24 Esempi e documentazione
2000::/3 Indirizzi unicast globalmente raggiungibili

Indirizzi pubblici vs privati

Gli IPv6 sono così tanti che non c'è bisogno di utilizzare indirizzi privati: niente NAT, niente port-forwarding. Questo restituisce connettività end-to-end ai dispositivi e apre numerose nuove possibilità di impiego, rimaste nascoste per anni a causa della scarsità di IPv4 e degli osceni espedienti inventati. Una banalità: non sarà più necessario passare attraverso un server terzo per condividere documenti, chattare o telefonare ai propri contatti.

Se necessarie, le caratteristiche di "sicurezza" introdotte dal NAT possono essere sostituite e accorpate a un banale firewall.

Progettazione di una rete

Nel progettare una rete con IPv4, la necessità principale è quella di risparmiare sugli indirizzi, perciò vengono usati prefissi di rete di varia lunghezza. Nel progettare una rete con IPv6, si hanno a disposizione così tanti indirizzi che conviene utilizzarli in maniera da renderne più agevole una distribuzione logica.

Sono così identificate le seguenti dimensioni standard per le reti IPv6 (nulla vieta di usare dimensioni personalizzate):

  • /126: contiene 2 soli host, utilizzata per i collegamenti punto-punto nell'infrastruttura di rete;
  • /64: è la più piccola rete che dovrebbe essere fatta; dimensione utilizzata nelle LAN; lo spazio di indirizzamento è esageratamente sovradimensionato ed è sufficiente per qualunque LAN immaginabile (è 4 miliardi di volte più grande di tutta la rete Internet IPv4); viene usata in ambito domestico;
  • /56: contiene 256 reti di dimensione /64, viene usata in ambito domestico o per piccole imprese;
  • /48: contiene 65536 reti di dimensione /64, viene usata in ambito aziendale;

Le LAN non devono avere un prefisso più lungo di /64, perché molte nuove funzionalità introdotte con IPv6 (es SLAAC, Privacy Extension, ...), e anche funzionalità che saranno introdotte in futuro, daranno per scontato che le reti abbiano almeno questa dimensione.

Ottenere connettività IPv6

  • si può richiedere nativamente al proprio ISP, ma in Italia non sono molti gli operatori consumer che la forniscono;
  • si possono fare dei tunnel che veicolano il traffico IPv6 all'interno dei pacchetti IPv4 (sprecando un po' di banda);

Tunnel:

  • pro:
    • molti sono gratuiti;
  • contro:
    • spreco di banda per incapsulare i pacchetti (qualche decina di byte in più per ogni pacchetto, circa 20 ogni 1500);
    • maggiore latenza;
    • alcuni richiedono un indirizzo IPv4 statico; altri richiedono complicate configurazioni per l'uso con indirizzi dinamici;
    • alcuni non funzionano dietro NAT (la quasi totalità delle reti domestiche);

Considerazioni e descrizione generale

Come portare IPv6 al GOLEM?

Tunnel-ipv6.jpeg

Infrastrutture (quasi) esistenti:

  • VPN

Viene realizzato un tunnel tra un intermediario e il nostro VPS. L'intermediario inoltra al VPS tutti i pacchetti destinati alla nostra rete. La nostra rete viene scomposta in sottoreti: una rete di backbone, una per l'officina e una per ogni altro punto di accesso necessario, es uno per ogni abitazione dei soci. Il VPS conosce le rotte per raggiungere ogni singola sottorete e inoltra i pacchetti che riceve dall'intermediario verso il giusto router di ogni punto di accesso. Il router del punto di accesso inoltra i pacchetti allo specifico host destinatario.

Si procede analogamente a ritroso.

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: [6] [7]

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 <math>2^{80}</math> 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 <math>2^{16}</math> 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 (<math>2^4</math> = 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;

Golem-template-note-reminder.png 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 <math>2^{64}</math> 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.

Golem-template-note-attention.png Non ancora testato! 


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

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.

Golem-template-note-reminder.png 'Nota bene': salvare queste impostazioni, per esempio con iptables-save e iptables-restore, altrimenti verranno perse al riavvio.


Direttamente sull'host

Si può agire direttamente sugli host da proteggere: 

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

In generale con Linux questa operazione non è comunque necessaria, perché tanto non vi sono servizi esposti a meno che non siano stati installati esplicitamente.

Dal gateway

Invece di configurare il firewall su ogni host singolarmente, si può configurare il gateway una volta sola per proteggere tutta la rete a valle: 

# ip6tables -A FORWARD -s 2001:470:c844:rrrr::/64 -j ACCEPT
# ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# ip6tables -P FORWARD DROP

Nell'ordine:

  • blocca l'inoltro di tutti i pacchetti
  • abilita l'inoltro dei pacchetti in uscita dalla rete
  • abilita l'inoltro dei pacchetti correlati a connessioni già stabilite

Questo impedisce l'accesso indesiderato a tutti gli host della rete, compresi gli host con Windows che possono starsene "sicuri" anche senza il firewall, pur esponendo servizi (NetBIOS, Samba).

Eccezioni

Se si desidera comunque rendere accessibile un proprio server in particolare, è possibile istruire il gateway con un'eccezione, aggiungendo: 

# ip6tables -A FORWARD -d 2001:470:c844:rrrr::host -j ACCEPT

Questo è qualcosa che "assomiglia" vagamente al vecchio port forwarding.

Torrent

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

Golem-template-note-reminder.png TODO: Questa sezione è da fare!

Estratto da "https://wiki.golem.linux.it/index.php?title=IPv6_@_GOLEM&oldid=8223"