Come diventare raggiungibili da internet su rete fastweb con il protocollo IPv6

Molti di quelli che si connettono su rete Fastweb lo fanno ancora attraverso un Natting di rete; l’indirizzo IP con cui ci si presenta su internet è quindi condiviso con molti altri utenti.

Questo tipo di configurazione è perfettamente funzionale ad una normale navigazione su internet e in una certa misura migliora la sicurezza del nostro pc perché non ci espone direttamente dall’esterno.

Come contropartita però è un problema da aggirare se si vogliono implementare dei servizi di tipo server (un server web ad esempio) o per l’utilizzo di alcuni programmi (in genere giochi, sistemi peer-to-peer o altro) che, assegnando un ruolo paritario alle macchine coinvolte e richiedono ad ognuna alternativamente di assumere sia il ruolo del server sia quello del client.

Cercando su google idee su come gestire questo problema su una connessione fastweb ho trovato riferimenti sostanzialmente a tre tipi di indicazioni:

  • si ha già un IP dedicato ma bisogna configurare il portforwarding sul proprio router
  • molti dicono (ma io non ho provato e quindi mi limito a riportare quanto letto altrove) che in genere, insistendo con il supporto, si riesce a farsi assegnare un IP, non mi è chiaro se gratuitamente o meno.
  • se si è su rete nattata non c’è modo di aggirare il problema.

In realtà è comunque possibile sfruttare il protocollo IPv6 per gestire questo problema. Data la natura di questo protocollo infatti ogni IPv6 è un identificatore univoco di un apparato dulla rete.

Lo si può abilitare ad esempio come ho descritto in “primi passi in IPv6.

Primi passi in IPv6

Questo articolo lo sto scrivendo connesso all’IP

2001:41d0:1:1b00:94:23.64:3

. Quello che si ottiene con un

dig -t AAAA linuxandcompany.it

Non è mica poco!

Alla fine cercando in rete ho trovato che da rete Fastweb è piuttosto semplice, anche se le informazioni è stato necessario metterle insieme da più fonti.

Prima di tutto l’IPv6 non è nativo ma la rete fastweb, come riportato qui, contiene il server

tsp.ipv6.fastweb.it

che permette di fare un tunnel verso la rete IPv6.

Per usare questo client si piò utilizzare il client gogoc sviluppato in gogo6. Da sito si scaricano solo i sorgenti e almeno sulla mia versione di ubuntu la compilazione non va a buon fine ma ho scoperto che il client è tra i pacchetti di ubunto e si chiama gogoc; basta quindi un

aptitude install gogoc

L’ultimo step è inserire qualche dato in

/etc/gogoc/gogoc.conf

ovvero

server=tsp.ipv6.fastweb.it
auth_method=anonymous

Dopo di che

/etc/init.d/gogoc start
/etc/init.d/gogoc status
ip add sh

saranno sufficienti per attivare il tunnel IPv6 e per verificarne lo stato.

Potremo poi verificare l’avvenuta attivazione dai siti

http://test.ipv6.fastweb.it/
http://www.ipv6.fastweb.it/

Se si ha poi un qualche tool che visualizza l’IP del sito che si sta visualizzando sul browser, e si naviga dopo averlo riavviato, si cominceranno a vedere molti accessi su questo protocollo di trasporto, che ha priorità più alta. Dovreste vederlo su linuxandcompany.it ma anche su qualche sito minore come www.google.com.

djbdns dns server: dnscache

Il mondo dei server DNS è sicuramente dominato da bind in ambito linux ma esistono altri prodotti interessanti soprattutto se la necessità non è quella di dare il servizio DNS su internet.

Trovo particolarmente interessante djbdns. Questo daemon è stato sviluppato da D.J. Bernstein, autore, tra l’altro, anche di qmail. La caratteristica più interessante di djbdns è quella di separare in tre daemon differenti tre funzionalità differenti generalmente unificate sotto un’unico daemon:

  • caching DNS: dnscache
  • authoriting delle zone: tinydns
  • trasferimento di zone: axfrdns and axfr-get

Di questi il più utile secondo me è dnscache che, essendo un sistema estremamente leggero è ideale per essere istallato e ridurre il carico di lavoro di tutti quei server che hanno la necessità di gestire un elevato numero di connessioni che giungono da svariati IP.

Djbdns richiede due software: daemontools e ucspi-tcp. Questi li istalliamo da pacchetto.

aptitude install daemontools
aptitude install ucspi-tcp

djbdns non è però presente sulla distribuzione debian. Scarichiamo quindi i sorgenti. La compilazione richiede i pacchetti make, gcc

 wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
tar -zxvf djbdns-1.05.tar.gz
cd djbdns-1.05
echo gcc -O2 -include /usr/include/errno.h > conf-cc
make
make setup check

L’autore richiede poi di segnalare l’avvenuta istallazione con

( echo 'First M. Last'; cat `cat SYSDEPS` ) \
| mail djb-sysdeps@cr.yp.to

Passiamo ora alla configurazione del servizio. Come sempre non è il caos di di far girare dei daemon come root; aggiungiamo quindi due utenti al sistema inserendo nel file */etc/passwd*

dnscache:x:999:999::/dev/null:/usr/sbin/nologin
dnslog:x:998:999::/dev/null:/usr/sbin/nologin

e al file /etc/group

dnscache:x:999:

Prepariamo la configurazione di base

dnscache-conf dnscache dnslog /etc/dnscache 127.0.0.1

Con questo comando abbiamo generato la configurazione in /etc/dnscache specificando che l’utente che dovrà eseguire il daemon sarà dnscache, che i log saranno gestiti dall’utente dnslog e che il daemone sarà in ascolto sull’IP 127.0.0.1.

La directory creata conterrà 5 sottodirectory: env, log, root, run e seed. In particolare env e root contengono le configurazioni vere e proprie e log i log. Vedremo qualche dettaglio in seguito.

Occupiamoci ora dell’avvio del sistema. Vogliamo sfrutatre i daemontools e per farlo dovremo far si che svscanboot venga avviato all’avvio del sistema attraverso i meccanismi della distribuzione che stiamo utilizzando. Per le finalità di questo tutorial ci accontentiamo di lanciarlo a mano:

mkdir /etc/service/
cd /tmp/
nohup svcscanboot &

Il sistema dei daemontools si aspetta una directory in /etc/service per ogni servizio da gestire e monitorare. Aggiungiamo quindi la nostra cache dns

ln -s /etc/dnscache /etc/service/dnscache

Dopo qualche secondo il daemon sarà avviato

svstat /etc/service/dnscache/

ci restituirà il tempo di esecuzione e il PID del demone.

Interessanti un paio di *ps*

root@debian:/tmp# ps aux|grep sv
root      7605  0.0  0.0   4180   580 pts/0    S    22:24   0:00 /bin/sh /usr/bin/svscanboot
root      7607  0.0  0.0   4120   460 pts/0    S    22:24   0:00 svscan /etc/service
root@debian:/tmp# ps aux|grep dns
root      7609  0.0  0.0   3948   316 pts/0    S    22:24   0:00 supervise dnscache
dnslog    7611  0.0  0.0   4092   468 pts/0    S    22:24   0:00 multilog t ./main
dnscache  7612  0.0  0.1   5484  1492 pts/0    S    22:24   0:00 /usr/local/bin/dnscache

che mostrano tutti i processi coinvolti. Notare che la gestione dei log è fatta attraverso un daemon separato e infatti si troverà all’interno della directory log in /etc/dnscache una directory *service* esattamente come in */etc/dnscache*.

Per fermare e riavviare dnscahe si può ricorrere a

svc -d /etc/service/dnscache
svc -u /etc/service/dnscache

o anche a un più brutale kill del daemon dnscache: ci penseranno i daemontools a riavviarlo.

Per meglio gestire le zone interne o se si vuole sfruttare qualche dns interno si consideri che in /etc/dnscache/root/servers si possono aggiungere file, denominati come un dominio e contenenti una lista di DNS interrogabili per quel dominio. Ad esempio con:

cd /etc/dnscache/root/servers
echo 213.251.188.150 > linuxandcompany.it
echo 213.251.128.150 > linuxandcompany.it
svc -d /etc/service/dnscache
svc -u /etc/service/dnscache

posso dire alla cache dove di preferenza deve rivolgersi per le risoluzioni del dominio di questo sito.

Questa directory contiene di base un file denominato @ in cui è contenuta la lista dei root dns di internet.