| Home / Indice sezione | www.icosaedro.it | |
Ripasso Unix - Lezione 3 - Networking1. Kernel e networking
2. Protocollo IP
3. Configurazione dell'interfaccia
4. Routing
5. Protocollo TCP/IP (TCP over IP)
6. Impostare nome e dominio della macchina
7. Resolver
8. Diagnostica
9. Telnet come chiave inglese del TCP
10. Leggere la posta (POP-3, RFC 1939)
11. Inviare la posta (SMTP, RFC 2821)
12. Protocollo WEB (HTTP, RFC 2616)
13. Configurazione
14. Domande
15. Bibliografia
Il kernel si occupa di interfacciare le applicazioni con le interfacce
di rete, smista e filtra i pacchetti, esegue il firewall, esegue il
masquerading, implementa le funzionalità di router e di gateway.
Tutte queste funzionalità sono configurabili essenzialmente con i
comandi ifconfig e route, più qualche altro.
Nei kernel recenti sono inclusi i driver per una gran varietà di dispositivi di rete. Occorre leggere la documentazione del kernel per conoscere tutti i tipi supportati.
I dispositivi PCI sono intrinsecamente plug-and-play, nel senso che se è
disponibile un modulo driver per il dispositivo, esso viene caricato
automaticamente all'avvio del kernel. Per conoscere i dispositivi
trovati bisogna guardare ai messaggi di boot, oppure usare il comando
dmesg. Ad esempio:
# dmesg | grep eth
Se un dispositivo manca, occorre trovare il modulo driver corrispondente e includerlo nel kernel. Esistono driver in versione sorgente da inserire nel sorgente del kernel e ricompilare, e in versione pacchetto RPM di più immediata installazione.
Il protocollo IP (Internet Protocol) oggi riconosciuto come "IPv4" (versione 4) è stato definito nella sua forma attuale nel documento RFC 791 nel 1981 (v. www.rfc-editor.org). Si tratta di un protocollo a pacchetti dove ogni nodo della rete ha assegnato un indirizzo univoco a 32 bit. Questi indirizzi sono spesso rappresentati nella forma "quad-byte", dove si riporta il valore di ciascuno dei 4 byte che lo compongono rappresentato in base 10. Questi sono modi alternativi di scrivere lo stesso indirizzo:
00001100001000100011100001001110 (binario) 203569230 (decimale) 12.34.56.78 (quad-byte)
Ogni pacchetto IP contiene il numero di nodo (o indirizzo di nodo) del mittente e del destinatario, ed ogni nodo della rete fa del suo meglio per recapitare il pacchetto verso la destinazione. Trattandosi di una rete, infatti, raramente i due computer che si parlano sono connessi direttamente, per cui i pacchetti sono costretti ad attraversare un numero variabile di nodi prima di arrivare a destinazione.
La maschera di sottorete è uno strumento per decidere il routing dei pacchetti in base all'indirizzo di destinazione. La maschera è un pattern di bit che viene confrontato con i bit dell'indirizzo di destinazione: l'AND logico tra i due valori dà l'indirizzo della sottorete. Esempio:
Destinazione: 00001100001000100011100001001110 AND
Maschera: 11111111000000000000000000000000 =
--------------------------------
Risultato: 00001100000000000000000000000000
La cosa è forse un pò più chiara se espressa in notazione quad-byte:
Destinazione: 12.34.56.78 AND
Maschera: 255. 0. 0. 0
------------
Risultato: 12.0.0.0
Il fatto che il driver di una data interfaccia sia caricato non è sufficiente
per il suo corretto funzionamento: bisogna infatti assegnare alla scheda di
rete (o quant'altro) un indirizzo di nodo e una maschera di sottorete
adatti. Questo lo si fa con il comando ifconfig (InterFace
CONFIGuration):
# ifconfig eth0 12.34.56.78
che assegna l'indirizzo 12.34.56.78 alla scheda pilotata dal driver eth0 (le eventuali altre schede si chiameranno eth1, eth2, ecc., e i numeri vengono assegnati in base all'ordine in cui sono caricati i driver, per cui non è facilmente prevedibile). La maschera di sottorete usata in questo caso è quella default per un indirizzo del tipo usato nell'esempio, e cioè 255.0.0.0. Se non è quella corretta, allora bisognerà specificare anche questo dato:
# ifconfig eth0 12.34.56.78 netmask 255.255.0.0
La maschera di sottorete decide quando il pacchetto deve essere smistato all'interno della rete Ethernet oppure deve andare al gateway.
Per visualizzare lo stato delle interfacce configurate basta dare
il comando ifconfig da solo, eventualmente specificando il
nome della interfaccia se si è interessati solo a quella. Ecco la situazione
nel mio computer:
root@orso, ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:84:9D:86:5D
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:240 (240.0 b)
Interrupt:9 Base address:0x6f00
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
ppp0 Link encap:Point-to-Point Protocol
inet addr:151.26.156.247 P-t-P:151.5.168.56 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4 errors:1 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:40 (40.0 b) TX bytes:58 (58.0 b)
Per richiamare questi comandi ad ogni riavvio della macchina basta
inserirli in /etc/rc.d/rc.local oppure, meglio, in
/etc/rc.d/init.d/network.
La tabella di routing permette di gestire in modo abbastanza versatile la logica di routing desiderata. Si tratta di una tabella che si trova dentro al kernel e che è costituita essenzialmente dalle informazioni necessarie per individuare l'interfaccia di rete da usare una volta noto l'indirizzo di destinazione. Per inviare un pacchetto all'indirizzo a.b.c.d, il kernel esamina nell'ordine i valori della colonna "Genmask": viene eseguito l'AND logico dell'indirizzo di destinazione con la genmask e poi il risultato viene : se coincide, il pacchetto viene inviato al driver dell'interfaccia specificato.
La singola interfaccia deve conoscere a sua volta il metodo di routing opportuno per la sua natura. La situazione sul mio computer è questa:
root@orso, ~ # route Kernel IP routing table Destination Gateway Genmask Flags Iface bo1ie08u.iunet. * 255.255.255.255 UH ppp0 10.0.0.0 * 255.255.255.0 U eth0 127.0.0.0 * 255.0.0.0 U lo default bo1ie08u.iun 0.0.0.0 UG ppp0
eth0 è l'interfaccia Ethernet per la rete locale, mentre ppp0 è il modem. La situazione è più chiara se mettiamo l'opzione -n che dà gli indirizzi in forma numerica:
root@orso, ~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Iface 151.5.168.56 0.0.0.0 255.255.255.255 UH ppp0 10.0.0.0 0.0.0.0 255.255.255.0 U eth0 127.0.0.0 0.0.0.0 255.0.0.0 U lo 0.0.0.0 151.5.168.56 0.0.0.0 UG ppp0
In questo esempio la Genmask dell'ultima riga 0.0.0.0 intercetta tutti gli indirizzi IP che non corrispondono alle sottoreti delle righe precedenti e quindi dirotta i pacchetti verso ppp0 al gateway 151.5.168.56.
Per aggiungere righe nella tabella di routing:
# route add -net 192.168.0.0 netmask 255.255.255.0 eth0 # route add -net 192.168.0.0/24 eth0 # route add default gw 192.168.0.105
Per rimuovere righe nella tabella di routing si usano gli stessi comandi sostituendo "add" con "del".
La tabella di routing viene automaticamente ripulita quando un device viene tolto o disabilitato:
# ifconfig eth0 down # killall pppd
Le entrate nella tabella di routing vengono automaticamente ordinate in modo appropriato. Non esiste modo di indicare l'esatta posizione nella quale si vuole inserire una riga, perché questo viene deciso dal kernel sulla base di regole di coerenza della tabella stessa. In generale, le entrate con le genmask più specifiche (cioè con meno bit accesi) vengono per ultime.
Il demone pppd provvede automaticamente alla sistemazione del
routing, salvo diversa esplicita configurazione scelta.
Per le schede Ethernet viene impostato automaticamente il routing verso la sottorete default come dedotta dall'indirizzo assegnato, salvo diversa esplicita indicazione.
Gli indirizzi del tipo
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
per convenzione non sono utilizzati in Internet ma vengono riservati ad uso interno delle reti locali (RFC 1918).
Per richiamare questi comandi ad ogni riavvio della macchina bisogna inserirli in uno dei file citati al paragrafo precedente.
Viene descritto nell'RFC 793: basato su IP, il TCP permette di stabilire canali di comunicazione tra un processo residente su di una macchina e un altro processo su di un'altra macchina (o anche sulla stessa, naturalmente). I diversi canali di comunicazione contemporanei vengono individuati da un numero di porta a 16 bit. Il computer che inizia la comunicazione è il client, mentre quello che rimane in attesa della richiesta di collegamento si chiama server.
L'insieme di numeri di nodo del client e del server, e dei numeri di porta TCP del client e del server, sono quattro numeri che costituiscono un socket pair Internet o, brevemente, socket pair. Grazie al concetto di socket pair vari computer stabiliscono vari canali di comunicazione senza rischio che i pacchetti TCP vengano confusi.
| Canali TCP e socket pair. I rettangoli rappresentano i computer sulla rete Internet, mentre i pallini neri rappresentano i socket TCP e riportano il numero della porta assegnata. Il computer 11.11.11.11 sembra essere un server WEB con installato Apache. Il computer 22.22.22.22 ha attivato due canali TCP con Internet Explorer, e contemporaneamente sta inviando posta con Outlook Express verso il computer 33.33.33.33. Quest'ultimo computer sta anche eseguendo un programma PHP che accede al DB PostgreSQL attraverso un canale TCP. I numeri di porta come 25 e 80 sono standard, mentre gli altri numeri di porta hanno l'unico vincolo di essere univoci sul computer dove risiedono. |
Mentre il numero di porta utilizzato dal client di norma viene assegnato
a caso (basta che sia univoco tra tutte le porte TCP correntemente usare
dal client), il numero di porta del server deve essere noto. Esistono
perciò delle convenzioni sui numeri porta assegnati riportate
nell'RFC 1700. Un estratto di tale documento lo si trova nel file
/etc/services: si tratta di una tabella che mappa i nomi
assegnati alle porte convenzionali usate dai server per il protocollo
TCP e per l'UDP (di cui non abbiamo parlato qui). Questa tabella serve
ad alcuni comandi per poter visualizzare i numeri di porta in forma
simbolica, anziché in forma numerica. Tuttavia, è bene ricordare alcuni
numeri di porta TCP importanti, da sapere a memoria:
25 SMTP 110 POP-3 80 HTTP 443 HTTPS 20,21 FTP 22 SSH 23 Telnet
Sul protocollo TCP sono basati i principali protocolli di livello superiore per la posta elettronica, per il WEB, ecc. Li vedremo nel seguito per mezzo di esempi.
# hostname www # domainname azienda.it
Ogni processo che necessita della risoluzione dei nomi di dominio
(compresi i programmi server) fa uso della libreria di sistema detta
resolver. In questa libreria ci sono le funzioni che permettono
la conversione da nome di dominio (es. www.azienda.it)
in numero di nodo (es. 11.11.11.11).
La risoluzione statica la fa con il file /etc/hosts:
$ cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 10.0.0.1 orso.casa.lan orso 10.0.0.2 castoro.casa.lan castoro 10.0.0.3 emulo.casa.lan emulo
La risoluzione dinamica via servizio DNS la fa in base al
contenuto del principale file di configurazione del resolver
/etc/resolv.conf, il cui contenuto tipico potrebbe essere
questo:
option rotate nameserver 193.70.192.25 nameserver 193.70.152.25
La riga delle opzioni dice solo di utilizzare i due nameserver indicati a rotazione, in modo da bilanciare il carico sui DNS. Si possono indicare fino a tre DNS.
ATTENZIONE! il file di configurazione viene letto solo la prima volta che il processo chiama una delle funzioni del resolver, tipicamente all'avvio del processo stesso. Nel caso dei programmi server, se occorre modificare il resolver, dopo bisogna anche riavviare i programmi che lo usano.
Scoprire cosa fanno e come si possono usare i comandi seguenti:
ping
traceroute
lsof -i
pstree
tcpdump -i eth0 -s 65535 -l -nn -q -t -x -X
Il client telnet implementa essenzialmente il protocollo telnet che dialoga sulla porta TCP 23 del server. Tuttavia lo si può usare come strumento grezzo per parlare TCP su qualsiasi porta, basta indicare il numero della porta voluta e prepararsi a parlare il protocollo di livello superiore direttamente con il server. Siccome i protocolli di livello superiore basati su TCP sono per lo più orientati alla linea, il telnet è perfetto per questo scopo.
Per fare gli esperimenti che seguono raccomando di utilizzare un client telnet adeguato: quello default su Linux va bene, su Windows usare Putty o Teraterm.
In questo esempio di sessione interattiva, genero un paio di email di prova e quindi le vado a leggere con il protocollo POP-3. Il server in questione è la mia stessa macchina sulla quale ho installato gli opportuni programmi. Come al solito, le righe evidenziate in grassetto sono quelle che ho scritto io, mentre le altre sono le risposte del computer e del programma server POP-3.
$ echo "body messaggio 1" | mail salsi -s "oggetto 1"
$ echo "body messaggio 2" | mail salsi -s "oggetto 2"
$ telnet localhost 110
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
+OK POP3 localhost.localdomain v2000.69rh server ready
user salsi
+OK User name accepted, password please
pass pippo
+OK Mailbox open, 2 messages
stat
+OK 2 702
list
+OK Mailbox scan listing follows
1 351
2 351
.
retr 1
+OK 351 octets
Return-Path: <salsi@casa.lan>
Received: (from salsi@localhost)
by casa.lan (Sendmail/3.14) id fBLCt1b01993
for salsi; Fri, 21 Dec 2001 13:55:01 +0100
Date: Fri, 21 Dec 2001 13:55:01 +0100
From: "U.Salsi" <salsi@casa.lan>
Message-Id: <200112211255.fBLCt1b01993@casa.lan>
To: salsi@casa.lan
Subject: oggetto 1
Status:
body messaggio 1
.
dele 1
+OK Message deleted
quit
+OK Sayonara
Connection closed by foreign host.
Un altro comando interessante del protocollo POP-3 è TOP: TOP 12 10 mostra le prime 10 righe del messaggio n. 12. Utile per visionare messaggi immmmensi, prima di deletarli...
In questo esempio uso il protocollo SMTP per inviare un email. Il server utilizzato è quello di Libero di Infostrada. Come al solito, le righe evidenziate in grassetto sono quelle che ho scritto io, mentre le altre sono quelle generate dal computer e dal server SMTP.
$ telnet mail.libero.it smtp Trying 195.123.94.65... Connected to localhost.localdomain. Escape character is '^]'. 220 smtp3.libero.it ESMTP Service (6.0.032) ready HELO localhost 250 smtp3.libero.it MAIL FROM:<umberto-salsi@libero.it> 250 MAIL FROM:<umberto-salsi@libero.it> OK RCPT TO:<tizio@qualcosa.it> 250 RCPT TO:<tizio@qualcosa.it> OK RCPT TO:<caio@qualcosaltro.it> 250 RCPT TO:<caio@qualcosaltro.it> OK DATA 354 Start mail input; end with <CRLF>.<CRLF> Date: Wed, 17 Aug 2002 21:19:45 CET From: Umberto Salsi <umberto-salsi@libero.it> To: tizio@qualcosa.it, caio@qualcosaltro.it Subject: Salve! Sto provando con l'SMTP. Ciao, - Umb . 250 <3C0D5E3F005FC9EA> Mail accepted QUIT 221 smtp3.libero.it QUIT Connection closed by foreign host.
Il messaggio deve rispettare le specifiche RFC 2822.
Vedere la home page di www.qualcosa.it usando telnet come browser WEB:
$ telnet www.qualcosa.it 80 Trying 12.34.56.78... Connected to www.qualcosa.it. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 200 OK Date: Wed, 21 Aug 2002 21:33:20 GMT Server: Apache/1.3.19 (Unix) (Red-Hat/Linux) Last-Modified: Mon, 17 Aug 2002 08:55:23 GMT ETag: "fa7b-43-3c146a6b" Accept-Ranges: bytes Content-Length: 67 Content-Type: text/html <html><body>...</body></html> Connection closed by foreign host.
Quadro delle tipiche implementazioni dei protocolli citati e i file di configurazione usati. Configurare il server consiste nel modificare opportunamente il file di configurazione (con un text editor) e quindi riavviare il server con il comando indicato.
| Servizio | Programma | File di config. | Per avviare/fermare |
|---|---|---|---|
| Telnet | telnetd | (nessuno) | (avviato da inetd (v. /etc/inetd.conf) o da xinetd (v. /etc/xinetd.conf) |
| SSH | sshd | /etc/ssh/sshd_config |
Programma stand-alone da invocare come sshd nel file
/etc/rc.d/rc.local, oppure si usa service sshd start|stop|restart|status, a seconda del packaging. |
| SMTP | sendmail | /etc/sendmail.cf |
service sendmail start|stop|restart|status |
| POP-3 | imap | (nessuno) | (avviato da inetd (v. /etc/inetd.conf) o da xinetd (v. /etc/xinetd.conf) |
| HTTP | Apache | /etc/httpd/conf/httpd.conf |
service httpd start|stop|restart|status |
C.Hunt, "TCP/IP Network Administration", O'Reilly 1998
I documenti RFC sono disponibili in
www.rfc-editor.org:
0791 Internet Protocol. J. Postel. Sep-01-1981. (Format: TXT=97779
bytes) (Obsoletes RFC0760) (Also STD0005) (Status: STANDARD)
0793 Transmission Control Protocol. J. Postel. Sep-01-1981. (Format:
TXT=172710 bytes) (Updated by RFC3168) (Also STD0007) (Status:
STANDARD)
0854 Telnet Protocol Specification. J. Postel, J.K. Reynolds.
May-01-1983. (Format: TXT=39371 bytes) (Obsoletes RFC0764) (Also
STD0008) (Status: STANDARD)
1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format:
TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status:
STANDARD)
1918 Address Allocation for Private Internets. Y. Rekhter, B.
Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996.
(Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005)
(Status: BEST CURRENT PRACTICE)
1939 Post Office Protocol - Version 3. J. Myers, M. Rose. May 1996.
(Format: TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957,
RFC2449) (Also STD0053) (Status: STANDARD)
2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys,
J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June
1999. (Format: TXT=422317, PS=5529857, PDF=550558 bytes) (Obsoletes
RFC2068) (Updated by RFC2817) (Status: DRAFT STANDARD)
2821 Simple Mail Transfer Protocol. J. Klensin, Editor. April 2001.
(Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869)
(Status: PROPOSED STANDARD)
2822 Internet Message Format. P. Resnick, Editor. April 2001. (Format:
TXT=110695 bytes) (Obsoletes RFC0822) (Status: PROPOSED STANDARD)
| Umberto Salsi | Commenti | Contatto | Mappa | Home / Indice sezione |
Still no comments to this page. Use the Comments link above to add your contribute.