<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Linux NET-3-HOWTO, Linux Networking.: Informazioni generali sulla configurazione di rete.</TITLE>
<LINK HREF="NET-3-HOWTO-6.html" REL=next>
<LINK HREF="NET-3-HOWTO-4.html" REL=previous>
<LINK HREF="NET-3-HOWTO.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="NET-3-HOWTO-6.html">Avanti</A>
<A HREF="NET-3-HOWTO-4.html">Indietro</A>
<A HREF="NET-3-HOWTO.html#toc5">Indice</A>
<HR>
<H2><A NAME="s5">5. Informazioni generali sulla configurazione di rete.</A></H2>
<P>È piuttosto importante conoscere e capire le seguenti sottosezioni
prima di provare a configurare in pratica la propria rete. Questi sono
principi fondamentali che si applicano indipendentemente dall'esatta natura
della rete che si intende costruire.
<P>
<H2><A NAME="ss5.1">5.1 Da dove devo partire?</A>
</H2>
<P>Prima di iniziare a costruire o configurare la propria rete occorrono
alcune cose. Le più importanti di queste sono:
<P>
<H3>Sorgenti aggiornati del kernel.</H3>
<P>Siccome il kernel che si sta usando al momento potrebbe non avere ancora
il supporto per i tipi di rete o di schede di interfaccia che si desidera
usare, probabilmente occorrono i sorgenti del kernel, in modo da essere
in grado di ricompilare il kernel con le opzioni appropriate.
<P>
<P>I sorgenti più recenti si possono sempre ottenere da
<A HREF="ftp://ftp.kernel.org/pub/linux/kernel">ftp.kernel.org</A>.
<P>Meglio ricordarsi che ftp.kernel.org viene seriamente sovraccaricato: un modo
preferibile di ottenere i sorgenti aggiornati è scaricare le patch
invece degli interi file sorgente in tar; meglio ancora cercare di utilizzare
mirror del sito ftp principale, come
<A HREF="ftp://ftp.funet.fi//mirrors/ftp.kernel.org/pub/linux/kernel">ftp.funet.fi</A>;
ricordarsi inoltre che ogni sito Linux di solito fornisce sorgenti del kernel
aggiornati.
<P>
<P>Normalmente i sorgenti del kernel saranno scompattati da tar nella
directory <CODE>/usr/src/linux</CODE>. Per informazioni riguardo a come si
applicano le modifiche (patch) e come si ricompila il kernel si legga
<A HREF="Kernel-HOWTO.html">Kernel-HOWTO</A>.
Per informazioni su come si configurano i moduli del kernel si legga
"Modules mini-HOWTO". Inoltre il file <CODE>README</CODE> che si trova nei
sorgenti del kernel e la directory <CODE>Documentation</CODE> sono molto
istruttivi per il lettore motivato.
<P>
<P>A meno di trovare indicazioni differenti, io consiglio di utilizzare
la distribuzione stabile del kernel (quella con un numero pari come
seconda cifra nel numero di versione). Le distribuzioni dei kernel di
sviluppo (quelle con la seconda cifra dispari) possono presentare
differenze strutturali o altri cambiamenti che possono causare
problemi quando usati con altro software di sistema. Se non si
è sicuri di essere in grado di risolvere questo tipo di
problemi, anche considerando il rischio che ci siano altri errori nel
software, allora è bene non usare le versioni dispari.
<P>
<P>D'altra parte, alcune delle funzionalità ivi descritte sono state
introdotte nel corso dello sviluppo dei kernel 2.1, per cui è necessario
fare una scelta: si può rimanere al 2.0, aspettando che esca il 2.2 e
qualche distribuzione aggiornata e completa di ogni programma di supporto,
o passare ai 2.1 ed aggiungere in proprio i vari programmi di supporto
necessari per utilizzare al meglio le nuove funzionalità.
Al momento della stesura di questo paragrafo, nell'Agosto 1998, è
già stato rilasciato il 2.1.115 e si pensa che non manchi molto al
rilascio del 2.2 [al momento della traduzione sono già uscite
alcune distribuzioni con i nuovi kernel 2.2, tra le quali Debian 2.1 N.d.T.].
<P>
<H3>Gli strumenti di rete aggiornati</H3>
<P>Gli strumenti di rete (i "network tools") sono i programmi che si
usano per configurare le periferiche di rete di Linux. Questi
programmi permettono per esempio di assegnare gli indirizzi alle
periferiche e configurare l'instradamento.
<P>La maggior parte delle moderne distribuzioni di Linux contengono
già gli strumenti di rete, se perciò si è
installato il proprio sistema da una distribuzione senza aver ancora
installato gli strumenti di rete, occorre farlo.
<P>Se il proprio sistema non è stato installato da una
distribuzione, occorre recuperare i sorgenti e compilare i programmi
da se. Questo non è difficile.
<P>Gli strumenti di rete sono attualmente distribuiti da Bernd Eckenfels
e sono disponibili presso:
<A HREF="ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/">ftp.inka.de</A>, sito che è presente in mirror anche su
<A HREF="ftp://ftp.uk.linux.org/pub/linux/Networking/base/">ftp.uk.linux.org</A>.
<P>Occorre essere sicuri di scegliere la versione più appropriata
per il kernel che si intende usare e di seguire le istruzioni di
installazione che si trovano nel pacchetto.
<P>Per installare e configurare la versione corrente al momento della
stesura di questo documento occorre invocare i seguenti comandi:
<P>
<BLOCKQUOTE><CODE>
<PRE>
user% tar xvfz net-tools-1.33.tar.gz
user% cd net-tools-1.33
user% make config
user% make
root# make install
</PRE>
</CODE></BLOCKQUOTE>
<P>Inoltre, se si intende configurare un firewall o utilizzare la
possibilità di mascheramento dei pacchetti ("IP masquerading")
occorre il comando <EM>ipfwadm</EM>, la cui versione aggiornata si può
recuperare da:
<A HREF="ftp:/ftp.xos.nl/pub/linux/ipfwadm">ftp.xos.nl</A>.
Ancora una volta, esistono diverse versioni del programma, e bisogna prendere
la versione che meglio si adatta al proprio kernel.
Da notare che le funzionalità di firewall di Linux sono cambiate durante
lo sviluppo dei 2.1. Quanto si dice si applica solo alle versioni 2.0 del
kernel.
<P>Per installare e configurare la versione cui ho accesso in questo momento
occorre invocare:
<P>
<BLOCKQUOTE><CODE>
<PRE>
user% tar xvfz ipfwadm-2.3.0.tar.gz
user% cd ipfwadm-2.3.0
user% make
root# make install
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Notare che se si utilizza una versione 2.2 (o uno degli ultimi 2.1) del
kernel, <EM>ipfwadm</EM> non è lo strumento giusto per configurare il
Firewall IP. Questa versione del NET-3-HOWTO attualmente non si occupa della
nuova configurazione del firewall.
<P>
<H3>Programmi Applicativi di Rete.</H3>
<P>Gli applicativi di rete sono i programmi come <EM>telnet</EM> e
<EM>ftp</EM>, unitamente ai programmi server associati. David Holland
<CODE><dholland@cs.harvard.edu></CODE> coordina la distribuzione dei
più comuni di questi. Tale distribuzione si può ottenere
<A HREF="ftp://ftp.uk.linux.org/pub/linux/Networking/base">ftp.uk.linux.org</A>.
<P>Nel Marzo 1997 il pacchetto è stato suddiviso in pacchetti distinti
più piccoli, ma nel Maggio 1997 i programmi fondamentali sono stati
incorporati in un pacchetto chiamato <CODE>netkit-base-0.10</CODE>.
Potrebbe essere necessario procurarsi il pacchetto di base e/o pacchetti
addizionali.
<P>
<P>Per installare e configurare la versione corrente al momento della
stesura di questo documento occorre invocare i seguenti comandi:
<P>
<BLOCKQUOTE><CODE>
<PRE>
user% tar xvfz netkit-base-0.10
user% cd netkit-base-0.10
user% more README
user% vi MCONFIG
user% make
root# make install
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H3>Indirizzi.</H3>
<P>Gli indirizzi IP sono composti da 4 byte. La convenzione usata per
scrivere gli indirizzi è chiamata `dotted decimal notation',
che significa "notazione decimale con i punti". In questa forma ogni
byte è convertito in un numero decimale (tra 0 e 255) scartando
gli zeri prefissi a meno che il numero sia zero, ogni byte è
poi separato da un carattere `.'. Per convenzione ogni interfaccia di
un calcolatore o router ha associato un indirizzo IP. In certe
circostanze è permesso assegnare lo stesso indirizzo a tutte le
interfacce di un singolo calcolatore, ma solitamente ogni interfaccia
avrà un indirizzo diverso.
<P>Le reti IP sono sequenze di indirizzi IP contigui. Tutti gli indirizzi
all'interno di una rete hanno un certo numero di cifre del loro indirizzo in
comune. La porzione di indirizzo comune all'interno della rete si chiama
"network portion" (porzione di rete) dell'indirizzo.
Le cifre rimanenti si chiamano "host portion". Il numero di bit che vengono
condivisi tra tutti gli indirizzi all'interno della rete è chiamato
"netmask" ed il suo ruolo è determinare quali indirizzi appartengono
alla rete cui la maschera è applicata e quali no. Consideriamo il
seguente esempio:
<P>
<BLOCKQUOTE><CODE>
<PRE>
----------------- ---------------
Host Address 192.168.110.23
Network Mask 255.255.255.0
Network Portion 192.168.110.
Host portion .23
----------------- ---------------
Network Address 192.168.110.0
Broadcast Address 192.168.110.255
----------------- ---------------
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Ogni indirizzo sottoposto ad un'operazione di "AND bit-a-bit" con la
sua maschera di rete darà l'indirizzo della rete cui appartiene.
La maschera di rete è perciò sempre il numero più basso
all'interno dell'intervallo di indirizzi che formano quella rete, e ha sempre
la parte di host dell'indirizzo pari a zero.
<P>L'indirizzo di broadcast è un indirizzo speciale cui tutti gli host
della rete ascoltano, in aggiunta al loro proprio indirizzo.
Questo indirizzo è quello cui vengono mandati i pacchetti che devono
essere ricevuti da tutti i calcolatori della rete. Certi tipi di dati, come le
informazioni di instradamento e i messaggi di errore vengono trasmessi
all'indirizzo di broadcast in modo che tutti i calcolatori sulla rete li
possano ricevere contemporaneamente. Ci sono due standard comunemente usati su
come debba essere un indirizzo di broadcast. Il più comunemente
accettato stabilisce che debba essere usato come indirizzo di broadcast
l'indirizzo più alto possibile della rete. Nell'esempio precedente
questo sarebbe <CODE>192.168.110.255</CODE>. Per qualche ragione alcuni siti hanno
adottato la convenzione di usare l'indirizzo zero come indirizzo di broadcast.
In pratica non fa molta differenza quale viene usato, ma bisogna assicurarsi
che ogni host sulla rete sia configurato con lo stesso indirizzo di broadcast.
<P>Per ragioni amministrative, ad un certo punto durante lo sviluppo iniziale del
protocollo IP sono stati formati alcuni gruppi di arbitrari di indirizzi e le
reti sono state raggruppate in quelle che sono chiamate classi. Le classi
caratterizzano le dimensioni delle reti che si possono allocare.
Queste classi offrono un numero di dimensioni fisse di rete che possono essere
allocate. Gli intervalli scelti per le varie classi sono:
<P>
<BLOCKQUOTE><CODE>
<PRE>
----------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
----------------------------------------------------------
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
----------------------------------------------------------
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>La scelta di quali indirizzi usare per la propria rete dipende da cosa
esattamente si sta facendo. Per ottenere gli indirizzi di cui si ha bisogno
si può procedere in uno dei seguenti modi:
<DL>
<DT><B>Installare una macchina Linux su una rete IP esistente</B><DD><P>Se si
desidera installare un calcolatore su una rete esistente si deve contattare
chi amministra tale rete e chiedere loro le seguenti informazioni:
<P>
<UL>
<LI>L'indirizzo IP da assegnare al calcolatore</LI>
<LI>L'indirizzo IP di rete</LI>
<LI>L'indirizzo IP di broadcast</LI>
<LI>La netmask</LI>
<LI>L'indirizzo del router</LI>
<LI>L'indirizzo del "name server".</LI>
</UL>
<P>Dopo di che bisogna configurare l'interfaccia di rete Linux in base a quei
numeri. Non è possibile inventare dei numeri e sperare che la
configurazione funzioni.
<DT><B>Costruire una rete nuova che non si connetterà mai a Internet</B><DD><P>Se si sta preparando una rete privata e non si ha intenzione nemmeno in futuro
di connettere tale rete ad Internet, allora si può scegliere qualunque
indirizzo. Ciononostante, per ragioni di sicurezza e di coerenza ci sono alcuni
indirizzi di reti IP che sono stati riservati specificamente a questo fine.
Essi sono specificati nell'RFC1597 come segue:
<P>
<BLOCKQUOTE><CODE>
<PRE>
-----------------------------------------------------------
| RESERVED PRIVATE NETWORK ALLOCATIONS |
-----------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
-----------------------------------------------------------
| A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 |
| B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 |
| C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
-----------------------------------------------------------
</PRE>
</CODE></BLOCKQUOTE>
<P>Occorre innanzitutto decidere quanto grande deve essere la nuova rete,
e poi scegliere gli indirizzi di cui si ha bisogno.
</DL>
<P>
<H2><A NAME="ss5.2">5.2 Dove bisogna mettere i comandi di configurazione?</A>
</H2>
<P>Ci sono differenti approcci sotto Linux per le procedure di inizializzazione
del sistema. Dopo che il kernel è partito, viene sempre eseguito un
programma chiamato `<EM>init</EM>'. Il programma <EM>init</EM> poi legge il suo file
di configurazione chiamato <CODE>/etc/inittab</CODE> ed inizia il processo di boot.
Esistono versioni di <EM>init</EM> leggermente differenti, quantunque si stia
convergendo verso lo stile System V (Five), sviluppato da Miguel van
Smoorenburg.
<P>Malgrado il fatto che il programma <EM>init</EM> sia sempre lo stesso, la
configurazione di boot del sistema è organizzata in modi diversi
nelle varie distribuzioni.
<P>Solitamente il file <CODE>/etc/inittab</CODE> contiene una voce che assomiglia
a:
<P>
<BLOCKQUOTE><CODE>
<PRE>
si::sysinit:/etc/init.d/boot
</PRE>
</CODE></BLOCKQUOTE>
<P>Questa riga specifica il nome dello script di shell che gestisce praticamente
la sequenza di boot. Questo file è in qualche modo simile al file
<CODE>AUTOEXEC.BAT</CODE> in DOS.
<P>Di solito ci sono altri script che vengono chiamati dallo script di
inizializzazione, e spesso la rete è configurata all'interno di uno di
questi.
<P>La seguente tabella può essere usata come guida per il proprio
sistema:
<P>
<BLOCKQUOTE><CODE>
<PRE>
--------------------------------------------------------------------
Distrib. | Interface Config/Routing | Server Initialization
--------------------------------------------------------------------
Debian | /etc/init.d/network | /etc/rc2.d/*
--------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1 | /etc/rc.d/rc.inet2
--------------------------------------------------------------------
RedHat | /etc/rc.d/init.d/network | /etc/rc.d/rc3.d/*
--------------------------------------------------------------------
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Si noti che Debian e Red Hat usano un'intera directory per ospitare gli
script che attivano i servizi di sistema. Gli script di solito non contengono
al loro interno le informazioni di configurazione necessarie. Ad esempio nei
sistemi RedHat gli script di inizializzazione (boot script) si aspettano di
trovarle nei file presenti in <CODE>/etc/sysconfig</CODE>. Se si vogliono
comprendere i dettagli del processo di boot, suggerisco di dare un occhiata a
<EM>/etc/inittab</EM> e alla documentazione associata a <EM>init</EM>.
Linux Journal sta per pubblicare un articolo sulla inizializzazione del sistema,
e a questo documento verrà aggiunto un puntatore ad esso non appena
sarà disponibile sul web.
<P>
<P>La maggior parte delle distribuzioni moderne includono un programma che
permette di configurare la maggior parte dei tipi diffusi di interfacce
di rete. Se si ha una di queste, allora bisognerebbe controllare se tale
programma fa quello di cui si ha bisogno prima di tentare una
configurazione manuale.
<P>
<BLOCKQUOTE><CODE>
<PRE>
-----------------------------------------
Distrib | Network configuration program
-----------------------------------------
RedHat | /usr/bin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H2><A NAME="ss5.3">5.3 Creazione delle interfacce di rete.</A>
</H2>
<P>In molti sistemi Unix le periferiche di rete hanno il loro posto nella
directory <EM>/dev</EM>. Questo non succede in Linux, dove i dispositivi di
rete sono creati dinamicamente via software e quindi non hanno bisogno della
presenza di file speciali.
<P>Nella maggior parte dei casi i dispositivi di rete sono creati automaticamente
dal driver durante la sua inizializzazione dopo che l'hardware è stato
riconosciuto. Per esempio, il driver per la rete ethernet crea le interfacce
<CODE>eth[0..n]</CODE> sequenzialmente, nell'ordine in cui le schede ethernet
vengono riconosciute. La prima scheda che viene trovata prende il nome
<CODE>eth0</CODE>, la seconda <CODE>eth1</CODE>, eccetera.
<P>Ciononostante in alcuni casi, come succede per <EM>slip</EM> e <EM>ppp</EM>, i
dispositivi di rete vengono creati a seguito di operazioni svolte da un
programma. Si applica la stessa regola di numerazione sequenziale, ma le
periferiche non sono create automaticamente all'accensione del sistema.
La ragione di questo è che, a differenza di quello che accade per le
schede ethernet, il numero di periferiche <EM>slip</EM> o <EM>ppp</EM> può
cambiare durante la vita della macchina. Questi casi vengono analizzati in
maggior dettaglio nelle sezioni successive.
<P>
<H2><A NAME="ss5.4">5.4 Configurazione delle interfacce di rete.</A>
</H2>
<P>Dopo aver recuperato tutti i programmi di cui si ha bisogno e tutti gli
indirizzi e le informazioni sulla rete, si può procedere alla
configurazione delle proprie interfacce di rete. Quando si parla di
configurazione dell'interfaccia si intende il processo di assegnazione degli
indirizzi appropriati alla periferica e all'assegnazione di valori appropriati
per gli altri valori configurabili di un dispositivo di rete. Il programma
più comunemente usato per questo compito è il comando
<EM>ifconfig</EM> (interface configure).
<P>Normalmente viene invocato un comando simile al seguente:
<P>
<BLOCKQUOTE><CODE>
<PRE>
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>In questo esempio si è configurata una scheda ethernet `<CODE>eth0</CODE>'
con l'indirizzo IP `<CODE>192.168.0.1</CODE>' e una maschera pari
a `<CODE>255.255.255.0</CODE>'. La parola `<EM>up</EM>' finale significa che l'interfaccia
deve essere attivata, ma può di solito essere omessa, dato che è
l'opzione di default.
<P>Il kernel assume alcuni valori di default quando un'interfaccia viene
configurata. Per esempio, si può specificare l'indirizzo di rete e
quello di broadcast per un'interfaccia, ma se questo non viene fatto, come
nell'esempio precedente, il kernel farà delle scelte ragionevoli per i
valori da assegnare in base alla maschera di rete fornita; se non viene
fornita una maschera di rete si baserà sulla classe della rete associata
all'indirizzo IP. Nell'esempio appena visto il kernel assegnerà un
indirizzo di rete `<CODE>192.168.0.0</CODE>' e un indirizzo di broadcast
`<CODE>192.168.0.255</CODE>' in base alla netmask specificata nel comando.
<P>Si possono passare al comando <EM>ifconfig</EM> molte altre opzioni. Le più
importanti di queste sono:
<P>
<DL>
<DT><B>up</B><DD><P>questa opzione attiva l'interfaccia (ed è
l'impostazione di default).
<P>
<DT><B>down</B><DD><P>questa opzione la disattiva.
<P>
<DT><B>[-]arp</B><DD><P>questa opzione abitita o disabilita l'uso del
protollo ARP ("Address Resulution Protocol") per questa
interfaccia.
<P>
<DT><B>[-]allmulti</B><DD><P>questa opzione abilita o disabilita la ricezione
di tutti i pacchetti multicast. Il multicast permette di
associare speciali indirizzi hardware di destinazione a gruppi
di calcolatori, in modo che tutti gli appartenenti al gruppo
ricevano certi pacchetti. Questa opzione può essere
importante se si usano applicazioni come la videoconferenza ma
normalmente non viene usata.
<P>
<DT><B>mtu N</B><DD><P>questo parametro permette di assegnare il valore MTU
("Maximum Transfer Unit") per questa periferica.
<P>
<DT><B>netmask addr</B><DD><P>questo parametro permette di specificare la maschera
relativa alla rete cui questa interfaccia appartiene.
<P>
<DT><B>irq addr</B><DD><P>questo parametro funziona solo con certi tipi di hardware
e permette di scegliere la linea interruzione usata
dall'hardware di questa interfaccia.
<P>
<DT><B>[-]broadcast [addr]</B><DD><P>questo parametro permette di
abilitare la ricezione di pacchetti di broadcast e assegna
l'indirizzo di broadcast per questa interfaccia, oppure
disabilita la ricezione di tali pacchetti.
<P>
<DT><B>[-]pointopoint [addr]</B><DD><P>questo parametro permette di
assegnare l'indirizzo della macchina che sta all'altro capo
di una connessione punto-a-punto, come accade per <EM>slip</EM>
e <EM>ppp</EM>.
<P>
<DT><B>hw <type> <addr></B><DD><P>questo parametro permette di assegnare
l'indirizzo hardware di certi tipi di schede di rete. Questo
è spesso inutile per per le interfaccie ethernet,
ma è comodo per altri tipi di rete, come AX.25.
</DL>
<P>
<P>Il comando <EM>ifconfig</EM> può essere usato per agire su tutte le
interfacce di rete. Alcuni programmi utente come <EM>pppd</EM> e <EM>dip</EM>
configurano automaticamente le periferiche di rete quando le creano, e in
questi casi l'uso manuale di <EM>ifconfig</EM> diventa inutile.
<P>
<H2><A NAME="ss5.5">5.5 Configurazione del risolutore dei nomi (name resolver).</A>
</H2>
<P>Il `<EM>Name Resolver</EM>' fa parte della libreria standard di Linux.
La sua funzione principale è quella di fornire un servizio che converta
i nomi dei calcolatori, quelli comprensibili all'uomo come
`<CODE>ftp.funet.fi</CODE>', in indirizzi comprensibili alle macchine, come
<CODE>128.214.248.6</CODE>.
<P>
<H3>Cosa compone un nome?</H3>
<P>Anche chi ha familiarità con i nomi degli host che costituiscono Internet
potrebbe non comprendere come sono costituiti. I nomi di dominio (domain
name) di Internet sono inerentemente gerarchici, hanno cioè una
struttura ad albero. Un `<EM>dominio</EM>' (domain) è una famiglia,
un gruppo di nomi. Un dominio può essere suddiviso in vari
`<EM>sottodomini</EM>'. Un `<EM>dominio pricipale</EM>' (toplevel domain) è
un dominio che non è un sottodominio. I domini principali sono
specificati nell'RFC 920. I domini principali più comuni sono:
<P>
<DL>
<DT><B>COM</B><DD><P>Organizzazioni commerciali
<DT><B>EDU</B><DD><P>Organizzazioni educative
<DT><B>GOV</B><DD><P>Organizzazioni governative
<DT><B>MIL</B><DD><P>Organizzazioni militari
<DT><B>ORG</B><DD><P>Altre organizzazioni
<DT><B>NET</B><DD><P>Organizzazioni connesse a Internet
<DT><B>Identificativo nazionale</B><DD><P>questi sono codici di due lettere
che rappresentano la nazione.
</DL>
<P>
<P> Per ragioni storiche la maggior parte dei domini che appartengono ai
domini principali non nazionali sono stati usati da organizzazioni con sede
negli Stati Uniti, malgrado gli Stati Uniti abbiano anche un proprio dominio
nazionale `<CODE>.us</CODE>'. Questo non è più vero per i domini
<CODE>.com</CODE> and <CODE>.org</CODE>, che vengono comunemente usati da società e
organizzazioni non statunitensi.
<P>
<P>Ognuno di questi domini pricipali ha i suoi sottodomini. I domini
principali basati sui nomi di nazione sono spesso suddivisi in sottodomini
come <CODE>com</CODE>, <CODE>edu</CODE>, <CODE>gov</CODE>, <CODE>mil</CODE> e <CODE>org</CODE>.
Questo non succede in Italia, ma per esempio esistono i sottodomini
<CODE>com.au</CODE> e <CODE>gov.au</CODE> per le organizzazioni commerciali e governative
in Australia; da notare che questa non è una regola generale, dato che
le linee effettive di condotta dipendono dalle autorità che gestiscono
a livello locale l'assegnazione dei nomi.
<P>
<P>Il livello successivo di divisione spesso rappresenta il nome
dell'organizzazione. I sottodomini ulteriori possono essere di diversa natura;
spesso il livello successivo è basato sulla suddivisione interna della
organizzazione, ma può essere basato su qualsiasi criterio che sia
considerato ragionevole e significativo all'interno dell'organizzazione.
<P>
<P>La parte più a sinistra del nome è sempre il nome univocamente
assegnato ad un calcolatore, e si chiama `<EM>hostname</EM>'. La parte di nome che
sta alla destra del "hostname" si chiama `<EM>domainname</EM>', e il nome completo
si chiama `<EM>Fully Qualified Domain Name</EM>', abbreviato FQDN.
<P>Usando l'host di Terry come esempio, il FQDN è
`<CODE>perf.no.itg.telstra.com.au</CODE>'. Questo significa che il suo "hostname"
è `<CODE>perf</CODE>', e il "domain name" è `<CODE>no.itg.telstra.com.au</CODE>'.
Il suo "domain name" è composto da un dominio principale basato sul nome
della sua nazione, l'Australia, e poiché il suo indirizzo di posta
elettronica appartiene ad un organizzazione commerciale c'è
`<CODE>.com</CODE>' come sottodominio. Il nome della compagnia è (era)
`<CODE>telstra</CODE>', e la sua struttura di nomi interna è basata sulla
struttura gestionale, in questo caso il calcolatore appartiene al gruppo di
tecnologia delle informazioni (Information Technology Group), sezione
operazioni di rete (Network Operations).
<P>
<P>Di solito, i nomi sono un po' più brevi; ad esempio il mio ISP
(Internet Service Provider = fornitore di accesso a internet) si chiama
`<CODE>systemy.it</CODE>' e la mia organizzazione senza scopo di lucro si chiama
`<CODE>linux.it</CODE>', senza nessun sottodominio <CODE>com</CODE> e <CODE>org</CODE> , così
che il mio host personale si chiama `<CODE>morgana.systemy.it</CODE>' e
<CODE>rubini@linux.it</CODE> è un indirizzo di posta elettronica valido.
Da notare che chi amministra un dominio può registrare nomi di singoli
host come anche sottodomini; ad esempio il LUG a cui appartengo usa il dominio
<CODE>pluto.linux.it</CODE>, poiché i titolari di <CODE>linux.it</CODE> hanno
acconsentito a creare un sottodominio per il LUG.
<P>
<H3>Quali informazioni sono necessarie.</H3>
<P>Per accedere al servizio di risoluzione dei nomi occorre sapere a quale
dominio appartiene il proprio calcolatore. Il software di risoluzione dei
nomi offre il servizio di traduzione dei nomi facendo delle richieste ad un
`<EM>Domain Name Server</EM>' (di solito chiamato semplicemente `name server'),
per cui occorre anche conoscere l'indirizzo di un name server locale che offra
questo servizio.
<P>Per configurare il proprio calcolatore occorre sistemare tre file, che
descriverò uno alla volta.
<P>
<H3>/etc/resolv.conf</H3>
<P>Il file <CODE>/etc/resolv.conf</CODE> è il file di configurazione
principale per accedere al servizio di risoluzione dei nomi. Il suo formato
è abbastanza semplice: si tratta di un file di testo con una parola
chiave (direttiva) per linea. Le direttive comunemente usate sono tre:
<P>
<DL>
<DT><B>domain</B><DD><P>questa direttiva specifica il nome del dominio locale.
<DT><B>search</B><DD><P>questa direttiva specifica una lista di domini
da consultare in alternativa.
<DT><B>nameserver</B><DD><P>questa direttiva, che può essere usata
più di una volta, specifica l'indirizzo IP di un name
server a cui rivolgersi per la risoluzione dei nomi.
</DL>
<P>
<P>Per esempio, <CODE>/etc/resolv.conf</CODE> potrebbe essere qualcosa di
simile a:
<BLOCKQUOTE><CODE>
<PRE>
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Questo esempio specifica che il dominio di default da usare per i nomi
non qualificati (cioè gli hostname senza un dominio associato)
è <CODE>maths.wu.edu.au</CODE>, e che se l'host non viene trovato in
quel dominio bisogna provare direttamente anche il dominio <CODE>wu.edu.au</CODE>.
Il file specifica anche due name server, ciascuno dei quali può
essere consultato dal software di risoluzione per risolvere un nome.
<P>
<H3>/etc/host.conf</H3>
<P>Il file <CODE>/etc/host.conf</CODE> è quello dove si dichiarano alcuni
elementi che governano il comportamento del codice di risoluzione dei nomi.
Il formato di questo file è descritto in dettaglio nella pagina del
manuale di `<CODE>resolv+</CODE>'. In quasi tutti i casi queste due linee sono tutto
quello che serve:
<P>
<BLOCKQUOTE><CODE>
<PRE>
order hosts,bind
multi on
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Questa configurazione dice al codice di risoluzione dei nomi di controllare
il file <CODE>/etc/hosts</CODE> prima di tentare una ricerca attraverso un name
server, e dice di ritornare tutti gli indirizzi definiti per un host descritto
in <CODE>/etc/hosts</CODE>, invece che ritornare solo il primo.
<P>
<H3>/etc/hosts</H3>
<P>Il file <CODE>/etc/hosts</CODE> è quello che contiene i nomi e gli
indirizzi IP dei calcolatori locali. Se un host appare in questo file non
occorre interrogare un name server per conoscere il suo indirizzo IP.
Lo svantaggio di questo tipo di approccio è che occorre aggiornare
questo file ogniqualvolta l'indirizzo IP relativo ad un calcolatore cambia.
Solitamente, in un sistema ben gestito le uniche voci che appaiono in questo
file sono una per l'interfaccia di loopback e una per il nome del calcolatore
stesso.
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 this.host.name
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>È possibile specificare più di un nome di calcolatore
per linea, come dimostrato dalla prima voce qui sopra, che è il
modo convenzionale per dare un nome all'interfaccia di loopback.
<P>
<H3>Attivare un name server</H3>
<P>Se si desidera far girare un name server locale, lo si può fare
facilmente. Si prega di fare riferimento al
<A HREF="DNS-HOWTO.html">DNS-HOWTO</A> e a ogni documento incluso nella propria versione di
<EM>BIND</EM> (Berkeley Internet Name Domain).
<P>
<H2><A NAME="ss5.6">5.6 Configurazione dell'interfaccia di loopback.</A>
</H2>
<P>L'interfaccia `<CODE>loopback</CODE>' è un tipo speciale di interfaccia che
permette ad un calcolatore di effettuare connessioni con se stesso. Ci sono
diversi motivi per cui capita di aver bisogno di farlo; per esempio quando
occorre verificare il funzionamento di programmi di rete senza interferire
con nessun altro sulla rete. Per convenzione è stato assegnato
all'interfaccia di loopback l'indirizzo IP `<CODE>127.0.0.1</CODE>'. Perciò,
indipendentemente dal calcolatore sul quale si lavora, se si apre una
connessione telnet a <CODE>127.0.0.1</CODE> si raggiungerà sempre la macchina
da cui si è partiti.
<P>La configurazione dell'interfaccia di loopback è semplice, ed è
una cosa che bisogna assicurarsi di fare (ma da notare che di solito tale
compito è svolto dagli script standard di inizializzazione).
<P>
<BLOCKQUOTE><CODE>
<PRE>
root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Il comando <EM>route</EM> verrà trattato più estesamente nella
prossima sezione.
<P>
<H2><A NAME="ss5.7">5.7 Routing.</A>
</H2>
<P>Il "routing", ovvero le questioni relative all'instradamento dei pacchetti,
costituisce un argomento ampio. Si possono facilmente scrivere grossi libri su
queste tematiche. La maggior parte delle persone, comunque, hanno
necessità di instradamento abbastanza semplici, mentre poche altre
hanno esigenze più complicate. Tratterò qui solo i concetti
fondamentali dell'instradamento dei pacchetti. Suggerisco a chi è
interessato ad avere informazioni più dettagliate di consultare i
manuali elencati all'inizio di questo documento.
<P>Inizierei con una definizione. Cos'è l'instradamento IP? Questa è
la definizione che uso io:
<P>
<P>
<BLOCKQUOTE>
L'instradamento IP (routing) è il procedimento
attraverso il quale un calcolatore con connessioni di rete multiple
decide dove trasmettere i pacchetti IP che ha ricevuto.
</BLOCKQUOTE>
<P>
<P>Potrebbe essere utile illustrare questa definizione con un esempio.
Immaginiamo un tipico router in un ufficio, che abbia una connessione PPP
verso Internet, un certo numero di segmenti ethernet che collegano le
postazioni locali e un secondo collegamento PPP verso un altro ufficio.
Quando il router riceve un pacchetto da una qualsiasi delle sue connessioni di
rete, il meccanismo usato per determinare su quale interfaccia deve essere
spedito il pacchetto è proprio il routing.
Anche gli host più semplici hanno bisogno di instradare i pacchetti,
tutti gli host di Internet hanno infatti due interfacce di rete:
una è quella di loopback descritta prima e l'altra è
queslla usata per comunicare col resto della rete; questa può
essere una ethernet oppure un collegamento su porta seriale PPP o SLIP.
<P>Bene, ma come funziona l'instradamento? Ogni host mantiene una lista di regole
di instradamento, chiamata "routing table". Questa tabella contiene delle voci
che sono in genere formate da almeno tre campi: il primo è l'indirizzo
di destinazione, il secondo è il nome dell'interfaccia attraverso la
quale instradare il pacchetto, e il terzo è l'indirizzo IP opzionale di
un'altra macchina che si incarichi di decidere il prossimo passo che il
pacchetto deve fare attraverso la rete. In Linux la tabella di instradamento
può essere visualizzata usando il seguente comando:
<P>
<BLOCKQUOTE><CODE>
<PRE>
user% cat /proc/net/route
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>oppure uno dei seguenti:
<P>
<BLOCKQUOTE><CODE>
<PRE>
user% /sbin/route -n
user% /bin/netstat -r
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Il procedimento di instradamento è abbastanza semplice:
viene ricevuto un pacchetto, viene esaminato il suo indirizzo di destinazione
(a chi è destinato quel pacchetto) e tale indirizzo viene confrontato
con tutte le voci della tabella. La voce che meglio rispecchia l'indirizzo di
destinazione viene poi usata per la ritrasmissione del pacchetto, attraverso
l'interfaccia specificata dalla voce. Se poi il campo `gateway' di questa voce
è valido il pacchetto viene passato a tale host attraverso l'interfaccia
specificata; in caso contrario si assume che l'indirizzo di destinazione sia
sulla rete connessa all'interfaccia scelta.
<P>Per manipolare la tabella esiste un comando specifico. Questo comando riceve
degli argomenti sulla linea di comando e li converte in chiamate di sistema
che richiedono al kernel di aggiungere, rimuovere o modificare le voci della
tabella di routing. Tale comando si chiama `<EM>route</EM>'.
<P>Passiamo ora ad un semplice esempio, immaginando che voi siate connessi
ad una ethernet e che vi sia stato detto che la rete è una classe C
con indirizzo <CODE>192.168.1.0</CODE>; immaginiamo inoltre che l'indirizzo
<CODE>192.168.1.10</CODE> sia stato assegnato alla vostra macchina, e che
<CODE>192.168.1.1</CODE> sia il router connesso al resto di Internet.
<P>Il primo passo da fare è configurare l'interfaccia come descritto in
precedenza. A questo fine si userà un comando tipo:
<P>
<BLOCKQUOTE><CODE>
<PRE>
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Adesso occorre aggiungere nella tabella di routing una voce che dica al
kernel che tutti i pacchetti destinati a calcolatori con indirizzi del tipo
<CODE>192.168.1.*</CODE> devono essere spediti sull'interfaccia ethernet.
Il comando per dire ciò sarà:
<P>
<BLOCKQUOTE><CODE>
<PRE>
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
</PRE>
</CODE></BLOCKQUOTE>
<P>Si noti l'uso dell'argomento `<CODE>-net</CODE>', che dice al programma "route"
che questa voce si riferisce ad un'intera rete. L'altra possibilità
è quella di specificare una regola di tipo `<CODE>-host</CODE>', cioè
una regola di instradamento specifica ad un singolo indirizzo IP.
<P>La regola di instradamento appena mostrata è quella che permette di
stabilire connessioni con tutti gli host del proprio segmento ethernet.
Ma come si fa a connettersi a tutte le macchine che non sono sul proprio ramo
ethernet?
<P>Dover aggiungere regole di instradamento per tutte le possibili reti sarebbe un
lavoro molto difficile; perciò esiste un trucco per semplificare questo
compito. Il trucco si chiama "regola di instradamento di `<CODE>default</CODE>'".
La regola "di default" si riferisce a tutti gli indirizzi di destinazione, ma
in modo "blando", cosicch se esiste un'altra voce nella tabella che si
riferisce all'indirizzo di destinazione del pacchetto, questa voce verrà
usata al posto di quella di default. L'idea della regola di <CODE>default</CODE>
è semplicemente quella di dire "e tutto il resto deve andare qui".
Nell'esempio di cui ci stiamo occupando si userà un comando come:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# route add default gw 192.168.1.1 eth0
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>L'argomento `<CODE>gw</CODE>' dice al comando `route' che l'argomento seguente
è l'indirizzo numerico, o il nome, di una macchina che fa da gateway, o
router, cui devono essere spediti tutti i pacchetti ai quali questa regola si
applica, ai fini di un ulteriore instradamento.
<P>Perciò, la vostra configurazione completa sarà:
<P>
<BLOCKQUOTE><CODE>
<PRE>
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add default gw 192.168.1.1 eth0
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Guardando attentamente i file di configurazione di rete che si trovano
sulle macchine Linux troverete che almeno uno di essi sarà molto simile
a quello appena mostrato. Questo tipo di configurazione è molto diffuso.
<P>Vediamo ora una configurazione dell'instradamento leggermente più
complicata. Immaginiamo di configurare il router che abbiamo visto prima,
quello con la connessione PPP verso Internet e i segmenti ethernet verso i
calcolatori nell'ufficio. Immaginiamo che il router abbia tre segmenti
ethernet e un collegamento PPP. La nostra configurazione di routing
sarà qualcosa come:
<P>
<BLOCKQUOTE><CODE>
<PRE>
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
root# route add default ppp0
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Ognuna delle workstation sulla rete locale userà la forma più semplice presentata prima, solo il router deve specificare separatamente le informazioni relativa a ciascun tratto della rete locale, perché per le workstation il meccanismo della regola di <CODE>default</CODE> si occuperà di tutte le sottoreti, lasciando al router il compito di suddividere correttamente i pacchetti. Ci si può chiedere perché la regola di default appena vista per il router non specifichi un `<CODE>gw</CODE>'. La
ragione è semplice: i protocolli su linea seriale come PPP e SLIP
hanno sempre e solo due calcolatori sulla loro "rete": uno ad ogni estremo.
Specificare il calcolatore che si trova all'altro estremo del cavo come
`gateway' è inutile e ridondante, poiché non esistono altre
possibilità, e per questo motivo non occorre esplicitare il gateway
per questo tipo di connessioni. Altri tipi di rete, come ethernet, arcnet o
token ring, richiedono invece che si specifichi il numero del gateway,
poiché queste reti permettono a molti calcolatori di essere collegati
insieme.
<P>
<H3>Allora a cosa serve il programma routed?</H3>
<P>La configurazione di routing descritta fino adessso si applica bene a
situazioni di rete semplici, dove c'è sempre solo un singolo percorso
possibile per una data destinazione. Se la propria rete è più
complessa, le cose diventano più complicate. Fortunatamente per la
maggior parte delle persone questo non è un problema.
<P>Il problema principale con il cosiddetto `instradamento manuale' o
`instradamento statico' come quello appena descritto è che se un
calcolatore o un collegamento all'interno della propria rete smette di
funzionare, l'unico modo (se possibile) per dirigere i pacchetti su di
un'altra strada consiste nell'intervenire a mano ed eseguire i comandi
appropriati. Naturalmente questo è impegnativo, lento, poco pratico e
rischia di fallire. Sono state sviluppate varie tecniche per correggere
automaticamente le tabelle di routing in caso di problemi sulla rete quando
ci siano percorsi alternativi. Tutte queste tecniche sono raggruppate sotto
il nome di "protocolli dinamici di instradamento".
<P>Può essere capitato a tutti di sentir nominare i protocolli dinamici
più usati. I più comuni probabilmente sono RIP
(Routing Information Protocol) e OSPF (Open Shortest Path First).
Il protocollo RIP è molto comune nelle reti piccole, come le reti di
organizzazioni di dimensione medio-piccola, o reti situate in un unico
edificio. OSPF è più moderno e più in grado di gestire
grosse configurazioni di rete, e pure più adatto ad ambienti dove
esistono molti percorsi possibili attraverso la rete.
Le implementazioni più diffuse di questi protocolli sono `<EM>routed</EM>'
(per RIP), e `<EM>gated</EM>' (per RIP, OSPF e altri protocolli). Il programma
`<EM>routed</EM>' di solito fa parte delle distribuzioni di Linux, oppure si
può trovare incluso nel pacchetto `NetKit' descritto all'inizio.
<P>Un esempio di dove e quando serva usare un protocollo di instradamento dinamico
potrebbe somigliare al seguente:
<P>
<BLOCKQUOTE><CODE>
<PRE>
192.168.1.0 / 192.168.2.0 /
255.255.255.0 255.255.255.0
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
/-----\
| |
| C |
| |
\-----/
|eth0
|
|---------|
192.168.3.0 /
255.255.255.0
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Ci sono qui tre router: A, B e C. Ognuno di essi è connesso ad una
ethernet che porta una rete di classe C (netmask 255.255.255.0).
Ogni router ha anche una connessione PPP verso ognuno degli altri due
router. La rete forma un triangolo.
<P>Dovrebbe essere chiaro che la tabella di routing per il router A dovrebbe
essere presente qualcosa come:
<P>
<BLOCKQUOTE><CODE>
<PRE>
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Questa situazione funzionerebbe bene, finché non si interrompesse il
collegamento tra il router A e il router B. Se la connessione si interrompe,
la tabella di instradamento mostrata non permetterebbe ai calcolatori sul
segmento ethernet A di raggiungere calcolatori sul segmento B, perché i
loro pacchetti sarebbero rediretti da A sulla connessione ppp0, che è
momentaneamente caduta. I calcolatori sulla rete A possono comunque continuare
a parlare ai calcolatori sulla rete C, e questi ultimo possono continuare a
parlare con i calcolatori sulla rete B, poiché il collegamento tra B e
C è ancora funzionante.
<P>Ma allora, se A può parlare a C, e C può ancora parlare a B,
perché non potrebbe A mandare i suoi pacchetti a B attraverso C?
Questo è esattamente il tipo di problemi che viene affrontato dai
protocolli dinamici come RIP. Se ognuno dei router A, B e C facesse girare un
programma demone di instradamento, allora le loro tabelle di routing sarebbero
corrette automaticamente per riflettere in nuovo stato della rete
ogniqualvolta uno dei collegamenti della rete si interrompesse.
Configurare questa rete è semplice: occorre fare solo due cose su
ognuno dei router. In questo caso, per A bisogna invocare:
<P>
<BLOCKQUOTE><CODE>
<PRE>
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Il demone `<EM>routed</EM>' trova automaticamente le interfacce di rete
attive nel momento in cui viene invocato, e successivamente manda dei
messaggi e ascolta le risposte su ogni interfaccia di rete, in modo da poter
determinare la routing table ed aggiornarla.
<P>Questo termina la breve spiegazione dell'instradamento dinamico e dove
è il caso di usarlo. Se si vogliono più informazioni al
proposito occorre riferirsi alle fonti di informazione elencate
all'inizio di questo documento.
<P>I punti importanti relativi all'instradamento dinamico sono:
<P>
<OL>
<LI>È necessario eseguire un demone per gestire un protocollo
di instradamento dinamico solo quando la propria macchina
Linux ha la possibilità di selezionare tra piu d'un
percorso possibile per una stessa destinazione.
</LI>
<LI>Il programma di instradamento dinamico modifica automaticamente
la tabella di intradamento perché rispecchi i
cambiamenti della rete.
</LI>
<LI>RIP ben si presta alla gestione di reti piccole e medie.
</LI>
</OL>
<P>
<H2><A NAME="ss5.8">5.8 Configurazione dei servizi di rete e dei programmi server.</A>
</H2>
<P>I programmi "server" ed i servizi di rete sono quei programmi che
permettono ad un utente remoto di utilizzare la macchina Linux locale.
I programmi server attendono le connessioni entranti su di una porta di rete.
Le porte sono un mezzo per indirizzare un particolare servizio su di un
particolare calcolatore e sono il modo in cui un calcolatore server può
distinguere tra una connessione entrante di tipo telnet ed una di tipo ftp.
L'utente remoto stabilisce una connessione di rete con la macchina server e
il programma server (anche detto "daemon" di rete) che sta attendendo una
connessione su quella porta accetta la connessione ed inizia a funzionare.
Ci sono due modi di utilizzare i servizi di rete, entrambi usati comunemente
nella pratica. Questi modi sono:
<P>
<DL>
<P>
<P>
<DT><B>standalone (da solo)</B><DD><P>. Il programma di rete ascolta una
porta specifica di rete e quando avverte una connessione in
ingresso la gestisce da solo per fornire il servizio richiesto.
<P>
<P>
<DT><B>dipendente dal server <EM>inetd</EM></B><DD><P>Il server <EM>inetd</EM>
è un programma-demone speciale di rete che si occupa di
gestire le connessioni in ingresso. <EM>inetd</EM> fa uso di un
file di configurazione che gli dice quale programma deve
essere invocato quando viene ricevuta una connessione entrante
su una particolare porta. Una porta può essere
configurata per entrambi i protocolli, tcp o udp. Le porte
stesse sono descritte in un altro file, di cui si
parlerà presto.
<P>
</DL>
<P>
<P>Ci sono due file importanti che occorre configurare per usare inetd:
<CODE>/etc/services</CODE> assegna dei nomi simbolici ai numeri delle porte,
mentre <CODE>/etc/inetd.conf</CODE> è il file di configurazione per il
programma <EM>inetd</EM>.
<P>
<H3>/etc/services</H3>
<P>Il file <CODE>/etc/services</CODE> è un semplice database che associa ad
ogni numero di porta comprensibile alla macchina un nome comprensibile
all'uomo. Il suo formato è molto semplice: il file è un testo
ciascuna riga del quale rappresenta una voce del database. Ogni voce è
composta da tre campi separati da un numero qualunque di spazi bianchi (spazi
o caratteri `tab'). I campi sono:
<P>
<PRE>
nome porta/protocollo alias # commento
</PRE>
<P>
<DL>
<P>
<P>
<DT><B>nome</B><DD><P>è una singola parola che rappresenta il
servizio che si sta descrivendo.
<P>
<P>
<DT><B>porta/protocollo</B><DD><P>questo campo è diviso in due
sottocampi.
<P>
<DL>
<P>
<DT><B>porta</B><DD><P>un numero che specifica il numero di porta
sulla quale il servizio è reso disponibile. La
maggior parte dei servizi comunemente usati hanno un
numero assegnato loro.
Questi numeri sono descritti nel <CODE>RFC-1340</CODE>.
<P>
<DT><B>protocollo</B><DD><P>questo sottocampo è o
"<CODE>tcp</CODE>" o "<CODE>udp</CODE>".
</DL>
<P>È importante notare che un valore pari a <CODE>18/tcp</CODE>
è molto differente da <CODE>18/udp</CODE> e che non ci sono
ragioni tecniche per cui un servizio debba esistere su entrambe le
porte. Normalmente si usa il buon senso, e il database contiene
entrambe le voci solo se un servizio è disponibile sia
attraverso <CODE>tcp</CODE> che attraverso <CODE>udp</CODE>.
<P>
<P>
<DT><B>alias</B><DD><P>altri nomi che possono essere usati per indicare
questo servizio.
<P>
</DL>
<P>
<P>Tutto il testo che appare in una riga dopo un carattere `<CODE>#</CODE>' è
trattato come commento.
<P>
<H3>Un file /etc/services di esempio.</H3>
<P>Tutte le distribuzioni recenti di Linux contengono un buon file
<CODE>/etc/services</CODE>.
Nel caso occorra configurare un calcolatore da zero, questa è una
copia del file <CODE>/etc/services</CODE> fornito con una vecchia distribuzione
<A HREF="http://www.debian.org/">Debian</A>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Si noti che attualmente la politica dello IANA è di assegnare
# un singolo numero di porta per entrambi TCP e UDP; perciò la maggior
# parte delle voci sono duplicate, anche se il protocollo non funziona
# con UDP.
# Aggiornato dall'RFC 1340, ``Assigned Numbers'' (Luglio 1992).
# Non sono incluse tutte le porte, solo le più comuni.
tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 - reserved
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp # Interim Mail Access Proto v2
imap2 143/udp
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman's Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin' (v5)
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
kerberos-adm 749/tcp # Kerberos `kadmin' (v5)
#
webster 765/tcp # Network dictionary
webster 765/udp
#
# From ``Assigned Numbers'':
#
#> Le "porte registrate" non sono controllate dallo IANA e su molti
#> sistemi possono essere usate da ordinari processi dell'utente
#> o programmi eseguiti da utenti non privilegiati.
#
#> Le porte sono usate in TCP [45,106] per dare un nome agli estremi
#> di connessioni logiche che trasportano conversazioni a lungo termine.
#> Al fine di fornire servizi ad anonimi, viene definita
#> una porta di contatto per il servizio. Questa lista specifica
#> la porta usata dal processo server come porta di contatto. Anche se
#> lo IANA non può controllare l'uso di queste porte, registra
#> comunque queste porte e riconosce il loro uso per la convenienza
#> della comunità.
#
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually uses UDP only
bbs 7000/tcp # BBS service
#
#
# Servizi Kerberos (Progetto Athena/MIT)
# Si noti che questi servizi sono usati da Kerberos versione 4,
# e non sono ufficiali. Chi usa la versione 4 dovrebbe scommentare
# queste voci e commentare quelle per la versione 5 definite più sopra.
#
kerberos4 750/udp kdc # Kerberos (server) udp
kerberos4 750/tcp kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos "passwd"
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
#
# Servizi non ufficiali ma necessari per NetBSD
#
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
#
# Servizi "Datagram Delivery Protocol"
#
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
#
# Servizi Debian GNU/Linux
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
cfinger 2003/tcp # GNU Finger
postgres 4321/tcp # POSTGRES
mandelspawn 9359/udp mandelbrot # network mandelbrot
# Local services
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>In realtà il file effettivo è in continua crescita dato che
vengono continuamente creati nuovi servizi. Se si teme che la propria copia
sia incompleta, si suggerisce di copiare un nuovo <CODE>/etc/services</CODE> da
una distribuzione recente.
<P>
<H3>/etc/inetd.conf</H3>
<P>Il file <CODE>/etc/inetd.conf</CODE> è il file di configurazione per il
server di rete <EM>inetd</EM>. La sua funzione è quella di dire a
<EM>inetd</EM> cosa fare quando riceve una richiesta di connessione per un
particolare servizio.
Bisogna dire ad <EM>inetd</EM> quale server demone di rete far partire per ciascun
servizio che si vuole fornire, bisogna anche dire come farlo partire.
<P>Il formato del file è abbastanza semplice: si tratta di un file di
testo in cui ogni riga descrive un servizio che si intende offrire. Tutto
quello che in una linea segue un segno <CODE>#</CODE> è ignorato e considerato
un commento. Ogni linea contiene sette campi separati da un numero qualsiasi
di spazi bianchi (tab o carattere di spazio). Il formato generale è:
<P>
<BLOCKQUOTE><CODE>
<PRE>
service socket_type proto flags user server_path server_args
</PRE>
</CODE></BLOCKQUOTE>
<P>
<DL>
<P>
<DT><B>service</B><DD><P>è il servizio al quale si riferisce questa
riga, è cioè uno dei nomi che stanno nel file
<CODE>/etc/services</CODE>.
<P>
<P>
<DT><B>socket_type</B><DD><P>questo campo descrive il tipo di socket cui
questa voce si riferisce, i cui valori validi sono:
<CODE>stream</CODE>, <CODE>dgram</CODE>, <CODE>raw</CODE>, <CODE>rdm</CODE>, o <CODE>seqpacket</CODE>.
Questa questione è abbastanza tecnica, ma come regola
pratica basti ricordare che quasi tutti i servizi basati su
<CODE>tcp</CODE> usano <CODE>stream</CODE> e quasi tutti i servizi basati su
<CODE>udp</CODE> usano <CODE>dgram</CODE>. Solo servizi molto particolari
useranno uno degli altri valori.
<P>
<P>
<DT><B>proto</B><DD><P>il protocollo usato da questa voce. Questo deve
corrispondere alla voce appropriata di <CODE>/etc/services</CODE>
e sarà di solito <CODE>tcp</CODE> o <CODE>udp</CODE>. I servizi basati
su "Sun RPC" (Remote Procedure Call) useranno <CODE>rpc/tcp</CODE>
o <CODE>rpc/udp</CODE>.
<P>
<P>
<DT><B>flags</B><DD><P>ci sono solo due valori possibili per questo campo,
che dice a <EM>inetd</EM> se il programma server libera il socket
dopo avere iniziato a lavorare. Il campo dice quindi se
<EM>inetd</EM> deve far partire un altro server alla prossima
richiesta di connessione oppure se deve attendere, assumendo
che il processo già in funzione gestisca anche le nuove
richieste di connessione. Ancora una volta, questa informazione
può essere difficile da ottenere, ma in genere tutti i
server <CODE>tcp</CODE> dovranno avere <CODE>nowait</CODE> in questo campo,
mentre la maggior parte dei server <CODE>udp</CODE> dovrebbero avere
il valore <CODE>wait</CODE>. Bisogna però fare attenzione alle
eccezioni a questa regola, perciò quando non si è
sicuri conviene farsi guidare dall'esempio che verrà
introdotto a breve.
<P>
<P>
<DT><B>user</B><DD><P>questo campo descrive a quale degli account presenti
in <CODE>/etc/passwd</CODE> deve essere assegnata la
proprietà del server di rete che viene fatto partire.
Questo campo è spesso utile per proteggersi da possibili
problemi di sicurezza. Si può assegnare l'utente
<CODE>nobody</CODE> come proprietario di un server, in modo da
minimizzare il danno possibile in caso di compromissione della
sicurezza del server di rete. Di solito, comunque, questo campo
viene posto a <CODE>root</CODE>, poiché molti server hanno
bisogno dei privilegi del superutente per funzionare
correttamente.
<P>
<P>
<DT><B>server_path</B><DD><P>questo campo è il percorso completo
(pathname) del programma server che deve essere eseguito in
relazione a questo servizio.
<P>
<P>
<DT><B>server_args</B><DD><P>questo campo comprende il resto della riga ed
è opzionale. In questo campo si mettono gli argomenti
di linea di comando che si intendono passare al programma
server quando questo viene lanciato.
<P>
</DL>
<P>
<H3>Un esempio di /etc/inetd.conf</H3>
<P>Come per <CODE>/etc/services</CODE>, tutte le distribuzioni aggiornate di Linux
includono un buon file <CODE>/etc/inetd.conf</CODE> con cui poter lavorare. Qui
per completezza riporto il file <CODE>/etc/inetd.conf</CODE> che appare nella
distribuzione
<A HREF="http://www.debian.org/">Debian</A>.
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Internal services
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#
# These are standard services.
#
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
#
# Pop et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
#
# `cfinger' is for the GNU finger server available for Debian. (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident stream tcp nowait nobody /usr/sbin/identd identd -i
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H2><A NAME="ss5.9">5.9 Altri file di configurazione relativi alla rete.</A>
</H2>
<P>C'è un certo numero di altri file, relativi alla configurazione di
rete sotto Linux, ai quali merita dare un'occhiata. Non ci sarà
bisogno di modificare questi file, ma vale la pena di descriverli, in modo da
sapere cosa contengono e a cosa servono.
<P>
<H3>/etc/protocols</H3>
<P>Il file <CODE>/etc/protocols</CODE> è un database che associa i numeri
identificativi dei protocolli al nomi di ciascun protocollo. Questa informazione
viene usata dai programmatori per poter specificare per nome i protocolli
all'interno dei programmi, e viene usata da alcuni programmi come
<EM>tcpdump</EM> al fine di mostrare nei loro messaggi i nomi di protocollo
invece dei numeri. La sintassi del file è:
<P>
<BLOCKQUOTE><CODE>
<PRE>
nome-protocollo numero alias
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Il file <CODE>/etc/protocols</CODE> che fa parte della distribuzione
<A HREF="http://www.debian.org/">Debian</A> è fatto così:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
xtp 36 XTP # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
rspf 73 RSPF # Radio Shortest Path First.
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H3><CODE>/etc/networks</CODE></H3>
<P>Il file <CODE>/etc/networks</CODE> ha una funzione simile a <CODE>/etc/hosts</CODE>.
Il file è un semplice database che associa i nomi delle reti ai loro
indirizzi. Il suo formato è differente da <CODE>/etc/hosts</CODE> in
quanto ci sono solo due campi per riga, che sono codificati come:
<P>
<BLOCKQUOTE><CODE>
<PRE>
nome-rete indirizzo-di-rete
</PRE>
</CODE></BLOCKQUOTE>
<P>Per esempio, il file potrebbe assomigliare al seguente:
<P>
<BLOCKQUOTE><CODE>
<PRE>
loopnet 127.0.0.0
localnet 192.168.0.0
amprnet 44.0.0.0
</PRE>
</CODE></BLOCKQUOTE>
<P>Quando si usano comandi come <EM>route</EM>, se un indirizzo di destinazione
è una rete e quella rete appare in<CODE>/etc/networks</CODE>, allora il
comando mostrerà il nome della rete invece del suo indirizzo.
<P>
<H2><A NAME="ss5.10">5.10 Sicurezza di rete e controllo degli accessi.</A>
</H2>
<P>Vorrei iniziare questa sezione avvisando che la protezione di un calcolatore e
di una rete da attacchi malevoli è un'arte complessa.
Non mi considero assolutamente un esperto in questo campo: mentre i meccanismi
che descrivo in seguito possono essere di aiuto, raccomando a chi prende
seriamente il problema della sicurezza di fare qualche ricerca personale
sull'argomento. Su Internet ci sono molti buoni documenti al proposito,
compreso
<A HREF="Security-HOWTO.html">Security-HOWTO</A>.
<P>Una importante regola base è:
`<B>Non far girare i servizi che non si intendono usare</B>'.
Molte distribuzioni sono configurate per attivare ogni sorta di servizi, che
vengono fatti partire automaticamente all'accensione della macchina.
Per assicurare un livello di sicurezza minimale occorre passare in rassegna il
proprio <CODE>/etc/inetd.conf</CODE> e commentare (mettendo un `#' all'inizio
della riga) ogni voce relativa a servizi che non si intendono usare. Buoni
candidati per questa operazione sono servizi come <CODE>shell</CODE>, <CODE>login</CODE>,
<CODE>exec</CODE>, <CODE>uucp</CODE>, <CODE>ftp</CODE>, e servizi informativi come <CODE>finger</CODE>,
<CODE>netstat</CODE> e <CODE>systat</CODE>.
<P>Ci sono molti tipi di meccanismi di sicurezza e controllo degli accessi;
qui descriverò solo i più elementari.
<P>
<H3>/etc/ftpusers</H3>
<P>Il file <CODE>/etc/ftpusers</CODE> è un semplice meccanismo che permette
di negare a certi utenti l'accesso via ftp alla macchina.
Il file <CODE>/etc/ftpusers</CODE> viene letto dal demone ftp server (<EM>ftpd</EM>)
quando vengono ricevute delle connessioni ftp in ingresso. Il file è
semplicemente una lista di utenti a cui è impedito di collegarsi.
Il file assomiglia al seguente:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/ftpusers - users not allowed to login via ftp
root
uucp
bin
mail
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H3>/etc/securetty</H3>
<P>Il file <CODE>/etc/securetty</CODE> permette di specificare a quali periferiche
di tipo <CODE>tty</CODE> l'utente root può collegarsi.
Il file <CODE>/etc/securetty</CODE> viene letto dal programma di login (di solito
<EM>/bin/login</EM>). Il file è una lista di nomi di terminali ai quali
root può collegarsi, mentre su tutti gli altri non è permesso di
collegarsi come superutente:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/securetty - tty's on which root is allowed to login
tty1
tty2
tty3
tty4
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H3>Il meccanismo di controllo degli accessi <EM>tcpd</EM>.</H3>
<P>Il programma <EM>tcpd</EM> che avrete notato in <CODE>/etc/inetd.conf</CODE>
fornisce i meccanismi di controllo degli accessi e di registrazione d'utilizzo
(logging) per i servizi che protegge.
<P>Quando viene invocato dal programma <EM>inetd</EM>, <EM>tcpd</EM> legge due
file contenenti regole di accesso e di conseguenza permette l'accesso al
servizio o lo rifiuta.
<P><EM>tcpd</EM> scandisce i file di regole finché non trova una
corrispondenza. Se non ci sono corrispondenze valide, si assume che l'accesso
sia permesso a tutti. I file che vengono scanditi in sequenza sono
<CODE>/etc/hosts.allow</CODE> e <CODE>/etc/hosts.deny</CODE>. Li descriverò uno
alla volta. Per una descrizione completa di questa funzionalità
conviene riferirsi alle pagine del manuale (<CODE>hosts_access(5)</CODE> è
un buon punto di partenza).
<P>
<H3>/etc/hosts.allow</H3>
<P>Il file <CODE>/etc/hosts.allow</CODE> è uno dei file di configurazione
del programma <EM>/usr/sbin/tcpd</EM>. <CODE>hosts.allow</CODE> contiene le regole
che descrivono a quali calcolatori è permesso accedere ai servizi di
questa macchina.
<P>Il formato del file è molto semplice:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/hosts.allow
#
# <lista servizi>: <lista calcolatori> [: comando]
</PRE>
</CODE></BLOCKQUOTE>
<P>
<DL>
<P>
<DT><B><CODE>lista servizi</CODE> </B><DD><P>è una lista delimitata da
virgole di nomi di programmi server cui questa regola si
applica. Esempi di nomi di server sono <CODE>ftpd</CODE>, <CODE>telnetd</CODE>
e <CODE>fingerd</CODE>.
<P>
<P>
<DT><B><CODE>lista calcolatori</CODE> </B><DD><P>è una lista delimitata da
virgole di nomi di host. Si possono, alternativamente, usare
gli indirizzi IP. Si possono anche specificare nomi o
indirizzi usando caratteri speciali per indicare gruppi di
host. Per esempio, <CODE>gw.vk2ktj.ampr.org</CODE> corrisponde ad un
host, <CODE>.uts.edu.au</CODE> indica tutti i nomi che terminano
con questa stringa, <CODE>44.</CODE> indica ogni indirizzo IP che
inizia con 44. Ci sono alcune parole speciali per semplificare
la configurazione, alcune delle quali sono: <CODE>ALL</CODE> per
indicare tutti gli host, <CODE>LOCAL</CODE> per indicare gli host il
cui nome non contiene un `<CODE>.</CODE>', cioè che sono nello
stesso dominio di questa macchina, <CODE>PARANOID</CODE> indica tutti
gli host il cui nome non corrisponde all'indirizzo (cioè
nel caso sia in atto un `name spoofing'). Un'altra parola
speciale che risulta utile è <CODE>EXCEPT</CODE>: permette di
specificare una lista con delle eccezioni. Questo caso
verrà coperto più avanti da un esempio.
<P>
<P>
<DT><B><CODE>comando</CODE> </B><DD><P>è un argomento opzionale.
Questo parametro corrisponde al pathname completo di un
comando che deve essere eseguito ogni volta che questa regola
si applica. Per esempio potrebbe essere un comando che cerchi
di identificare chi è collegato sul calcolatore che
cerca di connettersi, o un comando che spedisce un messaggio
di posta o altri avvertimenti all'amministratore di sistema
riguardo al tentativo di connessione.
Ci sono un certo numero di estensioni che possono essere
incluse nel comando; alcuni esempi tipici sono: <CODE>%h</CODE>
è il nome dell'host che cerca di collegarsi, o il suo
indirizzo se il nome non può essere risolto, <CODE>%d</CODE>
è il demone server che viene invocato.
<P>
</DL>
<P>
<P>Un esempio:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/hosts.allow
#
# La posta è permessa e chiunque
in.smtpd: ALL
# telnet e ftp sono permessi solo a questo dominio e al mio
# calcolatore di casa
telnetd, ftpd: LOCAL, myhost.athome.org.au
# finger è permesso a tutti, ma tenendo traccia di chi lo usa.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H3>/etc/hosts.deny</H3>
<P>Il file <CODE>/etc/hosts.deny</CODE> è un file di configurazione del
programma <EM>/usr/sbin/tcpd</EM>. Il file <CODE>hosts.deny</CODE> contiene
le regole che descrivono a quali calcolatori <EM>non è permesso</EM>
di accedere un servizio sul calcolatore locale.
<P>Un semplice esempio potrebbe somigliare a questo:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# /etc/hosts.deny
#
# Impedisci l'accesso a tutti i calcolatori con nomi sospetti
ALL: PARANOID
#
# Impedisci l'accesso a tutti i calcolatori
ALL: ALL
</PRE>
</CODE></BLOCKQUOTE>
<P>In realtà la voce <CODE>PARANOID</CODE> è ridondante perché
l'altra voce si riferisce in ogni caso a tutti i calcolatori. L'uso di una di
queste due voci potrebbe essere una scelta ragionevole, in base alle specifiche
esigenze di controllo degli accessi.
<P>La configurazione più sicura consiste nell'avere un default di
<CODE>ALL: ALL</CODE> esplicito in <CODE>/etc/hosts.deny</CODE> ed abilitare
esplicitamente in <CODE>/etc/hosts.allow</CODE> i servizi e gli host che si
vogliono autorizzare.
<P>
<H3>/etc/hosts.equiv</H3>
<P>Il file <CODE>hosts.equiv</CODE> viene usato per autorizzare alcuni calcolatori e
alcuni utenti ad utilizzare gli account sulla macchina locale senza aver
bisogno di fornire una password. Questo è utile in un ambiente sicuro,
in cui si possano controllare tutte le macchine, ma è un grosso rischio
in altre circostanze. Un calcolatore è sicuro solo tanto quanto lo
è il meno sicuro dei calcolatori di cui ci si fida. Per massimizzare la
sicurezza è bene non usare il meccanismo di <CODE>hosts.equiv</CODE> ed
incoraggiare gli utenti a non usare nemmeno il file <CODE>.rhosts</CODE>.
<P>
<H3>Come configurare correttamente il server <EM>ftp</EM>.</H3>
<P>Molti siti sono interessati ad offrire il servizio di ftp anonimo, per
permettere ad altre persone di scaricare e depositare dei dati senza bisogno di
un account specifico sulla macchina. Se si decide di offrire questo servizio
bisogna assicurarsi di configurare correttamente il server <EM>ftp</EM> per
l'accesso anonimo. La maggior parte delle pagine del manuale disponibili per
<CODE>ftpd(8)</CODE> descrivono accuratamente come adempiere questo compito, e
bisogna assicurarsi di seguire le istruzioni. Un consiglio importante è
di non usare una copia del proprio file <CODE>/etc/passwd</CODE> nella directory
<CODE>/etc</CODE> dell'account anonimo: bisogna assicurarsi di rimuovere tutti i
dettagli tranne quelli necessari, altrimenti si diventa vulnerabili alle
tecniche di rottura delle password "per forza bruta".
<P>
<H3>I firewall di rete.</H3>
<P>Un eccellente modo per avere una certa sicurezza è impedire ai
pacchetti di raggiungere il calcolatore che si intende proteggere.
Questa tecnica è discussa in dettaglio nel
<A HREF="Firewall-HOWTO.html">Firewall-HOWTO</A>, e (in forma concisa)
in una sezione successiva di questo documento.
<P>
<H3>Altri suggerimenti.</H3>
<P>Questi sono altri suggerimenti che val la pena di prendere in considerazione,
anche se potenzialmente si prestano a guerre di religione.
<P>
<DL>
<P>
<P>
<DT><B>sendmail</B><DD><P>nonostante la sua popolarità, appare sugli
annunci di attenzione alla sicurezza con impressionante regolarità.
Dipende da voi, ma io preferisco non usarlo [un'ottima alternativa è
<EM>postfix</EM>, si trova su
<A HREF="http://postfix.linux.it/">mirror italiano di www.postfix.org</A> N.d.T.].
<P>
<P>
<DT><B>NFS e altri servizi di tipo "Sun RPC"</B><DD><P>bisogna fare attenzione:
esistono un sacco di modi per sfruttare a fini malevoli questi servizi.
È difficile trovare un'alternativa a servizi come NFS, ma se questi
vengono abilitati bisogna fare estrema attenzione riguardo chi ha il permesso
di montare i dischi della propria macchina.
</DL>
<P>
<HR>
<A HREF="NET-3-HOWTO-6.html">Avanti</A>
<A HREF="NET-3-HOWTO-4.html">Indietro</A>
<A HREF="NET-3-HOWTO.html#toc5">Indice</A>
</BODY>
</HTML>
