Tunneling IPv6 di HE con Linux CentOS


Nota aggiunta il 30/9/2013: a questa soluzione è da preferire quella descritta in un articolo successivo con pfSense e KVM.

(alcune parti sono state modificate dopo la pubblicazione)

Questo articolo spiega come impostare un tunnel IPv6 con Linux CentOS 5 configurato come gateway, NAT e firewall di una LAN.

Lo scenario è il seguente: un router ADSL con IPv4 pubblico collegato ad un Linux che fa da NAT/firewall per la LAN. In questo esempio eth0 è l’interfaccia WAN con un IPv4 pubblico /29 e eth1 è l’interfaccia LAN con un IPv4 /24.

Alla fine della procedura la classe /64 di IPv6 pubblici con reverse DNS potrà essere utilizzata per assegnare indirizzi pubblici ai dispositivi IPv6 in LAN, incluso il gateway Linux.

Innanzi tutto bisogna abilitare IPv6 su CentOS senza assegnare, per ora, indirizzi alle interfacce. È però necessario aggiungere questa riga al file /etc/sysconfig/network per abilitare il routing IPv6 dalla LAN al tunnel:

IPV6FORWARDING=yes

Fatto questo, bisogna attivare su TunnelBroker un tunnel IPv6 gratuito. Se il firewall sul Linux blocca i ping, bisogna abilitarli almeno sull’interfaccia pubblica perché la raggiungibilità ICMP dell’endpoint locale è condizione necessaria per l’attivazione del tunnel. Diversamente dall’esperienza di Fabrizio (che mi ha aiutato a mettere a punto alcune parti della configurazione presentata di seguito), nel mio caso l’endpoint più veloce è quello britannico. Il fornitore mi assegna un IPv6 per il tunneling (IPv6 Tunnel Endpoints) e una classe da assegnare agli indirizzi locali (Routed IPv6 Prefixes), che sarà la classe pubblica da utilizzare.

HE fornisce degli script di net-tools di esempio, ma non funzionano correttamente se si vuole assegnare un IPv6 pubblico al server Linux. Se si configura l’indirizzo IPv6 di tunneling sull’interfaccia sit1, le connessioni IPv6 originate dal Linux uscirebbero con l’IPv6 del tunnel e non con un IPv6 della classe assegnata da HE.

Dal momento che il server Linux deve avviare correttamente i servizi al boot senza intervento umano, bisogna predisporre uno script di avvio che attivi il tunnel IPv6 appena dopo l’avvio della rete, ma prima che partano i demoni che usano IPv6. Diversamente, un programma potrebbe tentare di fare binding ad un indirizzo che non esiste e non avviarsi correttamente. Per fare questo si crea un file /etc/init.d/ipv6tunnel (o un altro nome a scelta) con questo contenuto:

#!/bin/bash
#
# ipv6tunnel      This shell script takes care of starting and stopping
#                 IPv6 tunnel with HE
#
# chkconfig: - 12 88
# description: HE supplies free IPv6 tunnel
# probe: true

# Source function library.
. /etc/rc.d/init.d/functions

#RETVAL=0

start() {

        echo "Starting IPv6 tunnel "
	ifconfig sit0 up
	# nella riga successiva sostituire 216.66.80.26 
	# con l'IP dell'endpoint scelto
	ifconfig sit0 inet6 tunnel ::216.66.80.26
	ifconfig sit1 up
	route -A inet6 add ::/0 dev sit1
	echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
	return 0
}
stop() {
	# Stop daemons.
	echo "Stopping IPv6 tunnel "
	ifconfig sit1 down
	ifconfig sit0 down
	return 0
}
restart() {
	stop
	sleep 1
	start
}	

# See how we were called.
case "$1" in
	start)
		start
		;;
	stop)
		stop
		;;
	restart)
		restart
		;;
	*)
        	echo $"Usage: $0 {start|stop|restart}"
		exit 2
esac

exit $?

Si può attivare lo script all’avvio con gli appositi comandi:

chkconfig --add ipv6tunnel
chkconfig --level 35 ipv6tunnel on

Bisogna, quindi, assegnare un IPv6 pubblico della classe Routed IPv6 Prefixes alla scheda di rete della LAN aggiungendo queste righe a /etc/sysconfig/network-scripts/ifcfg-eth1:

IPV6INIT=yes
IPV6ADDR=2001:470:1f09:203::dead:beef

Nella situazione in cui è stata testata questa procedura, l’IPv6 qui sopra è quello che viene usato per le connessioni esterne. Vale sempre la pena di fare un po’ di test perché ci sono molte variabili in gioco e l’IPv6 in CentOS 5 ogni tanto è goffo o erratico come un fulminatore.

A questo punto si può riavviare il Linux per verificare se il tunnel viene aperto nel momento giusto e per vedere se il tutto funziona. Se tutto è configurato correttamente, il comando

ping6 ipv6.google.com

eseguito sul Linux dovrebbe funzionare come ci si aspetta: ipv6.google.com è un host che ha solamente un indirizzo IPv6 e non IPv4.

Il passo successivo è predisporre la configurazione automatica degli host IPv6 della LAN. A questo scopo si installa radvd con il comando

yum install radvd

Quindi si modifica /etc/radvd.conf in questo modo:

interface eth1
{
	AdvSendAdvert on;
	MinRtrAdvInterval 200;
	MaxRtrAdvInterval 600;
	prefix 2001:470:1f09:203::/64
	{
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr off;
	};
};

dove prefix è la classe indicata sotto Routed IPv6 Prefixes. Il demone si avvia con service radvd start. Le macchine Linux e Windows (incluse le VM con la rete in bridge) che hanno attivo il protocollo IPv6 e la configurazione automatica dell’indirizzo dovrebbero acquisire automaticamente un IPv6.

Per eseguire un test con il browser si può visitare test-ipv6.com, che dovrebbe restituire un punteggio di 10/10, oppure ipv6test.google.com, o anche ipv6-test.com oppure ipv6eyechart.ripe.net per eseguire tanti test contemporaneamente. Ci sono, comunque, moltissimi siti che eseguono test IPv6.

Un ultimo passo, facoltativo, è la creazione di un reverse DNS sugli IP assegnati da HE. Per fare questo bisogna prima delegare he.net per la gestione del reverse nella stessa schermata in cui sono elencati gli IPv6 assegnati, poi andare su dns.he.net e collegarsi con il proprio account di HE. Qui il proprio blocco risulterà incomplete perché la zona è ancora vuota. Per popolarla cliccare sull’icona a sinistra della zona e specificare indirizzo e nome dell’host. Le modifiche sono attive immediatamente.

Vale sempre la pena di ricordare che gli IPv6 sono pubblici, quindi accessibili da chiunque abbia IPv6. La protezione del firewall IPv4 non si applica ad IPv6, per il quale vanno create e manutenute regole ad hoc. Ma questo è un argomento per un altro articolo.

Un ultimo consiglio: se fate delle prove a botte di configurazione e sconfigurazione di interfacce può succedere che ci si incasini, sia per quanto riguarda il Linux che fa da firewall/gateway sia per i client. Il consiglio è di fare poche modifiche per volta e ogni tanto di verificare la configurazione spegnendo e riaccendendo tutto.

Il tunneling è un buon sistema per impratichirsi dell’IPv6, fermo restando il fatto che la situazione migliore si avrà quando ci saranno ISP che daranno il blocco IPv6 disponibile sul router esattamente come i blocchi IPv4.


11 risposte a “Tunneling IPv6 di HE con Linux CentOS”

  1. Ottimo continuiamo così!
    Dopo questa serie di articoli nessuno ha più scuse per non usare IPV6 se non la pigrizia 🙂

    Allora questo “altro” articolo sulla sicurezza chi lo scrive?

    Io ne farei uno per aggiungere la configurazione del DNS e dei reverse alla LINUX box di cui sopra visto che l’hardware ce l’abbiamo già messo tanto vale sfruttarlo appieno.

    Anche se HE offre il servizio a scopo didattico non è male smanettarci per capire bene come funziona. Appena ho un attimo di tempo….

    P.S. visto che in questi casi 2 è meglio di uno invece di b16:b00b avrei utilizzato b1gb:00b5 come quartetti finali per l’indirizzo di sit1

    • Per la sicurezza prima voglio impratichirmi un po’ io.

      Se vuoi cimentarti con BIND, fai pure 🙂

      per l’indirizzo, …b16b:00bs e’ stato il primissimo IPv6 pubblico che ho usato. Il problema e’ che gli zeri vengono troncati, quindi nei log e nella messaggistica l’IP risulterebbe 2001:470:1f09:203::b16b:b5

  2. Attento agli intervals, quelli sono troppo bassi. Significa che mandi in scadenza i renew degli annunci SLAAC ogni 10 secondi. Questo può provocare su molti client e su una moltitudine di sistemi operativi un vero e proprio flap dello stack tcp/ip. Può succedere di tutto, alcuni kernel (sopratutto windows), abbattono la connessione di rete e rinegoziano v4/v6. Questo provoca che se hai connessioni aperte, tutto viene abbattuto. Bellissimo…;)

      • in soldoni SLAAC sul router (nel tuo caso radvd) annuncia le reti ogni Min/MaxRtrAdvInterval in secondi, se non configuri il lifetime (nella tua conf non c’è), il default è 3*Interval (da man). L’AdvInterval è il tempo ogni quanto il router advertisa in broadcast le reti ai client. Il lifetime è l’equivalente del lease time di DHCP in v4. Dopo il lifetime il client sega la rete learnata dall’interfaccia se non ha ricevuto nel frattempo degli advertisement.

        • Capito, grazie!

          In pratica i client anziche’ pollare il DHCPv4 ogni tot per confermare la lease, ascoltano i bcast del router/radvd, corretto?

  3. Pero’ e’ bello vedere nella pagina amministrativa di WordPress gli IPv6 al posto degli IPv4 degli host di alcune persone che fanno i commenti. 🙂 🙂 🙂
    (basta cosi’ poco a far contento un geek…)

  4. […] regole di routing e di accesso completamente diverse. Piazzare una macchina Linux con radvd e un tunnel IPv6 con 2^64 indirizzi pubblici è più semplice di quello che sembra; una volta attivato il gateway, […]

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *