Differenze tra le versioni di "IPv6 @ GOLEM"

Da GolemWiki.
Jump to navigation Jump to search
 
(55 versioni intermedie di 3 utenti non mostrate)
Riga 1: Riga 1:
{{Note
+
== Due parole su questa pagina ==
|type=attention
+
Questa pagina è un maldestro tentativo:
|text=PAGINA IN COSTRUZIONE
+
* per riassumere le ragioni che ci hanno portato a decidere di dotarci di IPv6;
}}
+
* per documentare la nostra infrastruttura di rete;
 +
 
 +
=== A chi si rivolge questa pagina ===
 +
* se sei l''''amministratore di rete''', buona lettura :-)
 +
* se sei un '''socio''', vedi come [[#Configurazione_lato_client | configurare il tuo client]]; è sufficiente leggere solo questo paragrafo.
 +
 
 +
== Due parole sull'IPv6 ==
 +
[https://it.wikipedia.org/wiki/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.
 +
 
 +
{| class="wikitable"
 +
| '''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 [https://it.wikipedia.org/wiki/Popolazione_mondiale], di cui la metà [http://www.lastampa.it/2018/01/31/tecnologia/gli-utenti-di-internet-sono-pi-di-quattro-miliardi-nel-mondo-milioni-in-italia-wMxQskzXeabwa3wgWI2jUO/pagina.html] è 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à.
 +
 
 +
Mentre questa pagina veniva scritta, gli IPv4 stavano finendo [https://en.wikipedia.org/wiki/IPv4_address_exhaustion].
 +
Nel novembre 2019, il RIPE (il registro europeo) ha terminato l'assegnazione degli ultimi indirizzi IPv4 assegnati all'Europa, [https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool] e adesso vengono solo riutilizzati quelli vecchi, che significa che:
 +
* non ci sono più indirizzi "nuovi" e dunque non è più possibile richiederli con facilità;
 +
* se si vogliono degli indirizzi IPv4, si viene messi in lista d'attesa, finché il precedente proprietario fallisce e rilascia i propri.
 +
 
 +
=== IPv4 vs IPv6 ===
 +
==== Notazione ====
 +
* IPv4 &rarr; 4 byte rappresentati con numeri decimali separati da un punto, es: <code>192.0.2.127</code>
 +
* IPv6 &rarr; 16 byte, ogni byte è rappresentato da due cifre esadecimali; ogni 4 cifre esadecimali si inseriscono i ''due punti'' <code>:</code>; 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):
 +
** <code>2001:0470:c844:0020:0000:0000:0000:0001</code>
 +
** <code>2001:470:c844:20:0:0:0:1</code>
 +
** <code>2001:470:c844:20::1</code>
 +
 
 +
==== Tipi di indirizzi ====
 +
* IPv6 Reference Card by RIPE [https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-address-types/ipv6_reference_card_July2015.pdf]
 +
 
 +
Riassunto:
 +
{| class="wikitable"
 +
| '''IPv6'''
 +
| '''Equivalente IPv4'''
 +
| '''Significato'''
 +
|-
 +
| <code>::1/128</code>
 +
| <code>127.0.0.1</code>
 +
| Indirizzo loopback
 +
|-
 +
| <code>fc00::/7</code>
 +
| <code>192.168.0.0/16</code>, <code>10.0.0.0/8</code>, <code>172.16.0.0/12</code>
 +
| Indirizzo privato
 +
|-
 +
| <code>fe80::/10</code>
 +
| <code>169.254.0.0/16</code>
 +
| Indirizzo link-local (univoco nella rete locale, e autoassegnato)
 +
|-
 +
| <code>2001:db8::/32</code>
 +
| <code>192.0.2.0/24</code>
 +
| Esempi e documentazione
 +
|-
 +
| <code>2000::/3</code>
 +
|
 +
| 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. Quando è stata scritta questa pagina, in Italia non erano molti gli operatori che fornivano connettività IPv6 nativa; adesso sono di più, perché gli IPv4 sono finiti, e non sarebbe altrimenti possibile fare business, ma alcuni operatori (specialmente quelli più grandi e noti), ancora non forniscono connettività IPv6 nativa;
 +
* 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?
 +
 
 +
È stato 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.
  
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.
+
Si procede analogamente a ritroso.
  
In figura è mostrata la visione ''logica'' della rete che si vuole realizzare:
+
In figura è mostrata la prima versione di visione ''logica'' della rete realizzata:
 
* '''HE''' (Hurricane Electric) è il provider fornitore IPv6;
 
* '''HE''' (Hurricane Electric) è il provider fornitore IPv6;
 
* '''OVH''' è il nostro provider per il VPS;
 
* '''OVH''' è il nostro provider per il VPS;
 
* '''VPS''' è il nostro VPS;
 
* '''VPS''' è il nostro VPS;
 
* '''serverozzo''' è il gateway in [[Officina Informatica]];
 
* '''serverozzo''' è il gateway in [[Officina Informatica]];
 +
 +
Per permettere il collegamento tra il VPS e un punto di accesso (anche noto in questa pagina come ''gateway dell'utente''), non essendo possibile stendere dei cavi fisici in giro per l'Europa, utilizzeremo la nostra VPN.
 +
Esistono delle pagine dedicate per la documentazione sulla [[Rete del GOLEM]].
 +
 +
<gallery>
 +
File:Tunnel-ipv6.jpeg|Il primo prototipo della rete del GOLEM, con la VPN e il tunnel IPv6.
 +
</gallery>
  
 
== Iniziare: rete /64 ==
 
== Iniziare: rete /64 ==
Come iniziare?
+
Sono l'amministratore di rete e voglio attivare il tunnel IPv6 per la prima volta. Come iniziare?
  
 
Ci si registra su [https://tunnelbroker.net/ TunnelBroker] e viene assegnata d'ufficio una rete IPv6 ''/64''.
 
Ci si registra su [https://tunnelbroker.net/ TunnelBroker] e viene assegnata d'ufficio una rete IPv6 ''/64''.
Riga 24: Riga 137:
  
 
Attiviamo il tunnel, aggiungendo questo al ''/etc/network/interfaces'':
 
Attiviamo il tunnel, aggiungendo questo al ''/etc/network/interfaces'':
 +
 
  auto he6in4
 
  auto he6in4
 
  iface he6in4 inet6 v4tunnel
 
  iface he6in4 inet6 v4tunnel
        address 2001:470:1f12:69::2
+
address 2001:470:1f12:69::2/64
        netmask 64
 
 
         endpoint 216.66.84.42
 
         endpoint 216.66.84.42
         gateway 2001:470:1f12:69::1
+
         local 152.228.140.73
        ttl 64
+
        ttl 255
 +
 
 +
Se si vuole utilizzare il tunnel come default gateway, aggiungere anche:
 +
gateway 2001:470:1f12:69::1
 +
 
 +
{{Note
 +
|type=warning
 +
|text=È possibile utilizzare un solo default gateway su Linux, perciò assicurarsi di non confliggere con la configurazione IPv6 del vostro provider (se c'è)
 +
}}
  
Possiamo adesso verificare la connettività tra il VPS e il PoP del broker con:
+
e verificare la connettività tra il VPS e il PoP del broker con:
 
  $ ip -6 addr
 
  $ ip -6 addr
 
  $ ping 2001:470:1f12:69::1
 
  $ ping 2001:470:1f12:69::1
Riga 40: Riga 161:
  
 
Nella maggior parte dei casi il server DNS IPv4 usato sin'ora ha anche il supporto per risolvere nomi IPv6.
 
Nella maggior parte dei casi il server DNS IPv4 usato sin'ora ha anche il supporto per risolvere nomi IPv6.
 +
 +
Probabilmente però '''non''' si vorrà utilizzare questa configurazione, bensì sfruttare la rete /48 come spiegato nel prossimo paragrafo.
  
 
== Rete /48 ==
 
== 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: [https://tools.ietf.org/html/rfc3177] [https://tools.ietf.org/html/rfc5375#section-3.1]
+
Siccome una rete IPv6 fisica (per esempio, una rete domestica) ha dimensione /64, ma il GOLEM, a sua volta, diventa provider per i soci, 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: [https://tools.ietf.org/html/rfc3177] [https://tools.ietf.org/html/rfc5375#section-3.1]
  
 
Ci è stata assegnata la rete <code>2001:470:c844::/48</code>, che significa:
 
Ci è stata assegnata la rete <code>2001:470:c844::/48</code>, 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;
 
* 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;
+
* 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.
 
Lo so, dopo anni bui di NAT dopo NAT e carenza di indirizzi, questa sembra fantascienza.
 +
 +
=== Routing ===
 +
Si può decidere di instradare tutto il traffico IPv6 tramite il tunnel broker, senza mai utilizzare l'IPv6 assegnato dal provider.
 +
 +
Se però il server dispone già di un IPv6 assegnato dal provider, probabilmente si vuole e si può:
 +
* utilizzare il suo IPv6 per navigare dal server, usando il gateway del provider
 +
* utilizzare il gateway del tunnel broker solo per instradare i pacchetti della rete /48 che è stata assegnata
 +
 +
Al GOLEM abbiamo fatto questa seconda scelta.
 +
Perciò, '''non''' si deve aggiungere il gateway del tunnel broker come default gateway della configurazione in ''/etc/network/interfaces'', ma si deve aggiungere una regola di routing a mano per la sottorete del GOLEM, di fatto implementando ''source routing''.
 +
 +
{{Note
 +
|type=info
 +
|text=Chiamasi ''source routing'' l'instradamento dei pacchetti fatto in base al loro indirizzo sorgente e non quello di destinazione, che è il modo standard
 +
}}
 +
 +
1. Modificare ''/etc/iproute2/rt_tables'' aggiungendo una nuova tabella di routing:
 +
200 golemsix
 +
 +
2. Aggiungere il routing dei pacchetti provenienti dalla sottorete del GOLEM automaticamente al post-up dell'interfaccia del tunnel in ''/etc/network/interfaces'':
 +
  post-up ip -6 rule add from 2001:470:c844::/48 table golemsix && ip -6 rule add to 2001:470:c844::/48 table main && ip -6 route add default via 2001:470:1f12:69::1 dev he6in4 table golemsix && ip -6 route flush cache
 +
pre-down ip -6 route del default via 2001:470:1f12:69::1 dev he6in4 table golemsix && ip -6 rule del to 2001:470:c844::/48 table main && ip -6 rule del from 2001:470:c844::/48 table golemsix && ip -6 route flush cache
 +
 +
Spiegazione:
 +
* I pacchetti provenienti dalla sottorete del GOLEM devono utilizzare la tabella di routing <code>golemsix</code>:
 +
ip -6 rule add from 2001:470:c844::/48 table golemsix
 +
 +
* I pacchetti destinati alla sottorete del GOLEM devono utilizzare la tabella di routing <code>main</code>, così da poter essere instradati correttamente anche ai soci collegati con la VPN Wireguard. Si noti che, se inserita in quest'ordine, questa seconda regola ha priorità sulla precedente, ed è quello che vogliamo.
 +
ip -6 rule add to 2001:470:c844::/48 table main
 +
 +
* Il default gateway per i pacchetti che utilizzano la tabella di routing <code>golemsix</code> è l'endpoint del tunnel broker
 +
ip -6 route add default via 2001:470:1f12:69::1 dev he6in4 table golemsix
 +
 +
* Aggiorna la cache del routing:
 +
ip -6 route flush cache
 +
 +
Analogamente, vengono eseguite le operazioni inverse quando viene spenta l'interfaccia di rete.
  
 
=== Piano di indirizzamento ===
 
=== Piano di indirizzamento ===
Riga 58: Riga 218:
 
     2001 : 0470 : c844 : rrrr : xxxx : xxxx : xxxx : xxxx
 
     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).
+
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:
+
Per semplicità (perché alla fine è a questo che servono tutti questi indirizzi in IPv6), poniamo ''rrrr'' = ''uugy'', dove:
* ''zzz'' (12 bit) identifica l'''utente'';
+
* ''uu'' (8 bit) identifica l'''utente'';
* ''y'' (4 bit) identifica la ''sottorete personale'' dell'utente (2^4 = 16 sottoreti personali)
+
* ''g'' (4 bit) identifica il gateway dell'utente (<math>2^4</math> = 16 gateway per utente)
 +
* ''y'' (4 bit) identifica la ''sottorete personale'' di quel gateway dell'utente (<math>2^4</math> = 16 sottoreti per gateway)
  
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.
+
Il VPS instrada direttamente tutta la sottorete /60 verso il gateway dell'utente, il quale può decidere di suddividerla come preferisce su quel gateway, da un unica grande rete /60, a 16 "piccole" reti /64.
  
 
Sono così riservate:
 
Sono così riservate:
  000y Servizio (16 reti)
+
  00gy indirizzi di servizio per l'infrastruttura (OpenVPN)
  001y non usata
+
  01gy indirizzi di servizio per l'infrastruttura (Wireguard)
  002y Officina (16 reti)
+
  02gy Officina (16 gateway × 16 reti)
  003y Socio-A (16 reti)
+
  03gy Socio-A (16 gateway × 16 reti)
  004y Socio-B (16 reti)
+
  04gy Socio-B (16 gateway × 16 reti)
  005y ...
+
  05gy ...
  
 
Il ''numero di rete'' <code>rrrr</code> sarà usato:
 
Il ''numero di rete'' <code>rrrr</code> sarà usato:
* per instradare tutto il traffico diretto a <code>2001:470:c844:rrrr::/64</code> verso il gateway dell'utente;
+
* per instradare tutto il traffico diretto a <code>2001:470:c844:rrg0::/60</code> verso il gateway dell'utente;
* per assegnare l'indirizzo <code>2001:470:c844::rrrr/64</code> al gateway dell'utente nella rete di servizio;
+
* per assegnare l'indirizzo <code>2001:470:c844::rrg0/64</code> al gateway dell'utente nella rete di servizio;
 
Si noti la "piccola" differenza.
 
Si noti la "piccola" differenza.
 +
 +
Per esempio, supponiamo di voler attivare ''serverozzo'', per il quale:
 +
* ''uu = 02'' (''02'' è l'utente ''Officina'')
 +
* ''g = 0'' (''0'' il primo &mdash; e al momento unico &mdash; gateway in Officina)
 +
allora:
 +
* serverozzo avrà indirizzo <code>2001:470:c844::200/64</code> lato VPN;
 +
* tutto il traffico per <code>2001:470:c844:200::/60</code> verrà instradato verso serverozzo;
 +
 +
E su serverozzo potranno essere create fino a 16 reti, per esempio:
 +
* per la rete cablata Ethernet dell'Officina (<code>2001:470:c844:200::/64</code> sull'interfaccia <code>ethI</code>);
 +
* per la rete wireless dell'Officina (<code>2001:470:c844:201::/64</code> sull'interfaccia <code>wlan0</code>);
 +
* per la rete cablata bus RS-485 (<code>2001:470:c844:202::/64</code> sull'interfaccia <code>ttyS0</code>);
 +
* per le macchine virtuali su KVM (<code>2001:470:c844:203::/64</code> sull'interfaccia <code>vir0</code>);
 +
* per le macchine virtuali su docker (<code>2001:470:c844:204::/64</code> sull'interfaccia <code>docker0</code>);
 +
* ...
 +
'''Nota:''' questo è solo un esempio, la configurazione finale su serverozzo è ancora in fase di definizione.
  
 
Nella prima rete di servizio (<code>2001:470:c844::/64</code>) ci sono:
 
Nella prima rete di servizio (<code>2001:470:c844::/64</code>) ci sono:
 
* il VPS
 
* il VPS
* il serverozzo
+
* tutti i gateway
* tutti i gateway dei soci
+
** per esempio, serverozzo
 +
** per esempio, 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.
 
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:
 
Così organizzate, le risorse si esauriranno in questo ordine:
* la banda a disposizione del VPS (100M/100M);
+
* la banda a disposizione del VPS (500M/500M);
 
* la capacità computazionale e di memoria del VPS per l'inoltro dei pacchetti;
 
* la capacità computazionale e di memoria del VPS per l'inoltro dei pacchetti;
 
* gli IPv6 (gli IPv6 non finiranno mai)
 
* gli IPv6 (gli IPv6 non finiranno mai)
  
 
Non essendo una rete a maglie, ma semplicemente un albero, il routing è definito staticamente.
 
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...
+
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 dimensione del bacino di utenti, non dovrebbe essere necessario.
  
== OpenVPN ==
+
== Installazione del server ==
Nel tunnel di OpenVPN è presente la prima rete di servizio <code>2001:470:c844::/64</code> (con ''rrrr'' = ''0000'').
+
La VPN del GOLEM può essere utilizzata per la navigazione in IPv6.
 +
La VPN è realizzata per mezzo di Wireguard.
  
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.
+
A differenza di altri protocolli, come OpenVPN, Wireguard ha un approccio "peer to peer", per cui la procedura di configurazione del server rispecchia per buona parte quella di ciascun client.
  
Configurazione del server OpenVPN sul VPS server:
+
Innanzitutto è necessario generare la coppia di chiavi pubblica/privata del server:
port xxxxx
+
 
  proto udp
+
  # wg genkey | tee /etc/wireguard/server.privkey | wg pubkey > /etc/wireguard/vpn.golem.linux.it.pubkey
+
 
dev tun
+
Per la configurazione è sufficiente creare un singolo file, ad esempio <code>/etc/wireguard/wg0.conf</code>:
 
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:
+
[Interface]
* ''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;
+
# Carica la chiave privata dal percorso dove la abbiamo generata precedentemente
* ''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''
+
PostUp = wg set %i private-key /etc/wireguard/vpn.golem.linux.it.privkey
* ''push tun-ipv6'' è un tunnel IPv6;
+
# Porta UDP di ascolto del server, a piacere
* ''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;
+
ListenPort = 51820
* ''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;
+
# Indirizzo del server all'interno della VPN
 +
Address = 2001:470:c844:100::1
  
{{Note
+
Il server può essere avviato tramite ''systemd'', e con lo stesso sistema si può impostare l'avvio automatico.
|type=reminder
+
Si noti che <code>@wg0</code> corrisponde al file di configurazione precedentemente creato.
|text=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 ==
+
# systemctl start wg-quick@wg0
Verrà presa ad esempio la configurazione del gateway di officina '''serverozzo''', che, secondo quanto stabilito nei precedenti paragrafi avrà indirizzo <code>2001:470:c844::20</code> e inoltrerà i pacchetti da/per la rete <code>2001:470:c844:20::/64</code>.
+
# systemctl enable wg-quick@wg0
  
=== Generare chiave SSL ===
+
== Aggiunta di un nuovo client ==
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 lato server ===
 +
il sysop aggiunge un blocco peer per ciascun client alla configurazione <code>/etc/wireguard/wg0.conf</code>, così:
  
=== Configurazione del server OpenVPN ===
+
... altri client ...
==== Comunicare la nuova rete a tutti i client ====
+
Sul server OpenVPN, nel file di configurazione del server ''/etc/openvpn/server.ipv6.conf'', aggiungere una rotta per la nuova rete:
+
  # porceddu.net.golem.linux.it
  ...
+
  [Peer]
  push "route-ipv6 2001:470:c844:20::/64"
+
PublicKey = tHeClIeNtFaNtAsTiCpUbLiCkEy=
  ...
+
AllowedIPs = 2001:470:c844:100::200/128, 2001:470:c844:200::/62
Questo comunica a tutti i client che quella rete è raggiungibile per mezzo del server OpenVPN.
+
 +
  ... altri client ...
  
{{Note
+
Altro che OpenVPN.
|type=reminder
 
|text=Non basta la rotta di default? Perché appesantire i client con tutte queste rotte? Non sono ridondanti? Non funziona ugualmente con <code>push "route-ipv6 2001:470:c844::/48"</code>?
 
}}
 
  
==== Comunicare al client il suo indirizzo IPv6 statico ====
+
=== Configurazione lato client ===
Sul server OpenVPN, nel file di configurazione del client ''/etc/openvpn/staticclients/hostname'', scrivere le seguenti righe:
+
1. Lato client, generare una coppia di chiavi pubblica/privata e inviare la chiave pubblica al sysop.
ifconfig-ipv6-push 2001:470:c844::20/64
 
iroute-ipv6 2001:470:c844:20::/64
 
  
Rispettivamente per:
+
$ wg genkey | tee client.example.com.privkey | wg pubkey > client.example.com.pubkey
* 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 ====
+
Il sysop si occuperà di aggiungere la chiave pubblica tra quelle consentite al server, sceglierà un indirizzo IP in base al piano di indirizzamento, e ve lo comunicherà.
Sul server OpenVPN, impostare la rotta per la nuova rete (utilizzare l'apposito file di configurazione ''/root/firewall/route-ipv6.fw.conf''):
 
# ip -6 route add 2001:470:c844:20::/64 via 2001:470:c844::20
 
  
=== Configurazione del client ===
+
2. Creare un file di configurazione come segue, in cui scrivere opportunamente la vostra chiave privata e l'indirizzo IP assegnato. Prestare particolare attenzione a modificare i campi della sezione <code>Interface</code>, come indicato nelle note.
==== Connessione alla VPN ====
 
Usare questo file di configurazione sul client openvpn:
 
  
  client
+
  [Interface]
  dev tun
+
  # PrivateKey = YoUrGoRgEoUsAnDsEcUrEpRiVaTeKeY=              # vedi note, scegliere questo...
proto udp
+
  # PostUp = wg set %i private-key ./client.example.com.privkey # vedi note,                ...oppure questo
remote golem.linux.it xxxxx
+
  Address = 2001:470:c844:100::'''200'''/64                          # vedi note
  resolv-retry infinite
 
  nobind
 
 
   
 
   
  user nobody
+
  # vpn.golem.linux.it
  group nogroup
+
  [Peer]
   
+
  PublicKey = w63aGvoyPaUTgA8nW/NJS6Qqp2hUFvHRBbIH8Qb5ISY= 
  ns-cert-type server
+
  AllowedIPs = 2000::/3                                     
  ca /etc/openvpn/golem.linux.it/ca.crt
+
  Endpoint = vpn.golem.linux.it:51280
  cert /etc/openvpn/golem.linux.it/serverozzo.crt
+
  PersistentKeepalive = 37
key /etc/openvpn/golem.linux.it/serverozzo.key
+
 
+
'''Note'''
keepalive 30 120
+
* <code>Interface</code> (sezione di configurazione dell'endpoint ''locale'')
persist-key
+
** scegliere una delle seguenti opzioni per indicare la chiave privata del client, scommentando la riga apposita.
persist-tun
+
*** ''PrivateKey'': chiave privata del client, da custodire con cura, inline
+
*** ''PostUp = command'': chiave privata del client, da custodire con cura, e caricata automaticamente da un file esterno (es. creato col comando mostrato in precedenza)
  comp-lzo
+
** ''Address'': indirizzo IP comunicato dal sysop: riportarlo accuratamente, altrimenti non sarà possibile utilizzare la VPN
+
* <code>[Peer]</code> (sezione di configurazione dell'endpoint ''remoto'' / server)
  verb 3
+
** ''PublicKey'': chiave pubblica del server (sì, è proprio quella)
 +
** ''AllowedIPs'': indirizzi raggiungibili tramite la VPN, a scelta:
 +
*** <code>2001:470:c844::/48</code>: solo la [[IPv6 @ GOLEM | rete IPv6 virtuale del GOLEM]]
 +
*** <code>2000::/3</code>: tutti gli indirizzi IPv6 (è possibile utilizzare la VPN del GOLEM per [[IPv6 @ GOLEM | navigare ''davvero'' in IPv6]])
 +
** ''Endpoint'': indirizzo del server
 +
** ''PersistentKeepalive'': timer per mantenimento del tunnel attivo (in secondi); particolarmente utile se l'indirizzo IP del client cambia o è soggetto a NAT
 +
 
 +
La connessione può essere attivata tramite systemd come sul server (spostandola in ''/etc/wireguard/''), oppure manualmente utilizzando <code>wg-quick</code>:
 +
* Attivazione del tunnel
 +
  wg-quick up client.example.conf
 +
* Disattivazione del tunnel
 +
  wg-quick down client.example.conf
  
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.
+
3. Provare il collegamento
 +
# ping 2001:470:c844:100::1    # server VPN, dentro al tunnel (per verificare se il collegamento funziona)
 +
# ping 2001:470:c844:100::200  # gateway in Officina (per verificare se il collegamento funziona; talvolta non raggiungibile se abbiamo staccato la luce)
 +
# ping ipv6.google.com        # per verificare l'accessibilità dell'Internet pubblico IPv6, nel caso non si abbia già accesso
  
Se invece il client è il gateway della rete (es. serverozzo, o di casa di uno dei soci), allora bisogna configurarlo come segue.
+
4. Successo!
 +
* 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. È comunque consigliato leggere la sezione relativa al [[#Firewall | firewall]] per ragioni di sicurezza ed eventualmente attivarlo.
 +
* Se invece il client è il gateway della rete IPv6 (es. ''serverozzo'', o il router di casa di uno dei soci che vuole navigare in IPv6), allora bisogna configurarlo come indicato nella [[#Client_VPN_come_gateway | sezione apposita]].
  
==== Impostare il client OpenVPN come gateway IPv6 per l'isola ====
+
== Client VPN come gateway ==
===== Abilitare inoltro pacchetti IPv6 =====
+
=== Impostare il client VPN come gateway IPv6 per l'isola ===
 +
==== Abilitare inoltro pacchetti IPv6 ====
 
Nel file ''/etc/sysctl.conf'':
 
Nel file ''/etc/sysctl.conf'':
 
  net.ipv6.conf.all.forwarding=1
 
  net.ipv6.conf.all.forwarding=1
  
===== Installare e configurare radvd =====
+
==== Installare e configurare radvd ====
 
''radvd'' è il demone di ''router advertisement''.
 
''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''.
+
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. [https://tools.ietf.org/search/rfc4862 SLAAC] con o senza [https://tools.ietf.org/html/rfc4941.html estensione per la privacy]).
 
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. [https://tools.ietf.org/search/rfc4862 SLAAC] con o senza [https://tools.ietf.org/html/rfc4941.html estensione per la privacy]).
 
L'unica cosa che non si può configurare automaticamente con ''radvd'' (vai a capire perché) è un server DNS.
 
 
Per il momento tutto funziona ugualmente, perché tanto:
 
* la quasi totalità delle reti è mista IPv4 / IPv6
 
* il server DNS IPv4 può essere interrogato anche per ottenere traduzioni di nomi IPv6
 
  
 
Installare ''radvd'':
 
Installare ''radvd'':
Riga 227: Riga 376:
  
 
Configurare il file ''/etc/radvd.conf'':
 
Configurare il file ''/etc/radvd.conf'':
  interface br0 {
+
  interface ethI {
 
         AdvSendAdvert on;
 
         AdvSendAdvert on;
 
         MinRtrAdvInterval 2;
 
         MinRtrAdvInterval 2;
 
         MaxRtrAdvInterval 10;
 
         MaxRtrAdvInterval 10;
         prefix 2001:470:c844:20::/64 {
+
         prefix 2001:db8::/64 {
 
                 AdvOnLink on;
 
                 AdvOnLink on;
 
                 AdvAutonomous on;
 
                 AdvAutonomous on;
 
                 AdvRouterAddr on;
 
                 AdvRouterAddr on;
 +
        };
 +
        RDNSS 2606:4700:4700::1111 {
 +
                AdvRDNSSLifetime 3600;
 
         };
 
         };
 
  };
 
  };
dove ''prefix'' naturalmente indica la rete a valle.
+
dove
 +
* <code>interface br0</code> indica l'interfaccia interna su cui fare ''advertise'';
 +
* <code>prefix 2001:db8::/64</code> indica la rete a valle;
 +
* <code>RDNSS 2606:4700:4700::1111</code> indica il server DNS (nell'esempio specifico, CloudFlare);
 +
** ''Nota:'' in seguito a questioni legali, OpenDNS non è al momento disponibile in Francia.
  
 
== Firewall ==
 
== Firewall ==
Riga 247: Riga 403:
 
|text=Non ancora testato!
 
|text=Non ancora testato!
 
}}
 
}}
# ip6tables -P FORWARD DROP
 
 
  # ip6tables -A FORWARD -d 2001:470:c844::/48 -i he6in4 -j ACCEPT
 
  # 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 -A FORWARD -s 2001:470:c844::/48 -o he6in4 -j ACCEPT
 +
# ip6tables -P FORWARD DROP
  
=== Per gli host ===
+
=== Per i client ===
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.
+
Gli indirizzi IPv6 sono "tutti" pubblici. Gli indirizzi IPv6 forniti dal GOLEM sono pubblicamente instradabili. In più, il GOLEM non mette in atto '''nessuna''' misura atta a prevenire connessioni dirette verso gli host della VPN (al netto di configurazioni specifiche sulle macchine direttamente di proprietà del GOLEM).
 +
Ciò significa che '''tutti''' gli host degli utenti/soci, compresi quelli domestici che sin'ora sono stati dietro a un (s)comodo NAT, possono essere acceduti attraverso la rete Internet globale, quando sono connessi alla VPN del GOLEM.
  
# ip6tables -P INPUT DROP
+
Pertanto, è consigliato attivare degli strumenti atti a prevenire accessi indesiderati dall'esterno, come un firewall, in special modo se il proprio computer "fornisce servizi" (eg. condivisione di file via rete, server web di sviluppo, ...)
# ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
  
 
{{Note
 
{{Note
 
|type=reminder
 
|type=reminder
|text=Salvare queste impostazioni, per esempio con <code>iptables-save</code> e <code>iptables-restore</code>, altrimenti verranno perse al riavvio.
+
|text='''Nota bene''': salvare queste impostazioni, per esempio con <code>ip6tables-save</code> e <code>ip6tables-restore</code>, altrimenti verranno perse al riavvio.
 
}}
 
}}
  
Si può fare anche qualcosa direttamente sul gateway, così da non dover replicare la configurazione su ogni host.
+
==== Direttamente sull'host ====
 +
Si può agire direttamente sugli host da proteggere (versione conservativa):
 +
# ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 +
# ip6tables -A INPUT -p icmpv6 -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.
 +
Si noti che ICMPv6 deve comunque sempre essere abilitato in quanto necessario al funzionamento di IPv6.
 +
 
 +
Si può anche utilizzare una regola più rilassata (es. per sfruttare la VPN del GOLEM come VPN "personale" tra i propri host), tipo:
 +
# ip6tables -A INPUT -s 2001:470:c844:uu00::/56 -j ACCEPT
  
 
{{Note
 
{{Note
|type=reminder
+
|type=info
|text=TODO: Questa sezione è da espandere!
+
|text=I pacchetti della VPN viaggiano crittografati sulla rete pubblica (almeno finché si trovano all'interno della VPN del GOLEM), ma sul server vengono decifrati e cifrati di nuovo per permetterne il routing!
 +
In caso di compromissione del VPS del GOLEM, pertanto, i pacchetti non possono essere considerati al sicuro da sguardi indiscreti. È sempre buona norma utilizzare crittografia end-to-end, anche all'interno di una VPN.
 
}}
 
}}
 +
 +
==== 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 ===
 
=== Torrent ===
Riga 276: Riga 462:
 
|text=TODO: Questa sezione è da fare!
 
|text=TODO: Questa sezione è da fare!
 
}}
 
}}
 +
 +
= Risoluzione problemi =
 +
== Geolocalizzazione ==
 +
Il tunnel è localizzato in Francia.
 +
A causa di restrizioni imposte a causa del diritto d'autore, alcuni siti, specialmente di streaming video, come Netflix, Rai.tv o Youtube, potrebbero bloccare l'accesso ai contenuti italiani dal tunnel francese.
 +
Per inibire temporaneamente l'uso del tunnel IPv6 su un host:
 +
# sysctl -w net.ipv6.conf.all.disable_ipv6=1
 +
 +
[[Categoria:Howto]]
 +
[[Categoria:Officina]]
 +
[[Category:Sysop]]

Versione attuale delle 12:35, 1 nov 2024

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;

A chi si rivolge questa pagina

  • se sei l'amministratore di rete, buona lettura :-)
  • se sei un socio, vedi come configurare il tuo client; è sufficiente leggere solo questo paragrafo.

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à.

Mentre questa pagina veniva scritta, gli IPv4 stavano finendo [3]. Nel novembre 2019, il RIPE (il registro europeo) ha terminato l'assegnazione degli ultimi indirizzi IPv4 assegnati all'Europa, [4] e adesso vengono solo riutilizzati quelli vecchi, che significa che:

  • non ci sono più indirizzi "nuovi" e dunque non è più possibile richiederli con facilità;
  • se si vogliono degli indirizzi IPv4, si viene messi in lista d'attesa, finché il precedente proprietario fallisce e rilascia i propri.

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. Quando è stata scritta questa pagina, in Italia non erano molti gli operatori che fornivano connettività IPv6 nativa; adesso sono di più, perché gli IPv4 sono finiti, e non sarebbe altrimenti possibile fare business, ma alcuni operatori (specialmente quelli più grandi e noti), ancora non forniscono connettività IPv6 nativa;
  • 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?

È stato 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 prima versione di visione logica della rete realizzata:

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

Per permettere il collegamento tra il VPS e un punto di accesso (anche noto in questa pagina come gateway dell'utente), non essendo possibile stendere dei cavi fisici in giro per l'Europa, utilizzeremo la nostra VPN. Esistono delle pagine dedicate per la documentazione sulla Rete del GOLEM.

Iniziare: rete /64

Sono l'amministratore di rete e voglio attivare il tunnel IPv6 per la prima volta. 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/64
        endpoint 216.66.84.42
        local 152.228.140.73
        ttl 255

Se si vuole utilizzare il tunnel come default gateway, aggiungere anche:

	gateway 2001:470:1f12:69::1

Golem-template-note-warning.png È possibile utilizzare un solo default gateway su Linux, perciò assicurarsi di non confliggere con la configurazione IPv6 del vostro provider (se c'è)


e 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.

Probabilmente però non si vorrà utilizzare questa configurazione, bensì sfruttare la rete /48 come spiegato nel prossimo paragrafo.

Rete /48

Siccome una rete IPv6 fisica (per esempio, una rete domestica) ha dimensione /64, ma il GOLEM, a sua volta, diventa provider per i soci, 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.

Routing

Si può decidere di instradare tutto il traffico IPv6 tramite il tunnel broker, senza mai utilizzare l'IPv6 assegnato dal provider.

Se però il server dispone già di un IPv6 assegnato dal provider, probabilmente si vuole e si può:

  • utilizzare il suo IPv6 per navigare dal server, usando il gateway del provider
  • utilizzare il gateway del tunnel broker solo per instradare i pacchetti della rete /48 che è stata assegnata

Al GOLEM abbiamo fatto questa seconda scelta. Perciò, non si deve aggiungere il gateway del tunnel broker come default gateway della configurazione in /etc/network/interfaces, ma si deve aggiungere una regola di routing a mano per la sottorete del GOLEM, di fatto implementando source routing.

Golem-template-note-info.png Chiamasi source routing l'instradamento dei pacchetti fatto in base al loro indirizzo sorgente e non quello di destinazione, che è il modo standard


1. Modificare /etc/iproute2/rt_tables aggiungendo una nuova tabella di routing:

200	golemsix

2. Aggiungere il routing dei pacchetti provenienti dalla sottorete del GOLEM automaticamente al post-up dell'interfaccia del tunnel in /etc/network/interfaces:

 	post-up ip -6 rule add from 2001:470:c844::/48 table golemsix && ip -6 rule add to 2001:470:c844::/48 table main && ip -6 route add default via 2001:470:1f12:69::1 dev he6in4 table golemsix && ip -6 route flush cache
	pre-down ip -6 route del default via 2001:470:1f12:69::1 dev he6in4 table golemsix && ip -6 rule del to 2001:470:c844::/48 table main && ip -6 rule del from 2001:470:c844::/48 table golemsix && ip -6 route flush cache

Spiegazione:

  • I pacchetti provenienti dalla sottorete del GOLEM devono utilizzare la tabella di routing golemsix:
ip -6 rule add from 2001:470:c844::/48 table golemsix
  • I pacchetti destinati alla sottorete del GOLEM devono utilizzare la tabella di routing main, così da poter essere instradati correttamente anche ai soci collegati con la VPN Wireguard. Si noti che, se inserita in quest'ordine, questa seconda regola ha priorità sulla precedente, ed è quello che vogliamo.
ip -6 rule add to 2001:470:c844::/48 table main
  • Il default gateway per i pacchetti che utilizzano la tabella di routing golemsix è l'endpoint del tunnel broker
ip -6 route add default via 2001:470:1f12:69::1 dev he6in4 table golemsix
  • Aggiorna la cache del routing:
ip -6 route flush cache

Analogamente, vengono eseguite le operazioni inverse quando viene spenta l'interfaccia di rete.

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 = uugy, dove:

  • uu (8 bit) identifica l'utente;
  • g (4 bit) identifica il gateway dell'utente (<math>2^4</math> = 16 gateway per utente)
  • y (4 bit) identifica la sottorete personale di quel gateway dell'utente (<math>2^4</math> = 16 sottoreti per gateway)

Il VPS instrada direttamente tutta la sottorete /60 verso il gateway dell'utente, il quale può decidere di suddividerla come preferisce su quel gateway, da un unica grande rete /60, a 16 "piccole" reti /64.

Sono così riservate:

00gy indirizzi di servizio per l'infrastruttura (OpenVPN)
01gy indirizzi di servizio per l'infrastruttura (Wireguard)
02gy Officina (16 gateway × 16 reti)
03gy Socio-A (16 gateway × 16 reti)
04gy Socio-B (16 gateway × 16 reti)
05gy ...

Il numero di rete rrrr sarà usato:

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

Si noti la "piccola" differenza.

Per esempio, supponiamo di voler attivare serverozzo, per il quale:

  • uu = 02 (02 è l'utente Officina)
  • g = 0 (0 il primo — e al momento unico — gateway in Officina)

allora:

  • serverozzo avrà indirizzo 2001:470:c844::200/64 lato VPN;
  • tutto il traffico per 2001:470:c844:200::/60 verrà instradato verso serverozzo;

E su serverozzo potranno essere create fino a 16 reti, per esempio:

  • per la rete cablata Ethernet dell'Officina (2001:470:c844:200::/64 sull'interfaccia ethI);
  • per la rete wireless dell'Officina (2001:470:c844:201::/64 sull'interfaccia wlan0);
  • per la rete cablata bus RS-485 (2001:470:c844:202::/64 sull'interfaccia ttyS0);
  • per le macchine virtuali su KVM (2001:470:c844:203::/64 sull'interfaccia vir0);
  • per le macchine virtuali su docker (2001:470:c844:204::/64 sull'interfaccia docker0);
  • ...

Nota: questo è solo un esempio, la configurazione finale su serverozzo è ancora in fase di definizione.

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

  • il VPS
  • tutti i gateway
    • per esempio, serverozzo
    • per esempio, 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 (500M/500M);
  • 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 dimensione del bacino di utenti, non dovrebbe essere necessario.

Installazione del server

La VPN del GOLEM può essere utilizzata per la navigazione in IPv6. La VPN è realizzata per mezzo di Wireguard.

A differenza di altri protocolli, come OpenVPN, Wireguard ha un approccio "peer to peer", per cui la procedura di configurazione del server rispecchia per buona parte quella di ciascun client.

Innanzitutto è necessario generare la coppia di chiavi pubblica/privata del server:

# wg genkey | tee /etc/wireguard/server.privkey | wg pubkey > /etc/wireguard/vpn.golem.linux.it.pubkey

Per la configurazione è sufficiente creare un singolo file, ad esempio /etc/wireguard/wg0.conf:

[Interface]
# Carica la chiave privata dal percorso dove la abbiamo generata precedentemente
PostUp = wg set %i private-key /etc/wireguard/vpn.golem.linux.it.privkey
# Porta UDP di ascolto del server, a piacere
ListenPort = 51820
# Indirizzo del server all'interno della VPN
Address = 2001:470:c844:100::1

Il server può essere avviato tramite systemd, e con lo stesso sistema si può impostare l'avvio automatico. Si noti che @wg0 corrisponde al file di configurazione precedentemente creato.

# systemctl start wg-quick@wg0
# systemctl enable wg-quick@wg0

Aggiunta di un nuovo client

Configurazione lato server

il sysop aggiunge un blocco peer per ciascun client alla configurazione /etc/wireguard/wg0.conf, così:

... altri client ...

# porceddu.net.golem.linux.it
[Peer]
PublicKey = tHeClIeNtFaNtAsTiCpUbLiCkEy=
AllowedIPs = 2001:470:c844:100::200/128, 2001:470:c844:200::/62

... altri client ...

Altro che OpenVPN.

Configurazione lato client

1. Lato client, generare una coppia di chiavi pubblica/privata e inviare la chiave pubblica al sysop.

$ wg genkey | tee client.example.com.privkey | wg pubkey > client.example.com.pubkey

Il sysop si occuperà di aggiungere la chiave pubblica tra quelle consentite al server, sceglierà un indirizzo IP in base al piano di indirizzamento, e ve lo comunicherà.

2. Creare un file di configurazione come segue, in cui scrivere opportunamente la vostra chiave privata e l'indirizzo IP assegnato. Prestare particolare attenzione a modificare i campi della sezione Interface, come indicato nelle note.

[Interface]
# PrivateKey = YoUrGoRgEoUsAnDsEcUrEpRiVaTeKeY=               # vedi note, scegliere questo...
# PostUp = wg set %i private-key ./client.example.com.privkey # vedi note,                 ...oppure questo
Address = 2001:470:c844:100::200/64                           # vedi note

# vpn.golem.linux.it
[Peer]
PublicKey = w63aGvoyPaUTgA8nW/NJS6Qqp2hUFvHRBbIH8Qb5ISY=   
AllowedIPs = 2000::/3                                      
Endpoint = vpn.golem.linux.it:51280
PersistentKeepalive = 37

Note

  • Interface (sezione di configurazione dell'endpoint locale)
    • scegliere una delle seguenti opzioni per indicare la chiave privata del client, scommentando la riga apposita.
      • PrivateKey: chiave privata del client, da custodire con cura, inline
      • PostUp = command: chiave privata del client, da custodire con cura, e caricata automaticamente da un file esterno (es. creato col comando mostrato in precedenza)
    • Address: indirizzo IP comunicato dal sysop: riportarlo accuratamente, altrimenti non sarà possibile utilizzare la VPN
  • [Peer] (sezione di configurazione dell'endpoint remoto / server)
    • PublicKey: chiave pubblica del server (sì, è proprio quella)
    • AllowedIPs: indirizzi raggiungibili tramite la VPN, a scelta:
    • Endpoint: indirizzo del server
    • PersistentKeepalive: timer per mantenimento del tunnel attivo (in secondi); particolarmente utile se l'indirizzo IP del client cambia o è soggetto a NAT

La connessione può essere attivata tramite systemd come sul server (spostandola in /etc/wireguard/), oppure manualmente utilizzando wg-quick:

  • Attivazione del tunnel
wg-quick up client.example.conf
  • Disattivazione del tunnel
wg-quick down client.example.conf

3. Provare il collegamento

# ping 2001:470:c844:100::1    # server VPN, dentro al tunnel (per verificare se il collegamento funziona)
# ping 2001:470:c844:100::200  # gateway in Officina (per verificare se il collegamento funziona; talvolta non raggiungibile se abbiamo staccato la luce)
# ping ipv6.google.com         # per verificare l'accessibilità dell'Internet pubblico IPv6, nel caso non si abbia già accesso

4. Successo!

  • 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. È comunque consigliato leggere la sezione relativa al firewall per ragioni di sicurezza ed eventualmente attivarlo.
  • Se invece il client è il gateway della rete IPv6 (es. serverozzo, o il router di casa di uno dei soci che vuole navigare in IPv6), allora bisogna configurarlo come indicato nella sezione apposita.

Client VPN come gateway

Impostare il client VPN 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).

Installare radvd:

# apt install radvd

Configurare il file /etc/radvd.conf:

interface ethI {
        AdvSendAdvert on;
        MinRtrAdvInterval 2;
        MaxRtrAdvInterval 10;
        prefix 2001:db8::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
        RDNSS 2606:4700:4700::1111 {
                AdvRDNSSLifetime 3600;
        };
};

dove

  • interface br0 indica l'interfaccia interna su cui fare advertise;
  • prefix 2001:db8::/64 indica la rete a valle;
  • RDNSS 2606:4700:4700::1111 indica il server DNS (nell'esempio specifico, CloudFlare);
    • Nota: in seguito a questioni legali, OpenDNS non è al momento disponibile in Francia.

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 i client

Gli indirizzi IPv6 sono "tutti" pubblici. Gli indirizzi IPv6 forniti dal GOLEM sono pubblicamente instradabili. In più, il GOLEM non mette in atto nessuna misura atta a prevenire connessioni dirette verso gli host della VPN (al netto di configurazioni specifiche sulle macchine direttamente di proprietà del GOLEM). Ciò significa che tutti gli host degli utenti/soci, compresi quelli domestici che sin'ora sono stati dietro a un (s)comodo NAT, possono essere acceduti attraverso la rete Internet globale, quando sono connessi alla VPN del GOLEM.

Pertanto, è consigliato attivare degli strumenti atti a prevenire accessi indesiderati dall'esterno, come un firewall, in special modo se il proprio computer "fornisce servizi" (eg. condivisione di file via rete, server web di sviluppo, ...)

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


Direttamente sull'host

Si può agire direttamente sugli host da proteggere (versione conservativa):

# ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# ip6tables -A INPUT -p icmpv6 -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. Si noti che ICMPv6 deve comunque sempre essere abilitato in quanto necessario al funzionamento di IPv6.

Si può anche utilizzare una regola più rilassata (es. per sfruttare la VPN del GOLEM come VPN "personale" tra i propri host), tipo:

# ip6tables -A INPUT -s 2001:470:c844:uu00::/56 -j ACCEPT

Golem-template-note-info.png I pacchetti della VPN viaggiano crittografati sulla rete pubblica (almeno finché si trovano all'interno della VPN del GOLEM), ma sul server vengono decifrati e cifrati di nuovo per permetterne il routing! In caso di compromissione del VPS del GOLEM, pertanto, i pacchetti non possono essere considerati al sicuro da sguardi indiscreti. È sempre buona norma utilizzare crittografia end-to-end, anche all'interno di una VPN.


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!


Risoluzione problemi

Geolocalizzazione

Il tunnel è localizzato in Francia. A causa di restrizioni imposte a causa del diritto d'autore, alcuni siti, specialmente di streaming video, come Netflix, Rai.tv o Youtube, potrebbero bloccare l'accesso ai contenuti italiani dal tunnel francese. Per inibire temporaneamente l'uso del tunnel IPv6 su un host:

# sysctl -w net.ipv6.conf.all.disable_ipv6=1