L'autore di questa sezione (Opzioni di configurazione del kernel) è Hubert Feyrer <hubert@feyrer.de>.
Prima di addentrarci nei meandri delle configurazioni di rete, è bene dare un'occhiata ai relativi parametri presenti nella configurazione del kernel. Per ulteriori dettagli sull'argomento si veda Capitolo 7; qui ci concentreremo solo sugli aspetti relativi al networking, prendendo il file di configurazione i386/GENERIC a titolo di esempio. I file di configurazione per le altre piattaforme contengono opzioni simili, generlmente accompagnate da commenti che ne chiariscono l'uso all'interno dei file stessi. Inoltre, le opzioni di compilazione del kernel sono documentate nella pagina di manuale options(4) e solitamente c'è una pagina di manuale per ogni driver (per esempio tlp(4)).
# $NetBSD: GENERIC,v 1.354.2.15 2001/05/06 15:18:54 he Exp $
La prima linea del file di configurazione mostra il numero di versione che, in questo caso, è 1.354.2.15 e che può essere utile per confrontare con altre versioni via CVS o per riportare eventuali bug.
options NTP # NTP phase/frequency locked loop
Se si vuole usare il Network Time Protocol (NTP), si può attivare questa opzione per ottenere la massima precisione. Se quest'opzione non è attiva, NTP funziona ugualmente. Vedere ntpd(8) per ulteriori dettagli.
file-system NFS # Network File System client
Per utilizzare il disco fisso di un'altra macchina con il Network File System (NFS), è necessario attivare quest'opzione. Vedere la Sezione 10.2.2 per ulteriori informazioni.
options NFSSERVER # Network File System server
Quest'opzione comprende il lato server del protocollo NFS e deve essere abilitata per consentire ad altre macchine di usare il disco fisso locale. Vedere la Sezione 10.2.2 per ulteriori informazioni.
#options GATEWAY # packet forwarding
Per impostare un router che inoltra i pacchetti tra più reti o più interfacce di rete, bisogna abilitare l'opzione GATEWAY. Non solo attiva l'inoltro dei pacchetti ma aumenta anche alcuni buffer. Vedere options(4) per ulteriori dettagli.
options INET # IP + ICMP + TCP + UDP
Attiva il supporto al TCP/IP nel kernel. Anche se non si intende usare il networking, quest'opzione è comunque necessaria per le comunicazioni interne alla macchina di sottosistemi quali X Window. Vedere inet(4) per i dettagli.
options INET6 # IPV6
Chi vuole usare IPv6 deve attivare quest'opzione, che è stata introdotta già con la release 1.5 di NetBSD. Chi non vuole IPv6 può commentarla. Vedere la pagina di manuale inet6(4) e la Sezione 9.1.7 per ulteriori informazioni sul protocollo Internet di nuova generazione.
#options IPSEC # IP security
Include il supporto per il protocollo IPsec: autenticazione, compressione, chiavi, ecc. Quest'opzione si può utilizzare anche senza attivare IPv6 se si desidera usare IPsec solo con IPv4, il che è possibile. Vedere ipsec(4).
#options IPSEC_ESP # IP security (encryption part; define w/IPSEC)
Quest'opzione si utilizza in aggiunta a IPSEC per attivare la crittografia IPsec.
#options MROUTING # IP multicast routing
Includere quest'opzione per attivare il routing di servizi multicast quali MBone. Si noti che il routing è poi controllato dal demone mrouted(8).
options NS # XNS #options NSIP # XNS tunneling over IP
Queste opzioni abilitano la famiglia di protocolli Xerox Network Systems(tm). Non sono in relazione con lo stack del protocollo TCP/IP e non sono molto utilizzate oggi. La pagina di manuale ns(4) contiene alcuni dettagli.
options ISO,TPIP # OSI #options EON # OSI tunneling over IP
Queste opzioni attivano lo stack del protocollo OSI che, dopo essere stato a lungo reputato il futuro del networking, oggi ha un interesse prevalentemente storico. Vedere la pagina di manuale iso(4).
options CCITT,LLC,HDLC # X.25
Queste opzioni attivano il set di protocolli X.25 pre la trasmissione di dati su linea seriale. È, o meglio era, usata insieme ai protocolli OSI o nel networking WAN.
options NETATALK # AppleTalk networking protocols
Include il supporto per lo stack del protocollo AppleTalk. Per poterlo usare sono necessari i programmi server che si possono trovare, per esempio, in pkgsrc/net/netatalk e pkgsrc/net/netatalk-asun. Ulteriori informazioni sul protocollo AppleTalk e sul relativo stack si possono trvare nella pagina di manuale atalk(4).
options PPP_BSDCOMP # BSD-Compress compression support for PPP options PPP_DEFLATE # Deflate compression support for PPP options PPP_FILTER # Active filter support for PPP (requires bpf)
Queste opzioni controllano vari aspetti del protocollo PPP (Point-to-Point Protocol). Le prime due determinano gli algoritmi di compressione usati/disponibili, mentre la terza abilita il codice per il filtraggio di alcuni pacchetti.
options PFIL_HOOKS # pfil(9) packet filter hooks options IPFILTER_LOG # ipmon(8) log support
Queste opzioni abilitano il firewalling usando IPfilter. Vedere le pagine di manuale ipf(4) e ipf (8) per ulteriori informazioni sull'uso di IPfilter, nonché la Sezione 10.2.1 per un esempio di configurazione.
# Compatibility with 4.2BSD implementation of TCP/IP. Not recommended. #options TCP_COMPAT_42
Quest'opzione è necessaria solo se sulla rete sono ancora presenti macchine che usano 4.2BSD o uno stack di rete derivato da questa versione. In presenza di macchine 4.2BSD bisogna fare attenzione alla corretta impostazione dell'indirizzo di broadcast, poiché 4.2BSD ha un bug nel codice di networking relativamente all'indirizzo di broadcast. Questo bug costringe a mettere tutti i bit di host a "0" nell'indirizzo di broadcast. L'opzione TCP_COMPAT_42 serve a questo.
options NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM
Queste opzioni abilitano la ricerca di informazioni con DHCP o con il protocollo BOOTPARAM quando il kernel usa un filesystem "root" di tipo NFS. Vedere la pagina di manuale diskless(8) per ulteriori informazioni.
# Kernel root file system and dump configuration. config netbsd root on ? type ? #config netbsd root on sd0a type ffs #config netbsd root on ? type nfs
Queste linee indicano al kernel dove cercare il proprio filesystem "root" e di quale tipo di filesystem si tratti. Se, per esempio, si vuole creare un kernel che usa un filesystem root di tipo NFS tramite l'interfaccia tlp0, lo si può fare con la direttiva "root on tlp0 type nfs". Se si usa ? al posto del tipo di dispositivo, il kernel cerca di determinare il dispositivo autonomamente.
# ISA serial interfaces com0 at isa? port 0x3f8 irq 4 # Standard PC serial ports com1 at isa? port 0x2f8 irq 3 com2 at isa? port 0x3e8 irq 5
Per usare PPP o SLIP è necessario avere un'interfaccia seriale (com). Va bene anche una che si attacchi a USB, PCMCIA o PUC.
# Network Interfaces
La lista delle interfacce di rete è piuttosto lunga e contiene dispositivi di ogni tipo; bisogna semplicemente selezionare quello che corrisponde al proprio hardware, basandosi sui commenti presenti nel file. La maggior parte dei driver ha una propria pagina di manuale; per esempio tlp(4), ne(4), ecc.
# MII/PHY support
Questa sezione elenca le interfacce di rete indipendenti dal dispositivo. In caso di dubbio, abilitarle tutte e lasciare la scelta al kernel. Vedere la pagina di manuale mii(4) per ulteriori informazioni.
# USB Ethernet adapters aue* at uhub? port ? # ADMtek AN986 Pegasus based adapters cue* at uhub? port ? # CATC USB-EL1201A based adapters kue* at uhub? port ? # Kawasaki LSI KL5KUSB101B based adapters
Gli adattatori ethernet USD hanno una banda limitata a soli 2 MBit/s ma sono molto pratici da usare. Naturalmente, per funzionare, bisogna configurare anche le opzioni per USB, che però non sono descritte in questa sede, oltre, naturalmente, a disporre dell'hardware necessario. Si vedano le varie pagine di manuale.
# network pseudo-devices pseudo-device bpfilter 8 # Berkeley packet filter
Questo pseudo-dispositivo consente lo "sniffing" di pacchetti di tutti i tipi. È necessario per tcpdump ma anche per rarpd e per altre applicazioni che devono esaminare il traffico di rete. Vedere bpf(4) per ulteriori informazioni.
pseudo-device ipfilter # IP filter (firewall) and NAT
Questa riga attiva l'interfaccia IPfilter del kernel per il filtraggio dei pacchetti usata per il firewalling, NAT (detto anche IP masquerading), ecc. Vedere ipf(4) e la Sezione 10.2.1 per ulteriori informazioni.
pseudo-device loop # network loopback
Questa è l'interfaccia "loopback" di rete, usata sia da alcuni programmi sia per effettuare alcuni tipi di routing. Deve essere abilitata. Vedere la pagina di manuale lo(4) per i dettagli.
pseudo-device ppp 2 # Point-to-Point Protocol
Quest'opzione è necessaria per poter usare il protocollo PPP, sia via interfaccia seriale sia via ethernet (PPPoE). Vedere ppp(4).
pseudo-device sl 2 # Serial Line IP
Il "Serial Line IP" è semplicemente il protocollo IP incapsulato per viaggiare su linea seriale. Poiché non include opzioni quali la negoziazione degli indirizzi IP, oggi non è più molto usato. Si veda sl(4).
pseudo-device strip 2 # Starmode Radio IP (Metricom)
Vedere la pagina di manuale strip(4) per il supporto ai vecchi dispositivi di rete Metricon Ricochet. Se ne avete uno, abilitate quest'opzione.
pseudo-device tun 2 # network tunneling over tty
Questo dispositivo di rete serve per predisporre un tunnel per i pacchetti di rete verso un dispositivo /dev/tun*. I pacchetti inoltrati all'interfaccia tun0 si possono leggere in /dev/tun0, e i dati scritti su /dev/tun0 vengono inviati all'interfaccia di rete tun0. Con questo sistema si può implementare, per esempio, l'instradamento QoS in modalità utente. Vedere tun(4) per ulteriori dettagli.
pseudo-device gre 2 # generic L3 over IP tunnel
L'incapsulamento GRE si può usare per effettuare un tunnel di pacchetti arbitari di livello 3 su IP, per esempio per l'implementazione di VPN. Vedere gre(4) per ulteriori dettagli.
pseudo-device ipip 2 # IP Encapsulation within IP (RFC 2003)
Un altro dispositivo per icapsulare IP su IP, con un diverso formato di incapsulamento. Vedere la pagina di manuale ipip(4) per i dettagli.
pseudo-device gif 4 # IPv[46] over IPv[46] tunnel (RFC 1933)
L'interfaccia GIF serve per attivare un tunnel, per esempio di IPv6 su IPv4, che può essere usato per ottenere connettività IPv6 in assenza di una connessione IPv6 con l'ISP. Sono possibili anche altre combinazioni di operazioni: vedere gli esempi contenuti nella pagina di manuale gif(4).
#pseudo-device faith 1 # IPv[46] tcp relay translation i/f
L'interfaccia faith cattura il traffico TCP IPv6, per implementare relay da IPv6 IPv4, per esempio per transizioni di protocollo. Vedere la pagina di manuale faith(4).
#pseudo-device stf 1 # 6to4 IPv6 over IPv4 encapsulation
Questa direttiva aggiunge un dispositivo di rete che si può usare per creare un tunnel IPv6 su IPv4 senza bisogno di configurare il tunnel stesso. Il mittente dei pacchetti in uscita contiene l'indirizzo IPv4, il che consente di inviare le risposte via IPv4. Vedere la pagina di manuale stf(4) e la Sezione 10.2.4 per ulteriori dettagli.
pseudo-device vlan # IEEE 802.1q encapsulation
Questa interfaccia fornisce il supporto per le LAN virtuali IEEE 802.1Q, consentendo di marcare i pacchetti ethernet con un ID "vlan". Configurando opportunamente degli switch che supportano le VLAN, si possono creare delle VLAN nelle quali un gruppo di macchine non vede il traffico degli altri gruppi. La pagina di manuale vlan(4) contiene ulteriori informazioni in proposito.
La lista seguente contiene un elenco dei file di configurazione della rete, alcuni dei quali già visti nei capitoli precedenti. La descrizione di questi file sarà ò l'oggetto delle prossime sezioni.
Il database degli host locali. Ogni linea descrive un host e contiene l'indirizzo IP, il nome dell'host e gli eventuali alias. Le reti di modeste dimensioni possono essere configurate usando solo il file degli host, senza bisogno di un name server.
Questo file specifica le modalità operative per le funzioni di libreria dell'Internet Domain Name System. Generalmente contiene gli indirizzi dei "name server".
Questo file viene usato per la configurazione automatica della scheda di rete all'avvio.
Contiene l'indirizzo IP del gateway.
File di configurazione del Name Service Switch; controlla le modalità di accesso ai vari database contenenti le informazioni su host, utenti, gruppi, ecc. In pratica, questo file specifica l'ordine in base al quale vengono consultati i database. Per esempio, la linea:
hosts: files dnsspecifica che le informazioni sugli host vengono da due fonti, il file locale /etc/hosts) e il DNS (Internet Domain Name System), e che i file locali vengono consultati prima del DNS.
Solitamente non è necessario modificare questo file.
Vi sono molti tipi di collegamento a Internet: questa sezione spiega come collegarsi a un provider usando un modem via linea telefonica con il protocollo PPP, uno dei setup più comuni. Le operazioni da compiere sono, nell'ordine:
Richiedere le informazioni necessarie al provider.
Editare il /etc/resolv.conf e controllare il file /etc/nsswitch.conf.
Creare le directory /etc/ppp e /etc/ppp/peers se non esistono.
Creare lo script di connessione, il chat file e il file di opzioni pppd.
Creare il file di autenticazione utente-password.
A giudicare dalla lista precedente sembra una procedura complessa che richiede molto lavoro. In realtà, ognuno dei punti elencati è molto semplice: si tratta soltanto di creare, modificare o semplicemente controllare alcuni piccoli file di testo. Nell'esempio seguente supporremo che il modem sia collegato alla seconda porta seriale /dev/tty01 (COM2 in DOS.)
La prima cosa da fare è chiedere al provider, che supponiamo si chiami BigNet, di fornirci i dati che servono per potersi collegare; in particolare:
Il numero di telefono del POP (Point Of Presence) più vicino.
Il tipo di autenticazione da utilizzare.
Il nome utente e la nostra password da utilizzare per il collegamento.
Gli indirizzi IP dei nameserver.
Il file /etc/resolv.conf deve essere configurato utilizzando alcune informazioni fornite dal provider, in particolare i DNS. Supponiamo che i due DNS siano "194.109.123.2" e "191.200.4.52".
Nota: la riga "lookup file bind" indica che i name server vengono utilizzati solo per le voci non presenti in /etc/hosts. La riga è commentata perché, a partire dalla versione 1.4 di NetBSD, non viene più utilizzata: le sue funzioni sono ora svolte dal file /etc/nsswitch.conf. Il nuovo Name Service Switch consente di cambiare i metodi di accesso ai database usati dai programmi per accedere alle informazioni base del sistema.
Nota: l'unica riga modificata in questo file è quella che inizia con "hosts:". Si noti nelle versioni successive alla 1.4.1 non dovrebbe più essere necessario effettuare questa modifica a mano.
Le directory /etc/ppp e /etc/ppp/peers dovranno contenere i file di configurazione per il collegamento; al termine di una nuova installazione di NetBSD non esistono, e quindi bisogna crearle (chmod 700).
Lo script di collegamento è quello che viene specificato sulla riga di comando di pppd; si trova in /etc/ppp/peers e ha generalmente il nome del provider. Per esempio, supponendo che il provider si chiami BigNet e che il nostro nome utente presso il provider sia alan, questo potrebbe essere lo script per il collegamento:
Nel precedente esempio, lo script indica il chat file da utilizzare per il collegamento. Per una spiegazione delle opzioni: pppd(8).
Nota: in caso di problemi di connessione, è possibile aggiungere al precedente file due righe contenenti le opzioni
debug kdebug 4Per ulteriori informazioni: pppd(8), syslog.conf(5) .
Lo script di collegamento chiama il programma chat per effettuare il collegamento fisico vero e proprio (inizializzazione del modem, composizione del numero, ecc.). I parametri da passare a chat sono abbastanza numerosi e conviene metterli in un file, anche se è possibile specificarli inline nello script di collegamento. Per esempio, supponendo che il numero di telefono del POP più vicino sia 02 99999999
Nota: se si verificano dei problemi con il chatfile, può essere comodo collegarsi manualmente al provider con cu: in questo modo si possono vedere le stringhe esatte che vengono ricevute. Per ulteriori informazioni: cu(1).
Durante la fase di autenticazione ognuno dei due sistemi verifica l'identità dell'altro. In realtà il provider solitamente non si aspetta di essere autenticato ma pretende cha a farlo sia l'utente che si collega.
Generalmente i provider per provvedere alla nostra autenticazione utilizzano uno di questi due metodi:
login
PAP/CHAP
La maggior parte dei provider utilizza un'autenticazione di tipo PAP/CHAP. Questa informazione viene generalmente fornita dal provider stesso.
È sufficiente creare il file /etc/ppp/pap-secrets (o /etc/ppp/chap-secrets) le cui righe hanno il seguente formato:
utente * password
Per esempio:
alan * pZY9o
Nota: per motivi di sicurezza è bene che il file pap-secrets sia di proprietà di root e abbia permessi '600'.
Si tratta di una forma di autenticazione sempre meno usata; se il provider usa l'autenticazione login, il nome utente e la password non devono essere specificati in pap-secrets o in chap-secrets, bensì nel chatfile (naturalmente in questo caso è bene adottare opportuni permessi per il chatfile). In questo caso il chatfile simula un login interattivo.
Rimane solo da configurare il file delle opzioni di pppd, che è /etc/ppp/options (chmod 644.)
Prima di attivare il collegamento può essere conveniente effettuare un test del modem, per verificare che tutto funzioni correttamente. Per il test si può usare il programma cu.
Creare il file /etc/uucp/port contenente le seguenti righe:
type modem port modem device /dev/tty01 speed 115200(naturalmente, al posto di /dev/tty01 bisogna sostituire il device appropriato).
Dare il comando cu -p modem per avviare il test interattivo. A questo punto si possono inviare comandi al modem. Per esempio:
# cu -p modem Connected. ATZ OK ~. Disconnected. #Nell'esempio precedente viene inviato al modem il comando di reset (ATZ) e il modem risponde con OK. Come si vede, per uscire da cu bisogna dare il comando ~. (carattere tilde seguito dal carattere punto).
Se il modem sembra non funzionare, la prima cosa da controllare è che il modem sia realmente collegato al port usato da cu. Un'altra frequente causa di problemi sono i cavi.
Nota: se quando si avvia cu compare un messaggio che dice "Permission denied", verificare chi è il proprietario dei file /dev/tty##: deve essere uucp. Per esempio:
$ ls -l /dev/tty00 crw------- 1 uucp wheel 8, 0 Mar 22 20:39 /dev/tty00Se invece il proprietario è root:
$ ls -l /dev/tty00 crw------- 1 root wheel 8, 0 Mar 22 20:39 /dev/tty00 $ cu -p modem cu: open (/dev/tty00): Permission denied cu: All matching ports in use
Finalmente tutto è pronto per attivare il collegamento con il provider dando il comando
# pppd call bignet
dove bignet è il nome dello script di collegamento già descritto. Per vedere i messaggi di collegamento di pppd e chat, dare il comando
# tail -f /var/log/messages
Per scollegarsi bisogna fare un kill -HUP di pppd.
Quando il collegamento è a posto e funziona correttamente è il momento di creare un paio di comodi script per connettersi e per disconnettersi automaticamente. Per esempio, per connettersi:
e per sconnettersi:
Questi due script sfruttano il fatto che pppd, quando è attivo, crea il file /var/spool/lock/LCK..tty01 che contiene il pid (identificativo di processo) di pppd.
I due script devono essere eseguibili:
# chmod u+x ppp-up ppp-down
Nota: per lanciare pppd bisogna essere root oppure appartenere al gruppo dialer o al gruppo operator. Quindi per l'uso degli script da parte di un utente normale si può utilizzare sudo (/usr/pkgsrc/security/sudo) oppure assegnare l'utente a uno dei gruppi appena citati.
Il networking è sicuramente uno dei punti di forza di Unix in generale e di NetBSD in particolare, e la creazione di una rete domestica è un'operazione semplicissima (ed economica). Tra le altre cose, ne la Sezione 10.2.1 si vedrà come configurare una macchina NetBSD per fare da gateway e da firewall Internet per il resto della rete, consentendo a tutte le macchine della rete l'accesso a Internet con un solo collegamento al provider; anche qui non c'è alcuna necessità di acquistare software aggiuntivo: NetBSD dispone già di tutto il necessario. L'unica accortezza che bisogna avere è quella di acquistare schede di rete supportate da NetBSD (consultare il file INSTALL per l'elenco dei dispositivi supportati).
La prima cosa da fare è installare le schede di rete Ethernet sulle macchine e collegarle a un hub, a uno switch oppure collegarle direttamente tra loro con l'apposito cavo coassiale e i terminatori. Per questo esempio si faccia riferimento alla figura Figura 10-1.
Una volta installate le schede di rete bisogna controllare che vengano riconosciute correttamente dal kernel studiando l'output di dmesg. Per esempio:
... ne0 at isa0 port 0x280-0x29f irq 9 ne0: NE2000 Ethernet ne0: Ethernet address 00:c2:dd:c1:d1:21 ...
naturalmente è necessario che la scheda sia abilitata nel kernel, in caso contrario abilitarla, ricompilare il kernel e riavviare. Per esempio:
... ne0 at isa? port 0x280 irq 9 # NE[12]000 ethernet cards ...
Se la scheda non viene riconosciuta dal kernel, bisogna esaminare il file di configurazione del kernel per controllare l'IRQ della scheda di rete. L'IRQ specificato nel file deve essere quello realmente utilizzato dalla scheda, altrimenti nella maggior parte dei casi il kernel non potrà riconoscerla all'avvio. Se l'IRQ è diverso si può cambiare la linea del file di configurazione e ricompilare il kernel oppure riconfigurare la scheda (solitamente con un dischetto di setup o, per le schede più datate, con un cavallotto).
Si provi ora a dare il comando seguente:
# ifconfig ne0 ne0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 media: Ethernet 10base2
L'output del comando precedente mostra l'attuale configurazione della scheda di rete.
A questo punto si può passare alla configurazione software, che è molto semplice. Per prima cosa conviene provare la scheda, iniziando con il configurarla:
# ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00
L'effetto del comando si può verificare con:
# ifconfig ne0 ne0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 media: Ethernet 10base2 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
Confrontando con l'output del precedente comando ifconfig si può notare che è comparso l'indirizzo di rete assegnato e sono comparsi i flag "UP" e "RUNNING". Se un'interfaccia non è "UP", il sistema non la utilizzerà per trasmettere pacchetti.
All'host è stato attribuito l'indirizzo IP 192.168.1.1, che appartiene agli indirizzi di rete cosiddetti "interni", ossia riservati alle reti non visibili da Internet. A questo punto si può dire che la configurazione è terminata e non resta che provarla; se vi sono altri host già in rete si può provare a fare un ping verso un altro host. Per esempio, se l'indirizzo IP di un host attivo della rete è 192.168.1.2, provare:
# ping 192.168.1.2 PING ape (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=1.286 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=0.649 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=0.681 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=0.656 ms ^C ----ape PING Statistics---- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.649/0.818/1.286/0.312 ms
Al prossimo riavvio la configurazione della scheda andrà effettuata nuovamente; per automatizzare l'operazione conviene creare il file /etc/ifconfig.ne0 contenente la linea
inet 192.168.1.1 netmask 0xffffff00
Poi, nel file /etc/rc.conf bisogna impostare l'opzione
auto_ifconfig=YES
infine si inseriscono gli indirizzi degli host in /etc/hosts. Per esempio:
Il file /etc/nsswitch.conf deve essere modificato come già spiegato in Esempio 10-2.
Al prossimo riavvio tutto sarà configurato automaticamente.
Nota: in questo esempio è stato creato il file /etc/ifconfig.ne0 perché la scheda di rete veniva riconosciuta come ne0. Per altre schede bisogna sostituire il nome opportuno.
Per configurare la rete bisogna dunque semplicemente collegare fisicamente i computer, assegnare a ciascuno un indirizzo IP e configurare il file /etc/hosts con gli indirizzi di tutti su ogni host e modificare il file /etc/nsswitch.conf. Si tratta di una politica di gestione elementare, adatta soltanto a reti di piccole dimensioni.
Capita talvolta (almeno a me) di trovarsi nella necessità di trasferire dei file da un portatile a un PC. Se il portatile non si può collegare in rete e non ha il floppy (o magari il file è troppo grosso per un dischetto) una soluzione semplice ed efficace è quella di collegare le due macchine con un cavo null modem. Nelle sezioni seguenti vediamo alcuni esempi di possibili configurazioni.
Se entrambe le macchine da collegare utilizzano NetBSD, ci si trova nella situazione più favorevole: la realizzazione di un collegamento SLIP è semplicissima. Sulla prima macchina
# slattach /dev/tty00 # ifconfig sl0 inet 192.168.1.1 192.168.1.2
sulla seconda macchina
# slattach /dev/tty00 # ifconfig sl0 inet 192.168.1.2 192.168.1.1
A questo punto si può provare il collegamento con ping; per esempio, dal secondo PC eseguire
# ping 192.168.1.1
Se tutto è andato bene le due macchine sono in rete e si possono usare ftp, telnet, ecc. Può anche essere conveniente inserire i nomi e gli indirizzi degli host nel file /etc/hosts.
Nell'esempio precedente entrambe le macchine usavano la prima porta seriale (/dev/tty00).
Gli indirizzi 192.168.x.x sono tra quelli riservati per le reti private. La prima macchina ha indirizzo 192.168.1.1 e la seconda ha indirizzo 192.168.1.2.
Per ottenere un collegamento più veloce bisogna specificare il parametro -s velocità a slattach.
Per poter eseguire ftp deve essere stato avviato inetd e deve essere abilitato il server ftpd.
Nota: se uno dei due PC utilizza Linux, i comandi su quest'ultimo sono leggermente diversi. Supponendo di dare al PC Linux l'indirizzo 192.168.1.2:
# slattach -p slip -s 115200 /dev/ttyS0 & # ifconfig sl0 192.168.1.2 pointopoint 192.168.1.1 up # route add 192.168.1.1 dev sl0Non bisogna dimenticare "&" nel primo comando.
Windows NT e NetBSD possono essere messi in rete in modo semplice con un cavo seriale null modem. Il procedimento consiste nel creare una connessione di "Accesso remoto" sotto NT e nell'avviare pppd su NetBSD. Vediamo praticamente come fare.
Supponendo di avviare pppd come root, bisogna creare un file .ppprc in /root. Il contenuto del file deve essere simile al seguente:
connect '/usr/sbin/chat -v CLIENT CLIENTSERVER' local tty00 115200 crtscts lock noauth nodefaultroute :192.168.1.2
Il significato della prima riga verrà spiegato dopo; 192.168.1.2 è l'indirizzo IP che verrà assegnato da NetBSD all'host NT; tty00 è la porta seriale usata per la connessione.
Dal lato NT bisogna prima installare un modem di tipo null modem (connessione diretta) e poi creare una connessione di Accesso remoto che usi questo modem. Il driver null modem è standard sotto NT, ma non si tratta di un vero e proprio null modem, infatti all'attivazione del collegamento NT invia la stringa CLIENT e si aspetta di ricevere la risposta CLIENTSERVER (ecco il significato della prima riga di .ppprc: chat deve rispondere a NT, altrimenti la connessione non va a buon fine). Per la creazione della connessione utilizzare il null modem, indicare un numero telefonico qualsiasi (tanto non viene usato), scegliere un server ppp, abilitare solo il protocollo TCP/IP, usare indirizzo IP e nameserver indicati dal server (NetBSD, in questo caso). Inoltre impostare il flusso di controllo hardware e la porta a 115200 8N1.
A questo punto si può effettuare la connessione:
Collegare fisicamente le seriali delle due macchine.
Lanciare pppd su NetBSD. (Per vedere i messaggi inviati da pppd: tail -f /var/log/messages).
Attivare la connessione di Accesso remoto su NT.
Come per il caso di Windows NT, conviene usare la connessione di Accesso remoto di Windows e il server ppp di BSD. Purtroppo Windows 95 non dispone di un driver null modem, il che complica un po' le cose. La cosa più semplice è procurarsene uno su Internet (si tratta di un banale file .INF) e seguire le stesse istruzioni di Windows NT con l'unica avvertenza di rimuovere la linea che richiama chat dal file .ppprc.
In mancanza di un driver null modem si può usare un piccolo trucco:
Creare una connessione di Accesso remoto come quella descritta ne la Sezione 10.1.5.2 ma utilizzando il "Modem Standard".
In .ppprc sostituire la linea che chiama chat con la seguente
connect '/usr/sbin/chat -v ATH OK AT OK ATE0V1 OK AT OK ATDT CONNECT'
Per la connessione procedere come nel caso di Windows NT.
In questo modo il programma chat, richiamato alla connessione, emula il comportamento di un modem standard e restituisce a Windows le stringhe di risposta che riceverebbe da un modem: a ogni comando AT inviato, chat risponde con un OK.
Dietro alla misteriosa sigla IPNAT si nasconde l'Internet Protocol Network Address Translation, che consente l'instradamento di una rete IP fittizia (locale) su una vera (Internet). Ciò significa che con un solo IP fornito dal provider si possono collegare a Internet più computer creando una finta rete IP interna e instradando i dati tramite un computer collegato a Internet sui cui è in funzione IPNAT.
Per alcuni esempi d'uso di IPNAT, vedere nella subdirectory /usr/share/examples/ipf, in particolare i file BASIC.NAT e nat-setup.
L'esempio presentato in questa sezione è illustrato dalla Figura 10-1: l'host 1 può collegarsi a Internet con il modem chiamando un provider, che assegna un indirizzo IP dinamico. Gli host 2 e 3 non possono comunicare con Internet. Per rendere possibile il collegamento anche a loro si usano IPF e IPNAT.
Se il kernel è stato compilato con l'opzione GATEWAY attiva, questa è abilitata di default senza eseguire ulteriori operazioni di configurazione. Per controllare se è abilitata:
# sysctl net.inet.ip.forwarding net.inet.ip.forwarding = 1
Se il risultato è "1", come nell'esempio precedente, l'opzione è abilitata. Inoltre nel file di configurazione del kernel deve essere abilitato "pseudo-device ipfilter". Se il risultato è invece "0", allora l'opzione non è abilitata e vi sono due possibilità:
Compilare un nuovo kernel con l'opzione GATEWAY attiva.
Attivare l'opzione nel kernel corrente con il seguente comando:
# sysctl -w net.inet.ip.forwarding=1
Le impostazioni di sysctl vanno aggiunte al file /etc/sysctl.conf in modo che siano ripristinate automaticamente al riavvio del sistema. In questo caso bisogna aggiungere
net.inet.ip.forwarding=1
Le istruzioni seguenti spiegano come creare una configurazione di IPNAT che entri in funzione automaticamente ogni volta che ci si collega con il provider e si attiva il link PPP. Con questa configurazione tutti i PC della rete domestica potranno condividere il collegamento a Internet, anche se non utilizzano NetBSD.
Creare il file /etc/ipnat.conf contenente le seguenti regole:
map ppp0 192.168.1.0/24 -> 0/32 proxy port ftp ftp/tcp map ppp0 192.168.1.0/24 -> 0/32 portmap tcp/udp 40000:60000 map ppp0 192.168.1.0/24 -> 0/32
192.168.1.0/24 rappresenta il set di indirizzi interni da mappare. La prima linea consente il funzionamento del tcp attivo attraverso NAT ed è opzionale. La seconda riga assicura che i pacchetti tcp e udp vengano gestiti correttamente da NAT (il portmapping è necessario per via della relazione molti a uno). La terza riga fa funzionare tutto il resto (ICMP, ping, ecc.).
Creare il file /etc/ppp/ip-up che verrà chiamato automaticamente all'attivazione del link PPP.
#!/bin/sh # /etc/ppp/ip-up /etc/rc.d/ipnat forcestart
Creare il file /etc/ppp/ip-down che verrà chiamato automaticamente alla disattivazione del link PPP.
#!/bin/sh # /etc/ppp/ip-down /etc/rc.d/ipnat forcestop
ip-up e ip-down devono essere eseguibili:
# chmod u+x ip-up ip-down
Creare il file /etc/resolv.conf (come quello del gateway).
Dare il comando route add default 192.168.1.1 (192.168.1.1 è l'indirizzo IP del gateway precedentemente configurato).
Naturalmente è molto scomodo ripetere questo comando a ogni avvio. Per rendere automatica la configurazione del gateway si possono usare due metodi equivalenti:
specificare l'indirizzo del gateway utilizzando l'opzione "defaultroute" del file /etc/rc.conf
scrivere l'indirizzo del gateway nel file /etc/mygate
Se il client non è una macchina NetBSD, la sua configurazione sarà naturalmente diversa. Su una macchina Windows, per esempio, bisogna impostare la proprietà "gateway" del protocollo TCP/IP.
Per effettuare verifiche possono essere utili i seguenti comandi:
Visualizza le tabelle di instradamento (simile a route show).
Sul client; mostra la strada seguita dai pacchetti per arrivare a destinazione.
Da eseguire sul gateway.
Una volta messa in funzione la rete è possibile condividere file e directory tra computer grazie a NFS. Dal punto di vista della condivisione dei file, il computer che offre accesso alle sue gerarchie di directory è il server, quello che accede è il client. Un computer può essere contemporaneamente client e server. Vediamo quali sono le operazioni da compiere
Sia per il client sia per il server deve essere compilato un kernel con abilitata l'apposita opzione (non è difficile da trovare...).
Il server deve abilitare i servizi RPC in /etc/inetd.conf.
In /etc/rc.conf il server deve abilitare i daemon inetd e portmap e l'opzione nfs_server.
In /etc/rc.conf il client deve abilitare inetd e nfs_client.
Il server deve elencare le esportazioni in /etc/exports e poi eseguire il comando kill -HUP `cat /var/run/mountd.pid.
L'accesso a una directory remota si basa su due presupposti:
Il computer remoto esporta la directory.
Il computer locale monta la directory remota con il comando mount server:/xx/yy /mnt
Il comando mount è dotato di un ricco assortimento di opzioni, non proprio semplicissime.
Questo esempio, abbastanza elaborato, è stato preso da una situazione reale presentata su una mailing list. Supponiamo di avere il seguente scenario: cinque macchine client (cli1, ..., cli5) devono accedere a alcune directory su un server (buzz.toy.org). Alcune delle directory esportate dal server sono specifiche dei singoli client, altre sono condivise da tutti i client. I client fanno tutti il boot dal server e devono montare le directory. Le directory da esportare dal server sono:
deve servire da directory root per ognuna delle macchine cli?.
area di swap per ognuna delle macchine cli?.
directory /usr comune a tutte le macchine cli?.
da montare come /usr/src su ognuna delle macchine cli? (comune).
Sul server sono presenti i seguenti file system
/dev/ra0a su / /dev/ra0f su /usr /dev/ra1a su /usr/src /dev/ra2a su /export
Sui client si vogliono ottenere i seguenti file system
buzz:/export/cli?/root su / buzz:/export/common/usr su /usr buzz:/usr/src su /usr/src
La configurazione del server è la seguente:
# /etc/exports /usr/src -network 123.45.67.0 -mask 255.255.255.0 /export -alldirs -maproot=root -network 123.45.67.0 -mask 255.255.255.0
Ovviamente 123.45.67.0 deve essere sostituito con l'indirizzo reale della rete, come pure la netmask. Inoltre può essere necessario aggiungere: -maproot=root alla riga con "/usr/src".
Sui client /etc/fstab deve contenere
buzz:/export/cli?/root / nfs rw buzz:/export/common/usr /usr nfs rw,nodev,nosuid buzz:/usr/src /usr/src rw,nodev,nosuid
Naturalmente per ogni client bisogna sostituire il relativo numero al posto del carattere "?" in /etc/fstab.
L'autore di questa sezione (Impostare ...) è Hubert Feyrer <hubert@feyrer.de>.
Il problema con i mount NFS (e con gli altri tipi di mount) è che solitamente possono essere effettuati dall'utente "root", il che può risultare molto scomodo per gli altri utenti. Grazie a amd si può impostare una directory (nel nostro esempio verrà usata la directory /net) sotto la quale anche gli utenti normali possono effettuare mount NFS, a condizione che il filesystem a cui si deve accedere sia effettivamente esportato dal server NFS.
Per verificare quali sono i file system esportati da un server NFS, usare il comando showmount con l'opzione -e:
# showmount -e wuarchive.wustl.edu Exports list on wuarchive.wustl.edu: /export/home onc.wustl.edu /export/local onc.wustl.edu /export/adm/log onc.wustl.edu /usr onc.wustl.edu / onc.wustl.edu /archive Everyone
Per montare una directory e accedere a tutto il suo contenuto, subdirectory comprese, (per esempio /archive/systems/unix/NetBSD), basta portarsi nella directory con cd:
# cd /net/wuarchive.wustl.edu/archive/systems/unix/NetBSD
Il file system viene montato automaticamente da amd ed è possibile accedere a tutti i file proprio come se la directory fosse stata montata dall'amministratore di sistema.
La directory /net del nostro esempio si può impostare con le seguenti operazioni (che includono il setup di amd):
in /etc/rc.conf, impostare la variabile seguente:
amd=yes
mkdir /amd
mkdir /net
Usando /usr/share/examples/amd/master come esempio, aggiungere la direttiva seguente a /etc/amd/master:
/net /etc/amd/net
Usando /usr/share/examples/amd/net come esempio, aggiungere le seguenti righe a /etc/amd/net:
/defaults type:=host;rhost:=${key};fs:=${autodir}/${rhost}/root * host==${key};type:=link;fs:=/ \ host!=${key};opts:=ro,soft,intr,nodev,nosuid,noconn
Riavviare la macchina, oppure riavviare amd manualmente:
# sh /etc/rc.d/amd restart
L'autore di questa sezione (Connettività ...) è Hubert Feyrer <hubert@feyrer.de>.
Questa sezione spiega come arrivare praticamente alla connettività IPv6 e, poiché quest'ultima non è ancora facile da ottenere in modo nativo, descrive diffusamente le alternative alla connettività nativa IPv6 e un metodo per effettuare la transizione finché le connessioni IPv6 diventeranno più comuni.
Trovare un ISP che offra la connettività IPv6 nativa richiede una buona dose di fortuna. Il passo successivo è trovare un router in grado di gestire il traffico; al momento non tutti i produttori di router supportano IPv6 sulle loro macchine e, anche auqndo lo fanno, è improbabile che offrano routing o switching IPv6 con accelerazione hardware. Un'alternativa economica e di uso comune al router hardware consiste nell'usare un PC standard configurandolo come router, per esempio utilizzando un sistema operativo quale NetBSD e un sofware del tipo di Zebra per gestire i protocolli di routing. Questa soluzione è oggi abbastanza diffusa per quei siti che vogliono subito la connettività IPv6; l'unico svantaggio è che serve un ISP che supporta IPv6 e un colegamento dedicato solo per IPv6.
In mancanza di connettività nativa, si può ancora utilizzare IPv6 grazie ai tunnel. Invece di inviarli direttamente, i pacchetti IPv6 vengono incapsulati dentro a pacchetti IPv4, come mostrato in Figura 10-2. Usando l'infrastruttura IPv4, i pacchetti incapsulati vengono inviati a un collegamento reale IPv6 che rimuove l'incapsulamento e li invia in modalità nativa.
Per usare i tunnel ci sono due possibilità. La prima consiste nell'uso di un tunnel cosiddetto "configurato", la seconda nell'uso di un tunnel "automatico". Un tunnel configurato è caratterizzato dal fatto di richiedere una preparazione da entrambi i lati del tunnel stesso, generalmente soggetta a una qualche forma di registrazione al fine di scambiare i dati di setup. Un esempio di questo tipo di tunnel è l'incapsulamento IPv6-su-IPv4 descritto in [RFC1933] e implementato, per esempio, dall'interfaccia gif(4) di NetBSD.
Un tunnel automatico richiede un server pubblico dotato di una qualche forma di connettività IPv6, per esempio via 6Bone. Questo server rende pubblici i propri dati di connettività e attiva un protocollo di "tunnelling" che non richiede una registrazione esplicita dei siti che lo usano per collegarsi. Un popolare esempio di questo protocollo è il meccanismo 6to4 descritto in [RFC3056], e implementato dal dispositivo stf(4) di NetBSD. Un altro meccanismo che non richiede registrazione di informazioni IPv6 è il cosiddetto 6over4, che implementa il trasporto di IPv6 su una rete IPv4 abilitata al multicast, invece di, per esempio, ethernet o FDDI. 6over4 è documentato in [RFC2529]. Il suo principale svantaggio è che è necessaria la presenza di un'infrastruttura multicast esistente. Se non c'eè una struttura di questo tipo, la sua creazione e impostazione richiede uno sforzo paragonabile alla configurazione di un tunnel IPv6 diretto, e pertanto, in questo caso, si tratta di un'ipotesi che non vale la pena di considerare.
6to4 offre una soluzione semplice per ottenere la connettività IPv6 è per quegli host che sono dotati solo di un collegamento IPv4 (vedere la Sezione 9.1.7. Si può utilizzare con indirizzi IPv4 sia statici sia dinamici (il tipo più comune nel caso di connessioni "dial-up" via modem). Quando si usa un indirizzo IPv4 dinamico, i cambiamenti di indirizzo sono un problema per il traffico in entrata, il che comporta che non si può usare questo tipo di impostazione per un server web.
La configurazione di esempio descritta in questa sezione si riferisce a NetBSD 1.5.2.
Il setup IPv6 di 6to4 non consiste di un solo indirizzo dal lato utente: infatti si ottiene un'intera rete /48! Gli indirizzi IPv6 vengono ricavati a partire dal singolo indirizzo IPv4 originale. Il prefisso "2002:" è riservato agli indirizzi di tipo 6to4 (cioè agli indirizzi IPv6 derivati da IPv4). I 32 bit seguenti contengono l'indirizzo IPv4. Questo corrisponde a avere la disponibilità di un'intera rete /48, lasciando 16 bit di spazio per 216 sottoreti IPv6, ognuna con un massimo di 264 nodi. Figura 10-3 mostra la costruzione dell'indirizzo (o meglio dell'insieme di indirizzi) IPv6 a partire da quello IPv4.
Grazie al prefisso 6to4 e all'unicità dell'indirizzo IPv4, il blocco di indirizzi IPv6 ottenuti è anch'esso unico ed è assegnato alla macchina che aveva l'indirizzo IPv4 di partenza.
A differenza del setup configurato del tunnel "IPv6-over-IPv4", non è necessario registrarsi presso un gateway 6bone che inoltri il traffico IPv6. Invece, poiché l'indirizzo IPv6 deriva da quello IPv4, le risposte vengono inviate all'utente dal più vicino gateway 6to4. L'incapsulamento dei pacchetti viene elimnato da un'interfaccia di rete abilitata 6to4, che poi provvede a inoltrarli a seconda dell'instradamento impostato localmente (nel caso vi sia più di una macchina collegata alla rete 6to4 che è stata assegnata.
Per quanto riguarda l'invio di pacchetti IPv6 (traffico in uscita), l'interfaccia di rete abilitata 6to4 prende il pacchetto IPv6 e lo incapsula in un pacchetto IPv4. È necessario un collegamento al gateway 6to4, a sua volta collegato alla 6bone, che elimini l'incapsulamento dai pacchetti e li inoltri sulla 6Bone, come illustrato in Figura 10-4.
A differenza del setup con un "tunnel preconfigurato", in questo caso non si riesce solitamente a impostare filtri sui pacchetti per bloccare pacchetti 6to4 provenienti da fonti non autorizzate, proprio a causa del metodo di funzionamento del meccanismo 6to4. I pacchetti con le seguenti caratteristiche non dovrebbero essere considerati pacchetti 6to4 validi, e quindi è giustificato filtrarli:
indirizzo sorgente/destinazione IPv4 non specificato: 0.0.0.0/8
indirizzo di loopback (v4) come sorgente/destinazione: 127.0.0.0/8
multicast IPv4 in sorgente/destinaziomne: 224.0.0.0/4
broadcast limitato: 255.0.0.0/8
indirizzo di broadcast di sottorete in sorgente/destinazione: dipende dal setup IPv4
La pagina di manuale stf(4) di NetBSD riporta alcuni comuni errori di configurazione che vengono intercettati dallo stack KAME e contiene anche alcuni suggerimenti per il filtraggio dei pacchetti, anche se, a causa dei requisiti di questi filtri, il 6to4 non è completamente sicuro. Tuttavia, se i pacchetti 6to4 fittizi diventano un problema, si può utilizzare l'autenticazione IPsec per assicurarsi che i pacchetti IPv6 non vengano modificati.
Per configurare IPv6 via 6to4, sono necessarie alcune informazioni, e cioè:
L'indirizzo IPv4 locale, che si può determinare con il comando ifconfig -a oppure con netstat -i sulla maggior parte dei sistemi Unix. Se si usa un gateway con NAT o simili, bisogna utilizzare l'indirizzo ufficiale, visibile dall'esterno, e non quello privato (10/8 or 192.168/16).
In questo esempio verrà usato l'indirizzo IP locale 62.224.57.114.
L'indirizzo IPv6 locale derivato da quello IPv4. Vedere Figura 10-3.
In questo esempio l'indirizzo è 2002:3ee0:3972:0001::1 (62.224.57.114 == 0x3ee03972, 0001::1 è stato scelto arbitrariamente).
L'indirizzo IPv6 del gateway 6to4 da utilizzare. L'indirizzo IPv6 va bene perché contiene quello IPv4, nella solita traduzione 6to4.
In questo esempio usermo 2002:c25f:6cbf::1 (== 194.95.108.191 == 6to4.ipv6.fh-regensburg.de).
Pre elaborare pacchetti di tipo 6to4, il kernel del sistema operativo deve essere messo in grado di riconoscerli e gestirli, ed è pertanto necessario abilitare un apposito driver.
Per preparare il kernel di NetBSD all'uso di IPv6 e 6to4, bisogna attivare le linee seguenti nel file di configurazione del kernel:
options INET6 # IPv6 pseudo-device stf # 6to4 IPv6 over IPv4 encapsulation
Nota: il dispositivo stf(4) non è attivo di default.
Ricompilare il kernel e riavviare la macchina per attivare il nuovo kernel. Vedere Capitolo 7 per ulteriori informazioni sulla configurazione, compilazione e installazione di un nuovo kernel.
La presente sezione descrive i comandi necessari per il setup di 6to4. In breve, le operazioni da compiere sono:
configurare l'interfaccia
impostare la route di default
impostare il Router Advertisement, se lo si desidera
Il primo passo da compiere per impostare 6to4 è di assegnare un indirizzo IPv6 all'interfaccia 6to4, usando il comando ifconfig(8). Data la configurazione appena descritta, il comando è:
# ifconfig stf0 inet6 2002:3ee0:3972:1::1 prefixlen 16 alias (local)
Dopo aver configurato il dispositivo 6to4 con questo comando, bisogna impostare il routing, per inoltrare il traffico IPv6 al gateway 6to4. Il metodo migliore consiste nell'impostare una route di
# route add -inet6 default 2002:cdb2:5ac2::1 (remote)
Si noti che il dispositivo stf(4) di NetBSD determina l'indirizzo del gateway 6to4 dalla tabella di routing. Sfruttando questa caratteristica è semplice impostare un proprio gateway 6to4 se si dispone di un vero collegamento IPv6, per esempio via 6Bone.
Dopo aver dato quetsi comandi il colegamento al mondo IPv6 è attivo: congratulazioni! Assumendo che la risoluzione dei nomi venga sempre effettuata via IPv4, si può ora effettuare un "ping" di un sito IPv6, quale www.kame.net oppure www6.netbsd.org:
# /sbin/ping6 www.kame.net
L'ultimo passo nell'impostazione di IPv6 via 6to4 consiste nel setup del Router Advertisement, per il caso i cui vi siano più host sulla rete. Benché sia possibile ripetere le impostazioni 6to4 su ognuno dei nodi, quest'operazioni comporta dei costi di routing onerosi da un nodo all'altro - i pacchetti vengono inviati al gateway 6to4 che li inoltrera al nodo vicino. Invece è preferibile impostare 6to4 su un'unica macchina e impostare IPv6 nativo sulla rete locale.
Si inizia con l'assegnare un indirizzo IPv6 all'interfaccia di rete. Nell'esempio seguente assumiamo che la sottorete "2" della rete IPv6 sia la rete ethernet locale e che l'indirizzo MAC dell'interfaccia ethernet sia 12:34:56:78:9a:bc, cioè l'indirizzo IP dell'interfaccia ethernet dela gateway locale è 2002:3ee0:3972:2:1234:56ff:fe78:9abc. Assegnamo questo indirizzo all'interfaccia ethernet:
# ifconfig ne0 inet6 alias 2002:3ee0:3972:2:1234:56ff:fe78:9abc
Nel comando precedente, "ne0" è l'interfaccia che si riferisce alla scheda di rete ethernet; naturalmente sarà diversa a seconda della scheda montata sul sistema.
Per il setup del router bisogna poi verificare che inoltri effettivamente i pacchetti dal dispositivo 6to4 locale all'intrefaccia ethernet e viceversa. Per abilitare il forwarding dei pacchetti IPv6, impostare "ip6mode=router" nel file /etc/rc.conf, che mette a "1" il "sysctl" di net.inet6.ip6.forwarding.
# sysctl -w net.inet6.ip6.forwarding=1
Per impostare il Router Advertisement bisogna controllare il file /etc/rtadvd.conf. Questo file consente di configurare parecchie cose ma, solitamente, la configurazione di default di non contenere dati va bene. Con questa impostazione, gli indirizzi IPv6 di tutte le schede di rete del router saranno resi pubblici.
Dopo aver verificato che la configurazione del Router Advertisement è corretta e che il forwarding IPv6 è abilitato, si può avviare il relativo demone che, sotto NetBSD, si chiama rtadvd. La prima volta lo si può avviare manualmente a scopo di test, ma poi conviene usare gli script di avviamento del sistema: in ogni caso si vedranno tutti i nodi locali magicamente configurare la sottorete resa pubblica in aggiunta ai loro indirizzi link-local preesistenti.
# rtadvd
Fino a ora abbiamo descritto il funzionamento e l'impostazione di 6to4. Per automatizzare queste operazioni, per esempio quando ci si collega "online", conviene utilizzare il package "6to4", che determina l'indirizzo IPv6 a partire da quello IPv4 assegnato dal provider e poi provvede alle necessarie impostazioni.
Il setup del pacchetto pkgsrc/net/6to4 richiede le seguenti operazioni:
Installare il package compilandolo da pkgsrc oppure usando il pacchetto precompilato 6to4-1.nb1 con il comando pkg_add.
# cd /usr/pkgsrc/net/6to4 # make install
Verificare che il pseudo-dispositivo stf(4) sia incluso nel kernel (vedere sopr).
Configurare il pacchetto "6to4". Per prima cosa, copiare /usr/pkg/etc/6to4.conf-example su /usr/pkg/etc/6to4.conf, e poi sistemare le variabili. Si noti che il file utilizza la sintassi perl.
# cd /usr/pkg/etc # cp 6to4.conf-example 6to4.conf # vi 6to4.conf
La pagina di manuale 6to4(8) descrive tutte le variabili che si possono impostare in 6to4.conf. Se si ha una connessione IP dialup via PPP e non si è interessati al Router Advertising per le altre macchine IPv6 della rete locale domestica o dell'ufficio, non è necessario effettuare alcuna configurazione. Se, invece, si vuole utilizzare il Router Advertising, bisogna impostare la variabile in_if al valore dell'interfaccia ethernet interna. Per esempio:to the internal (ethernet)
in_if="rtk0"; # Inside (ethernet) interface
Ra ci si può collegare e poi avviare il comando 6to4 manualmente:
# /usr/pkg/sbin/6to4.pl start
A collegamento effettuato, usare il comando ping6(8) per verificare che tutto funzioni correttamente. In caso afermativo, inserire le linee seguenti nello script /etc/ppp/ip-up che viene lanciato ogni volta che ci si collega:
logger -p user.info -t ip-up Configuring 6to4 IPv6 /usr/pkg/sbin/6to4.pl stop /usr/pkg/sbin/6to4.pl start
Per avere il routing IPv6 anche sulla rete interna, si può indicare a 6to4.pl di impostare automaticamente il Router Advertising:
# /usr/pkg/sbin/6to4 rtadvd-start
Anche questo comando si può mettere nello script /etc/ppp/ip-up per renderlo permanente.
Se si è combiato /etc/ppp/ip-up per impostare automaticamente 6to4, conviene cambiare anche /etc/ppp/ip-down per fermarlo quando si chiude il collegamento e si passa offline. I comandi da inserire in /etc/ppp/ip-down sono:
logger -p user.info -t ip-down Shutting down 6to4 IPv6 /usr/pkg/sbin/6to4.pl rtadvd-stop /usr/pkg/sbin/6to4.pl stop
Al momento non sono ancora disponibili molti gateway 6to4. Una lista di quelli utilizzabili si trova in http://www.kfu.com/~nsayer/6to4/: naturalmente conviene scegliere il più vicino. Nei test sembra che solo 6to4.kfu.com e 6to4.ipv6.microsoft.com funzionino. Cisco ha un gateway presso il quale occorre registrarsi prima di poterlo usare; vedere http://www.cisco.com/ipv6/.
C'è anche un server sperimentale 6to4 in Germania, 6to4.ipv6.fh-regensburg.de. Questo server usa NetBSD 1.5 ed è stato impostato usando il metodo descritto in questo capitolo. La configurazione della macchina si può vedere all'indirizzo http://www.feyrer.de/IPv6/netstart.local.
Se lo si confronta con il livello raggiunto oggi da IPv4, IPv6 sta ancora muovendo i suoi primi passi: funziona, molti servizi e client sono già disponibili; manca ancora una base di utenti. Le informazioni contenute in questo capitolo possono costituire un punto di partenza per consentire di iniziare a sperimentare e utilizare IPv6.
Alcuni link utili:
Uno script di esempio per impostare 6to4 su macchine BSD si può trovare su http://www.netbsd.org/packages/net/6to4/. Lo script determina l'indirizzo IPv6 della macchina e imposta, se lo si desidera, il Router Advertising. Lo script è stato progettato pensando agli ambienti con conessione dial-up, con indirizzo locale che cambia di volta in volta.
Le implementazioni di BSD Unix hanno la propria documentazione; i link più interessanti si possono trvare su http://www.netbsd.org/Documentation/network/ipv6/ per NetBSD, http://www.freebsd.org/doc/en_US.ISO_8859-1/books/handbook/ipv6-implementation.html per FreeBSD e le pagine 61 e 62 della Administrator's Guide di BSD/OS su http://www.bsdi.com/products/internet/release-notes/rn42.pdf.
I progetti che lavorano per implementare gli stack del protocollo IPv6 sono KAME per BSD e USAGI per Linux. I relativi siti sono http://www.kame.net/ e http://www.linux-ipv6.org/. Una lista di host e router si trova su http://playground.sun.com/pub/ipng/html/ipng-implementations.html.
Oltre all'archivio ufficiale RFC all'indirizzo ftp://ftp.isi.edu/in-notes, si possono trovare informazioni su IPv6 su molti siti web. Il primo e più importante è la pagina web di 6Bone su http://www.6bone.net/ 6Bone è stato creato per servire come banco di prova per IPv6, ed è ora una parte importante del mondo degli utenti IPv6. Altre pagine web contenenti informazioni su IPv6 sono http://www.ipv6.org/, http://playground.sun.com/pub/ipng/html/ e http://www.ipv6forum.com/. La maggior parte di questi siti, che val la pena di visitare, contengono ulteriori utili link.