Pillole
di
Internet
Orientarsi tra termini come LAN, WAN, Ethernet, HUB, Bridge,
Router,
Switch, TCP/IP, NAT, ipv4 ed ipv6, MPLS ed altro ancora…
Ciro Carbone
Ho
cercato di
condensare, senza presunzione e per quanto possibile,
un compendio riassuntivo degli elementi
basilari per orientarsi tra i fondamenti di Internet e di intranet ed i
termini
come LAN, WAN, Ethernet, HUB, Bridge,
Router, Switch, TCP/IP, NAT, ipv4 ed ipv6,, MPLS ed
altro ancora…
Indice:
Capitolo 1 à Introduzione alle reti LAN
Capitolo 2 à protocolli Ethernet, TCP/IP, IPv4, ARP,
DNS ecc.:
la Matrioska!
2.1
ARP
2.2
DNS
2.3
TCP
2.4
Conclusioni
Capitolo 3 à Bridge
e Switch
Capitolo 4 à Reti
WAN
Capitolo 5 à Router
Capitolo 6 à MPLS
Capitolo 7 à
Indirizzi IP, classi e Subnet Mask
Capitolo 8 à NAT
Capitolo 9 à IPV6
1.1
Introduzione alle reti LAN
Il termine LAN
è un
acronimo di Local Area Network (Rete Locale) ed identifica una piccola
o media
rete di computers, definiti anche Hosts (ospiti o utenti) che possono
comunicare tra loro e condividerne risorse di natura informatica (dati,
cartelle, files, stampanti, dischi, fax ecc.).
In passato le
prime reti
LAN utilizzavano una connessione su cavo coassiale, ovvero tutti gli
hosts
erano connessi ad un unico cavo (chiamato bus)Il bus era costituito da
un cavo
coassiale con una anima interna di rame ed una calza di rame più
esterna ed
isolata dall’anima tramite materiale isolante dielettrico.
Il cavo
coassiale
utilizzato poteva essere un RG-8, di grosso diametro, rivestito da una guaina
di plastica arancione o gialla (da cui il nome di cavo giallo o thick-cable=cavo
grasso) o di altro tipo
(RG-58 o
altro), più sottile, di colore nero o bianco (detto anche
thin-cable=cavo
magro) e con impedenza tra i 50ohm e i 75 ohm. Per il thin-cable,
l’aggancio
dei computer della LAN sul cavo bus avveniva con derivazioni con
connettori BNC
detti a T
Originariamente,
negli
anni settanta, il cavo bus poteva raggiungere lunghezze di 500 metri e
la rete
prendeva il nome di 10Base5. Questa dicitura identifica con 10 il bit
rate
supportato (10Mbits/sec), Base identifica il tipo di modulazione dei
bit dei
dati che viaggiano sul bus (Base identifica una modulazione in banda
base, in
inglese BaseBand), 5 codifica la
lunghezza di 500 metri di bus per ciascun segmento. Questo cavo veniva fatto
scorrere come una biscione lungo l'intera lunghezza della rete
accostandosi
alle varie stazioni che doveva interconnettere ma senza mai toccarle
realmente.
Il contatto con queste ultime avviene attraverso un cavo di
derivazione,
chiamato drop cable (cavo di spillamento), che poteva essere
lungo fino
a massimo di 50 metri e che veniva collegato, a sua volta, ad un
connettore
DB15 denominato AUI (Attachment Unit Interface) posto
direttamente sulla
scheda di rete del computer. L'unione tra drop cable e cavo coassiale
avveniva
tramite una speciale scatoletta che conteneva un
trasmettitore/ricevitore di
nome transceiver (transmitter/receiver). Il transceiver usato
nelle reti
10Base-5 vieniva innestato sul cavo coassiale mediante una complessa
operazione
di montaggio meccanico, poiché questo è di tipo coassiale
e quindi devono
essere evitate le possibili interferenze che si generano per contatto
tra la
maglia esterna e il filo interno. Tra una macchina e l'altra devono
esserci
almeno 2,5 metri di cavo coassiale. Infine il cavo è talmente
rigido e pesante
che non è possibile curvarlo se non descrivendo un arco molto
ampio.
L’insieme
di una rete LAN così collegata prende il
nome di Dominio o meglio collision-Domain (poi vedremo il
perché).
Altri
sistemi analoghi erano il 10-Base2 (200 metri) ed il 10-BaseT (con cavo
Twisted, cioè intrecciato).
Gli
svantaggi del cavo coassiale difficile da stendere, costoso, difficile
da
mantenere in caso di interruzioni e guasti, difficile da curvare
spronò la
ricerca di un sistema più opportuno: nasce l’HUB.
L’HUB
potrebbe essere tradotto in italiano col termine
“concentratore”; esso non fa
né più, né meno di quello che fa un cavo coassiale
con tutte le sue derivazioni
a T, drop-cable, AUI e transceivers. Lo possiamo immaginare come uno
“scatolotto” con una parte elettronica interna, una
alimentazione energetica e
tanti plugs RJ femmina a cui vanno collegati i computers della stessa
rete LAN
Invece di
stendere un cavo
coassiale lungo tutto lo spazio della rete LAN, basta collegarvi ogni
host con
l’apposito plug RJ45. Nell’HUB della foto sopra potremo
collegare un massimo di
4 hosts, quindi realizzare una piccola rete LAN con quattro computers.
Il cavo
dal computer all’HUB non può superare, però, i 100
metri di lunghezza. I 4
computers in rete realizzeranno quindi la propria rete LAN ed
apparterranno,
quindi, al proprio collision-Domain. L’uso
dell’HUB rende molto più semplice il cablaggio di una rete
LAN e sicuramente
anche più conveniente in termini economici. Inoltre,
l’inturruzione accidentale
di un cavo verso un host non pregiudicherebbe l’isolamento di una
parte della
rete come nei cablaggi con cavo coassiale. Oggi, per
realizzare una
LAN si userebbe esclusivamente un HUB come quello nella figura sopra.
Benché
da un punto di
vista topologico una rete realizzata con un HUB è fisicamente
una rete a stella
e non più a bus, logicamente la topologia rimane a bus. Infatti
in un HUB
dobbiamo immaginare ci fosse un bus che interconnette tutti gli hosts.
Il cavo
utilizzato con gli
HUB non è più di tipo coassiale ma un
“multifilare” con almeno 4 anime il cui
colore in sequenza è arancione, blu, verde, marrone
I connettori
sono chiamati
plugs e sono del tipo RJ-45. La numerazione parte da sinistra verso
destra. In
un cavo LAN RJ-45 ci sono 8 fili ma per il traffico LAN ne bastano solo
4, cioè
i cavi numerati 1, 2, 3 e 6.
|
|
|
I cavi di
collegamento
RJ-45 possono essere di due tipi: dritti e incrociati.
I cavi dritti
sono di tipo
pin-to-pin, ovvero caratterizzati da una corrispondenza delle anime tra
i due
plugs estremi (1 con 1, 2 con 2 ecc.), mentre i cavi incrociati, detti
anche cross-cable, hanno l’inversione del pin
1 col 3 ed il pin 2 col 6 ad una estremità. Questa inversione
coincide con
l’inversione tra Tx ed Rx. Il cavo dritto viene utilizzato quando
si devono
collegare due apparati di rete con funzionalità differenti (es.
un computer con
un hub, un router con uno switch ecc.), mentre il cross-cable
servirà per
collegare due apparati con le stesse funzionalità (es. due
computers, due HUB,
due router, due switch ecc.).
Una domanda
lecita
potrebbe essere: se ho un piccola rete LAN di 4 computers ed ho,
quindi, un HUB
con quattro porte (come quello in figura sopra) ma ora ho
necessità di
estendere la mia rete, poiché ho altri 3 computer da aggiungere,
cosa faccio?
Compro un nuovo HUB con più porte e butto il vecchio?
La risposta
è: non
necessariamente…
E’
possibile, infatti,
aggiungere più HUB in cascata ed il cavo che collegherà i
due HUB potrà avere
una lunghezza massima di 100 metri.
I sei host
collegati nella
figura sopra realizzano una singola rete LAN o una singola
collision-Domain.
- I protocolli Ethernet, TCP/IP, IPv4,
ARP, DNS ecc.: la Matrioska!
Cosa viaggiava
sul cavo
coassiale o sul cavo twisted prima o ancora oggi attraverso gli HUB?
Ciò che
viaggia sono bit, quindi impulsi in formato digitale, organizzati in
spezzoni
(frame) e pacchetti alle velocità di 10Mbit/sec. (circa 10
milioni di bit al
secondo) o 100Mbit/sec. (100 milioni di bit al secondo). Oggi tuttavia
esistono
reti Gigabit ben più veloci con miliardi di bit in un secondo.
Già negli anni
settanta Xerox,Digital e Intel inventando il protocollo ETHERNET consentirono la
nascita delle prime reti locali LAN. Ancora oggi Ethernet è il
protocollo
universalmente più utilizzato per le comunicazioni nelle reti.
Altri protocolli
furono sviluppati negli anni come il Token Ring …. ma quello che
è
sopravvissuto è l’Ethernet a velocità sempre
più elevate:
ü
10-BaseT, 10-Base2, 10-Base5 ecc. à Ethernet a 10Mbits/sec.
ü
100-BaseTx/Fx/Lx, ecc. à Ethernet a 100Mbits/sec. o
FastEthernet
ü
1000-BaseTx/Fx/Lx
à Gigabit Ethernet
Ethernet si
basa su bit
che vengono raggruppati in spezzoni denominati Frames. Ciascun Frame
è composto
da un minimo di 74 Byte ad un massimo di 1526 Byte. Poiché un
Byte è composto
da 8 bit, il frame ethernet è composto da un minimo di 592 bit
ad un massimo di
12208 bit. I primi 7 Byte costituiscono il “Preambolo” (una
serie di bit a 0 ed
1 alternati che avverte le interfacce LAN dell’inizio di un frame
e ne consente
la sincronizzazione con la relativa estrazione del clock). Il Byte
successivo è
chiamato SFD o “start of frame” ed è composto da 8
bit tutti ad 1 che indica
l’inizio del frame. A seguire troviamo 6 Byte di
“destination address” e 6 Byte
di “source address”. Nei 6 Byte del “destination
address”, troviamo codificato
in binario il codice MAC address dell’host destinatario del
frame, mentre nei 6
Byte successivi il MAC address dell’host che ha generato il frame
ethernet. Il
MAC address (Media Access Control) è un codice che identifica in
modo univoco
l’indirizzo fisico dell’host: per intenderci, nel nostro
computer sarà
l’indirizzo fisico della nostra scheda ethernet, rintracciabile
digitando dal
prompt di una macchina Windows il comando ipconfig (o winconfig nelle
vecchie
versioni precedenti a XP):
Come visibile
esso è
costituito da sei gruppi in esadecimale, che verranno codificati in
binario in
6 Byte.
I due Byte
successivi sono
chiamati “Type” ed identificano il tipo di frame ethenet,
cioè identificano
cosa seguirà. Se
seguirà un pacchetto IP il
valore di “type” sarà 800 in esadecimale (0x800 dove
0x indica la
rappresentazione decimale). Dopo il “Type”
seguono i dati o
“payload”, cioè il carico informativo vero e proprio
in cui sono inseriti i
pacchetti IP del protocollo Internet. Quindi è chiaro che il
contenuto dei dati IP è inglobato all’interno di
un frame Ethernet come in una matrioska. Poiché il
“Payload” deve
contenere il pacchetto IP, esso può avere lunghezza variabile a
seconda del
pacchetto IP. Può, quindi, spaziare da un minimo di 48 byte ad
un massimo di
1500 byte. Il frame termina con un ultimo campo di 4 Byte detto
“FCS” (Frame
Check Sequenze) o “CRC” (Cyclic Redundancy Code) che
contiene il checksum di tutto
il frame consentendone, entro alcuni limiti, la correzione di bit
errati
durante la trasmissione da parte del destinatario del frame senza
necessariamente richiedere una ritrasmissione.
Discutendo di
Ethernet e
pacchetti IP si sentirà spessissimo nominare la parola
“livello”. Ebbene, ciò
perché esiste al mondo un modello di riferimento a cui tutti i
protocolli di
comunicazione devono attenersi: questo modello si chiama modello
di riferimento ISO – OSI. Il modello ISO-OSI è uno
standard
creato dalla ISO (International Standard Organization) relativo
all’interconnessione di sistemi informatici aperti alla
comunicazione (OSI=
Open System Interconnection) ed è diviso in sette livelli:
Il modello di
riferimento,
detto anche pila ISO-OSI, si districa dal livello più basso, il
livello 1
ovvero quello fisico riferito al protocollo di standardizzazione del
mezzo
fisico di trasmissione dell’informazione fino al livello 7,
quello applicativo
che nei nostri computer in rete coincide con i software applicativi
(es. il
browser che utilizziamo per navigare). Il livello 1 è attinente
al metodo di
trasmissione, sia esso tramite segnali elettrici su cavo, tramite luce
su fibra
ecc. avendo a che fare con i bit. Il livello 7 è
l’applicazione, cioè il
software che gira sul nostro computer in rete e che non si preoccupa di
come
viaggino i bit e su quale mezzo ma solo di manipolare
l’informazione utile. Ad
esempio, il browser per navigare (Internet Explorer, FireFox o Opera),
non si
preoccuperà di come viaggiano i bit d’informazione sulla
rete ma è interessato
solo a codificare l’informazione utile del pacchetto IP per
mostrarci il
contenuto delle pagine web con i suoi testi, immagini, collegamenti
ipertestuali.
Se volessimo
fare
un’analogia con l’ethernet ed il pacchetto IP, diremo che
Ethernet è un
protocollo che coincide con il livello 2, mentre il pacchetto IP, o
meglio il
TCP/IP, con i livelli successivi, dal livello 3 al livello 7:
Una
scheda Ethernet non si preoccuperà di andare a leggere il
pacchetto IP dentro il
frame ma leggerà solo il “destination address” ed il
“source address” del
frame. Il contenuto del pacchetto IP lo cederà, così come
è, al computer, o
meglio a chi si dovrà occupare dei livelli superiori. Anche
l’HUB non andrà a
“spacchettare” il payload del frame per osservare il
pacchetto IP, ma osserverà
solo i MAC addresses contenuti in “destination address” e
“source address” del
frame Ethernet.
A sua volta il
pacchetto
(o datagramma) IP è così composto (diviso su due righe
per motivi di spazio):
Tutti i bit
che precedono
il campo “Dati” costituiscono l’header (intestazione)
del pacchetto IP.
I primi
quattro bit
del’header definiscono la versione del protocollo IP: quelle
maggiormente in
uso sono la versione 4, nota anche come ipv4 e la versione 6 o ipv6. In
questo
esempio consideriamo solo la versione 4, cioè quella attualmente
in utilizzo ed
accenneremo in seguito le differenze sostanziali dell’ipv6. I 4
bit “HLEN”
(Header LENght) codificano la lunghezza dell’header del pacchetto
. Il campo
“HLEN” è necessario perché essendo il campo
“Opzioni” di grandezza variabile, è
di lunghezza variabile anche tutto
l’header. “Service Type” serve per
implementare features di QoS (Qualità
of Service), consta di 8 bit, dove i primi 3 specificano un livello di
priorità
per i dati contenuti nel pacchetto che va da 0 (precedenza normale) a 7
(precedenza alta e controllo totale della rete). Altri tre bit vengono
denominati D, T, R. Quando sono attivati, il bit D richiede un basso
ritardo,
il bit T un troughput elevato (grosso flusso di dati), il bit R un'alta
affidabilità. Gli altri due bit non sono usati. “Lunghezza
totale” esprime la
lunghezza in bit di tutto il pacchetto, cioè header e dati. Il campo “Identificazione” contiene
un numero intero che
identifica il pacchetto. Serve per riassemblare il pacchetto se viene
frammentato. Questo campo è uguale per ogni frammento del
datagramma originale
(es. se un pacchetto IP numerato con “Identificazione”=8
viene frammentato in
quattro parti, questi quattro frammenti avranno nel campo
“Identificazione” il
numero 8, cosicché all’altro capo sarà possibile
comprendere come ri-assemblare
l’intero pacchetto frammentato). La frammentazione avviene se il
pacchetto deve
attraversare una rete in cui esiste un parametro detto di
MTU (Maximum Transfer Unit) di valore più
piccolo della lunghezza totale dello stesso pacchetto IP (vedi anche IP over ATM). Nel campo “Flags” ci sono
tre bit che specificano se il pacchetto IP può essere
frammentato oppure se è
l'ultimo frammento di un pacchetto. Il primo bit è quello di
"non
frammentazione" (DF), gli altri due indicano se il pacchetto è
l'ultimo
oppure bisogna aspettarne di ulteriori. I 13 bit di “Fragment
Offset”, invece,
costituiscono la numerazione interna dei frammenti (es. una volta
ri-assemblati,
grazie al campo “identificazione”, tutti i frammenti
appartenenti allo stesso
datagramma, c’è necessità di ordinarli nella giusta
sequenza). Il campo “TTL”
(Time To Live, cioè tempo di vita) è un contatore che
ogni router che viene
attraversato dal pacchetto decrementa ad ogni passaggio. Quando scade
il
pacchetto viene scartato ed il router invia un messaggio di errore al
mittente.
Serve per evitare i loopback. E’ facile accorgersi del TTL:
provate a lanciare
il comando ping verso un sito web conosciuto (es. ping www.google.it)
e noterete che comparirà un valore TTL ad ogni risposta:
Nel
caso della figura sopra il TTL è 245, ciò significa che
il datagramma IP
sopravviverà fino ad un massimo di 245 passaggi per i routers
della rete
Internet prima di poter giungere al web www.google.it.
Se per arrivare al web di Google dovesse passare per più di 245
routers, il
pacchetto morirebbe e noi avremmo la risposta di unreachable
(irraggiungibilità). A seguire il campo “Protocollo”
di 8 bit, identifica il
protocollo superiore al quale IP deve passare i dati ovvero, per essere
più
chiari, identifica che tipo di protocollo seguirà nel campo
“Data” ad es. UDP,
TCP ecc. che analizzeremo meglio di in seguito. Se
nei dati a seguire ci sarà un segmento TCP, il valore del campo
“Protocollo” lo avviserà col suo valore a 6, se UDP
a 17, se ICMP sarà 1 ecc.
“Checksum” è il codice checksum dell'header
IP. “Source” e “Destination IP Address”
sono i campi a 32 bit per gli
indirizzi IP di provenienza e destinazione.
Una
nota a parte meritano gli indirizzamenti IP. Il “Source IP
address” (32 bit)
contiene l’indirizzo IP dell’host che ha generato il
pacchetto IP, mentre
“Destination IP address” l’indirizzo IP del
destinatario. E’
interessante notare che anche nel frame Ethernet
esistono due campi simili (Destination address e Source address) ma di
natura
differente: nei campi Destination e Source address del frame Ethernet
troveremo
i MAC address delle interfacce di rete, che sono indirizzi fisici degli
host.
Diversamente, in “Destination” e “Source IP
address” del pacchetto IP
entrocontenuto nel frame Ethernet troveremo due nuovi codici
identificativi che
identificano gli stessi host non più a livello fisico ma ad un
livello più
alto: i livelli IP, appunto. Un indirizzo IP, a differenza
del MAC
address, non è legato fisicamente alla macchina e può
essere facilmente
cambiato, così come è semplice cambiare indirizzo IP al
nostro computer in
rete. Il formato di un indirizzo IP classico (quello che viene
utilizzato
attualmente) è standardizzato in RFC??? Ed è chiamato
IPv4 (IP versione 4). In
versione 4 il formato degli indirizzi è codificato da 32 bit in
binario, cioè
in 4 numeri decimali. Ad esempio il sito www.google.it
può avere tra i suoi indirizzi disponibili 209.85.129.99 che
tradotto in
binario equivale a 11010001.1010101.10000001.1100011. Sarà
proprio questa
sequenza di 0 e di 1 che verrà inserito nel campo a 32 bit
“Destination IP
address” del pacchetto IP generato dal nostro computer per
interrogare il sito
web di Google. In “Source IP address” ci sarà,
invece, l’indirizzo IP assegnato
alla nostro computer dall’Internet provider al momento della
connessione ad
Internet o, se dovesse trattarsi di una macchina in rete Internet con
indirizzo
pubblico l’IP address, l’indirizzo IP assegnato alla
macchina dalla IANA
(Internet Assigned Number Authority; l’ente internazionale che
assegna gli
indirizzi IP in tutto il mondo – vedi www.iana.org).
Per
convertire un qualsiasi numero decimale in binario basta affidarsi allo
schemetto di seguito riportato:
|
128 |
64 |
32 |
16 |
8 |
4 |
2 |
1 |
|
|
|
|
|
|
|
|
|
Se
si desidera convertire il numero decimale 209 basterà porre un 1
nelle caselle
la cui somma dei numeri porterà a 209
|
128 |
64 |
32 |
16 |
8 |
4 |
2 |
1 |
|
1 |
1 |
0 |
1 |
0 |
0 |
0 |
1 |
Infatti
128+64+16+1 è
uguale a 209. Ecco perchè la conversione binaria di 209 è
11010001. Se
ponessimo, invece, tutte le caselle ad 1 avremmo 255.
|
128 |
64 |
32 |
16 |
8 |
4 |
2 |
1 |
|
1 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
*In
verità per navigare
sui siti web, nessuno di noi si sognerebbe di conoscere a memoria gli
indirizzi
IP. Sarebbe, infatti, come dire che per raggiungere www.google.it dovremmo digitare dal nostro browser 209.85.129.99. In realtà potremmo pure
farlo
e funzionerà di sicuro! Ma non potremmo certo ricordarci a
memoria i numeri
identificativi degli IP address di tutti i siti ed host che vorremmo
raggiungere: per questo ci viene in aiuto un servizio appartenente ad
IP
chiamato DNS (Domain Name Server) di cui si analizzerà meglio in
seguito.
Tornando al
datagramma IP,
dopo “Source” e “Destination IP address”
c’è un campo con numero di bit
variabile chiamato “Opzioni”. In questo campo ci sono
codici che identificano
le opzioni necessarie soprattutto per testare la rete e per il
debbunging. Le
principali sono: percorso di provenienza, registrazione del percorso e
contrassegno temporale. La prima specifica negli ottetti di dati gli
indirizzi
IP che il pacchetto è obbligato ad attraversare per giungere a
destinazione.
Serve per esempio per testare il troughput di un particolare percorso.
La
seconda invece consente ad ogni router che incontra il pacchetto di
inserire il
proprio IP Address per registrare il percorso compiuto. La terza
è molto simile
alla seconda, poiché il router inserisce oltre all'IP Address,
anche un
contrassegno temporale di 32 bit che fornisce la data e l'ora in cui il
gateway
ha elaborato il pacchetto.
Se andiamo
ancor più nello
specifico possiamo dettagliare meglio cosa vi è dentro il campo
“Data” del
datagramma IP: scopriremo alcuni importanti servizi dell’ IP. Dentro
il campo “Data” ci sono i livelli superiori
dell’IP definiti anche ULP (Upper Level Protocol). La
filosofia è:
più si entra nella matrioska del pacchetto, più saliamo
ai livelli superiori.
Come visibile
se torniamo
all’immagine comparativa con il modello di riferimento ISO-OSI,
il pacchetto IP
appena analizzato è considerato livello 3 (livello rete). Se
andiamo ancor più
dentro la matrioska, cioè nel campo “Data” del
pacchetto IP, scopriremo il
livello subito superiore: il livello trasporto o livello 4 è
quello del TCP –
UDP – ICMP – EIGRP.
Prima di
analizzare il
pacchetto TCP, UDP o ICMP cercherò di specificare brevemente la
funzione di
questi servizi. TCP ed UDP sono il livelli di trasporto dell’ IP:
il primo è
più affidabile, il secondo meno. UDP (User Datagram Protocol)
è un protocollo
di livello trasporto di tipo connection-less (senza connessione).
Connection-less significa che il livello si preoccupa solo di
incapsulare i
suoi dati e consegnarli al livello più basso per l’invio,
dopodichè se i dati
arrivino o meno a destinazione e/o in modo corretto non ha importanza.
TCP
(Tranfer Control Protocol) invece, come dice il suo nome, si preoccupa
di
effettuare opportuni controlli per sincerarsi del giusto trasferimento.
TCP,
quindi, a differenza di UDP, stabilisce una connessione con il livello
TCP
dell’altro host in comunicazione. Per questo motivo TCP è
più affidabile ma più
lento ed è perciò più adatto al trasferimento di
files, UDP è meno affidabile
ma più veloce ed è, quindi, più opportuno per il
trasferimento di dati voce o
applicazione real-time, dove pur se si verifica la perdita di qualche
segmento
di dati o la ricezione non corretta, ciò non determina
criticità. Se volessimo
fare un paragone banale, diremmo che TCP è l’equivalente
di una lettera. ICMP
(Internet Control Message Protocol) è il protocollo utilizzato
da alcune
applicazioni per testare funzionalità di rete e di Internet.
ICMP non porta
dati utili ad applicazione come il browser o la posta o altri simili,
porta
dati per l’analisi della rete: problemi di congestione, analisi
dei problemi di
rete, troubleshooting, annunci di timeout. ICMP è il protocollo
utilizzato da
una classica applicazione come il ping che è utile per
verificare la
raggiungibilità di un host e prevede una serie di risposte come
la
raggiungibilità (reply), l’irragiungibilità
(unreachable) o sulla congestione
(source quench) o i ritardi (timeout).
Attenzione! ICMP non viene utilizzato dall’applicazione
traceroute (comando
tracert su Windows) per controllare il percorso di un pacchetto IP:
traceroute
utilizza UDP!
ICMP spesso
viene
disabilitato su alcuni server poiché questo protocollo è
notoriamente
utilizzato come ABC per le analisi degli Hacker. Il fatto di non
ricevere un
reply pingando un server non significa che il server sia
malfunzionante: può
darsi che sia stato disabilitato ICMP su quel server per motivi di
sicurezza.
Volendo potremmo banalizzare associando ad raccomandata con ricevuta di
ritorno
il TCP, mentre UDP è una semplice lettera in posta ordinaria.
Volendo
addentrarsi ancora
di più nella matrioska, ed analizzare come le applicazioni
scelgono i
protocolli di livello 4, sarebbe molto interessante installare sul
proprio PC
Windows un cosiddetto “sniffer” ethernet: un programma che
legge e cattura
tutto quello che accade su una rete LAN con Ethernet. Da www.wireshark.org è possibile scaricare WireShark
e da www.ethereal.com lo sniffer Ethereal. Entrambi sono
software free
ma io preferisco ed uso WireShark e qui di seguito incollerò
alcuni
print-screen prelevati da una catturazione di poco più di un
minuto sulla mia
rete wireless di casa. Attualmente la mia rete wireless è
composta da un
wireless ADSL router USRobotics (IP 192.168.1.1) a cui mi collego con
un
computer portatile con hostname Solomone (192.168.1.3) via WiFi. Al
router
USRobotics è anche collegato via cavo un disco autonomo di rete
(quelli
generalmente chimati NAS Network Attached Storage) con IP 192.168.1.4
ed un
computer desktop con Linux Ubuntu 6.10 avente indirizzo IP 192.168.1.2
ma
temporaneamente spento.
|
Router ADSL gateway |
192.168.1.1 |
|
Computer Desktop Linux |
192.168.1.2 |
|
Computer
portatile |
192.168.1.3 |
|
Disco
di rete NAS |
192.168.1.4 |
Con il desktop
spento,
provo a catturare il traffico di questa piccola LAN domestica per poco
più di
un minuto collegandomi prima al sito www.flamenetworks.com e poi con una seconda sessione di
Internet
Explorer a www.cirocarbone.it, poi
infine mi collego al mio disco di rete. Catturo ed analizzo e noto
subito che i
primi pacchetti sono di tipo ARP.
2.1 ARP
ARP è
spessissimo
utilizzato in IP e ne troveremo pieni i buffer di catturazione di
WireShark.
ARP (Address Resolution Protocol) è il protocollo utilizzato nel
mondo IP per
associare il MAC Address di un host al suo indirizzo IP.
Provate a navigare un po’ in Internet e
subito dopo digitate dalla vostra macchina Windows il comando arp
–a; noterete
probabilmente un output simile a questo:
In questa
tabellina di due
righe, detta tabella ARP, il mio computer contiene l’associazione
dei MAC
address di due host aventi indirizzo IP 192.168.1.1 e 192.168.1.4. Si
badi bene
che queste informazioni sono di tipo dinamico, cioè permangono
in memoria solo
per un po’, dopodichè verranno automaticamente cancellate
da ogni computer (su
Windows dovrebbero durare circa 10 minuti). A cosa serve questa tabella
ARP?
Questa tabella è indispensabile a ciascun host in rete,
poiché se il computer A
vuole parlare con B dovrà conoscere innanzi tutto il MAC address
per costruire
la frame Ethernet ed anche l’indirizzo IP di B per costruire,
poi, il pacchetto
IP da inserire nella frame. Come fa un host a conoscere gli indirizzi
IP e i
MAC address della sua rete LAN? Semplice: ciascun host invia sulla rete
LAN,
automaticamente e senza che ve ne accorgiate, alcuni frame e pacchetti
chiamati
broadcast (cioè diretti a tutti) a cui gli altri host della rete
LAN rispondono
comunicando il proprio MAC address ed il proprio indirizzo IP. Questi
due dati
verranno poi memorizzati nella tabella ARP da tutti gli host che
ascoltano
questa doppietta di dati sulla rete. I frame Ethernet di tipo broadcast
partono
da un mittente ma, essendo diretti a tutti, hanno come destinatario il
campo
Destination Address con i bit tutti a 1 (valore esadecimale FF).
Esistono,
inoltre, due tipi di broadcast: il directed broadcast ed il local
broadcast. Il
local broadcast si verifica quando l’host interroga tutti e
chiunque è libero
di rispondere. Il directed broadcast è inviato fisicamente a
chiunque sulla
rete solo perché il mittente del broadcast ha cancellato
(probabilmente per
inattività o rimozione) l’associazione indirizzo IP e MAC
address di un
determinato host. Pur leggendolo tutti, il directed broadcast, è
come se fosse
un urlo ad un determinato host sulla rete.
Nella prima,
seconda e
terza riga del print-screen, il router (USRoboti_20:4c:bb – gli
ultimi dati
corrispondono agli ultimi byte in esadecimale del suo MAC address), che
funge
da gateway e server, chiama l’host 192.168.1.2, aspettandosi che
risponda col
suo MAC address, cosicché poter aggiornare la sua tabella ARP.
In realtà, il
router non ha la tabella aggiornata per 192.168.1.2 poiché
quest’ultimo è stato
volutamente spento. L’host 192.168.1.2 (computer Desktop Linux),
essendo stato
spento ed assente dalla rete, non può rispondere e quindi il
broadcast sarà
disatteso. Il pacchetto IP entrocontenuto nel frame è di tipo
ARP e ciò si
intuirà dal codice 0x806 nel campo “type” del frame.
Comunque, lo sniffer
correda comodamente dei commenti abbastanza chiari: Who has
192.168.1.2? Tell
192.168.1.1 … che tradotto è: Chi ha
indirizzo 192.168.1.2? Dica a me 192.168.1.1. Notare nella parte
bassa il
“Destination” della frame Ethernet a ff:ff:ff:ff:ff:ff (non
si conosce, infatti,
il MAC del destinatario e perciò viene generato questo directed
broadcast) ed,
inoltre, il Destination del pacchetto IP settato a 192.168.1.2 e del
Source a
192.168.1.1.
Nella quarta
riga subentra
un nuovo host, il portatile con indirizzo 192.168.1.3, che chiede con
un
directed broadcast il MAC address del router. Nella quinta riga il
router
risponde al portatile dandogli il suo MAC address. A questo punto il
portatile,
avendo aggiornato la sua tabella ARP, può comunicare col router
qualora
volesse. Si noti che queste prime cinque righe sono tutte di tipo ARP,
ovvero
utilizzate dagli host di rete per aggiornare le loro tabelle ARP ed
avere le
associazioni tra indirizzo IP e MAC address. ARP è un protocollo
non utilizzato
direttamente dalle applicazioni IP ma su cui le applicazioni si
appoggiano
indirettamente. E’ direttamente implementato in Ethernet (livello
2) ma può
essere invocato automaticamente e/o indirettamente dalle applicazioni
IP.
2.2 DNS
Si è
già accennato al
protocollo DNS. Ora lo osserviamo con maggiore dettaglio nella sesta e
settima
riga dell’immagine sopra. In concomitanza con la sesta riga ho
aperto il
browser Internet ed ho digitato l’indirizzo www.flamenetworks.com Il mio computer portatile non ha
però l’indirizzo
IP né il MAC address del sito web in questione ed allora chiede
al router
delucidazioni (il router funge anche da DNS server, poiché
l’ho settato io come
server DNS nelle impostazioni TCP/IP di Windows quando ho messo
“in piedi” la
rete). Il router riponde al portatile (riga 7)
dandogli l’ip address del sito web (84.200.25.7) ma non il
MAC address.
Quest’ultimo dato, il router se lo conserva per se, poiché
essendo lui il
gateway verso l’esterno della rete LAN e non essendo,
l’host di www.flamenetworks.com , riconosciuto sulla rete LAN,
dovrà essere lui a
fare da tramite verso il mondo Internet. Il portatile allora, comincia
a
costruire frame Ethernet in cui il Destination MAC address è
quello del router
mentre il Destination IP address del pacchetto IP è quello di www.flamenetworks.com (riga 8). In verità quello che
ci racconta lo
sniffer è solo limitato alla mia rete locale LAN. Quello che
accade fuori,
verso Internet, non viene visto. Il router avrebbe potuto non avere
l’indirizzo
IP di www.flamenetworks.com,
magari perché non ero mai andato su questo sito prima di allora.
Allora, come
ha fatto, il router, a procurare questo indirizzo ip 84.200.25.7 al mio
pc
portatile?
Per
rispondere
a questa domanda dobbiamo aprire un parentesi e spiegare come funziona
il
meccanismo di ricerca degli indirizzi IP a partire dal nome del dominio
web.
Facciamo
attenzione quando
parliamo di DNS (Domain Name Server): per DNS si identifica
impropriamente sia
il protocollo usato dall’applicativo (vedi righe 6 e 7), sia un
oggetto fisico
vero e proprio. L’oggetto fisico altro non e’ che un
particolare server, inserito
nella rete Internet, che contiene tabelle con la corrispondenza tra i
nomi dei
siti ed i relativi indirizzi IP (ad esempio www.repubblica.it
à
213.92.16.191). I server
DNS sono sparsi per il mondo e si dividono due tipologie: autoritativi
e non
autoritativi. I server DNS autoritativi sono quelli ufficiali, gestiti
da enti
e riconosciuti universalmente. I server DNS non autoritativi non
contengono
informazioni ufficiali e sono creati e gestiti dai providers che
forniscono la
connettivita’ alla rete internet.
I DNS
autoritativi sono
strutturati gerarchicamente e sono di tre tipi, chiamati
rispettivamente:
1)
root DNS
2)
DNS delle Registration Authority
3) DNS
Authoritative
I DNS non
autoritativi
(quelli dei providers) sono, invece, i DNS di comunicazione
I server DNS
principali e
gerarchicamente piu’ importanti sono i root DNS (detti
anche DNS di
primo livello) e che costituiscono la struttura base della rete
Internet. I
root DNS sono server autoritativi, gestiti da enti ufficiali e
hanno la
responsabilità di indirizzare la ricerca verso altri DNS,
gerarchicamente
inferiori, sulla base del primo livello del nome del dominio,
cioè di ciò che
viene evidenziato dopo il punto del nome del servizio web ricercato. Ad
esempio, un root Server conterra’ informazioni relative a tutti i
domini di
primo livello come i .com, .net, .org, .it, .fr, .info ecc. ed i
riferimenti
per smistare l’indirizzamento ai Server DNS di secondo livello.
Ciascun root
DNS ha un indirizzo nel formato x.root-server.net, in cui x
e’ una lettera
che varia da “a” a “m” (quindi esistono 13 root
server in tutto il mondo vedi http://www.root-servers.org/).
Sotto i
root DNS ci sono i DNS delle Registration Authority, gestiti
da vari
enti riconosciuti anch’essi a livello internazionale e quindi
anch’essi
autoritativi. I DNS delle Registration Authority contengono
tutti i
domini di una specifica competenza: ad esempio tutti i domini .it su
tutto il
territorio italiano sono contenuti nei DNS di secondo livello gestiti
da enti
come CNR (Consiglio Nazionale Ricerche), NIC (www.nic.it),
la societa’ COGENT (www.cogentco.com) ecc..
Continuando, sotto i DNS di Registration Authority, ci sono i
DNS
Authoritative che contengono i dati specifici dei domini. Essi sono
gestiti
dagli MNT’s (mainteners), cioe’ dalle aziende che
effettuano housing ed hosting
degli spazi web (ad esempio www.sarkom.it o www.aruba.it).
Esistono, poi, i server DNS di connessione
che sono quelli che utilizziamo puntualmente noi utenti navigatori
durante le
varie operazioni su Internet. I DNS di connessione sono gestiti
dai
providers di connessione che ci garantiscono, quindi, la
connettivita’ ad
Internet (es. Telecom Italia, Tele2, Libero, Tiscali, Vodafone ecc.) e
non sono
di tipo autoritativo.
Per meglio
comprendere
come avviene l’interrogazione dei vari tipi di DNS assumiamo un
esempio banale
in cui si vuole visitare il sito internet www.prozone.it
digitandolo nella barra
degli indirizzi del nostro browser. La prassi normale e’ che il
primo DNS che
verrà interrogato e’ il DNS di connessione del
nostro provider. I DNS
di connessione dei providers hanno una cache interna che memorizza
per un
tempo determinato l’associazione nome à
IP address. Se il nome del sito web e’ ancora presente nella
tabella dinamica della cache del DNS del nostro provider, il processo
si
concludera’ con la restituzione diretta dell’IP address
interessato. Se il nome
del sito web non’è presente nel DNS di connessione,
quest’ultimo
effettuerà in sequenza i tre passi sotto elencati:
1)
contattera’ tutti i root DNS e questi ultimi
notificheranno al nostro
DNS di connessione i DNS di Registration Authority che
gestiscono i
domini di primo livello .it;
2)
il nostro DNS di connessione contatta allora, uno per uno, tutti
i
DNS di Registration Authority comunicati inviandogli il nome
“repubblica.it” finche non trova il DNS di Registration
Authority che
gli risponde comunicandogli i DNS autoritativi che contengono
gli
indirizzi IP del sito www.repubblica.it;
3)
il DNS di connessione, allora contettera’, uno dopo
l’altro, i DNS
Authoritative del maintener del sito di repubblica.it per ottenere
finalmente l’indirizzo IP del sito web che vogliamo visitare.
Ecco un
esempio pratico di
ciò che accade analizzato con l’ausilio di un codice:
quando
inserisco questo
indirizzo nel mio browser e premo il tasto invio, il DNS del mio
provider di
connessione interroga i root DNS che
rispondono all'indirizzo x.root-servers.net dove “x”
e' una lettera che
può essere variabile dalla “a” alla “m”.
|
CODE |
Questi root
DNS rispondono, quindi, che tutti i
domini “.it” sono gestiti dai seguenti DNS dove il primo
è primario e tutti gli
altri sono secondari:
|
CODE |
Da queste due
schermate e’ possibile notare che
sia i “Root DNS” che i “DNS delle Registration
Authority” sono disclocati su
diversi continenti, e diverse reti, così che nel caso di guasto
di un singolo
server o di non raggiungibilità di una certa rete non vengano
‘oscurati’ in un
colpo decine di migliaia di siti web.
Andando avanti, i DNS del nostro provider interrogano, quindi, a
partire dal
primo in lista, i DNS della Registration
Authority che nel caso di prozone.it rispondono come segue:
|
CODE |
Ora che
finalmente hanno
trovato i DNS autoritativi per il nome a dominio vanno ad interrogare i
DNS di
cui sopra (ns1.th.seeweb.it e ns2.th.seeweb.it) a partire dal primo in
elenco,
ottenendo l’agognato indirizzo IP che ci serviva.
|
CODE |
Torniamo al
nostro
esempio tracciato col programma WireShark ed analizziamo le righe 6 e
7. Il
primo passo (riga 6 di WireShark) mostra una prima riga contrassegnata
come DNS
(qui si intende l’utilizzo del protocollo da parte
dell’applicazione Internet
Explorer per le funzionalita’ di query sui DNS). Qui il mio
portatile effettua
una query standard di tipo A (Any record) al router (che funge anche da
piccolo
DNS locale). Quest’ultimo potrebbe avere o meno
l’associazione dei dati per
questo sito desiderato. Se l’associazione esiste già,
risponde direttamente al
portatile comunicando l’indirizzo IP 84.200.25.7 del sito che
volevamo
visitare, cioe’ www.flamenetworks.com, altrimenti nel lasso temporale tra la
riga 6 e la
riga 7, la “patata bollente” verrà scaricata dal mio
router al DNS di comunicazione del mio provider
che si dovrà necessariamente impegnare a sviluppare tutto il
flusso poc’anzi
descritto.
2.3 TCP
(continuare)
Proseguendo
con il
tracciamento effettuato con WireShark, poiché ho deciso di
aprire la pagina del
sito web www.flamenetworks.com , l’applicazione
(cioè il browser), ottenuto l’indirizzo IP dal DNS,
è pronto per instaurare una
connessione TCP con questo sito web. Volendo essere piu’ preciso,
cio’ che si
instaura e’ uno “streaming” (flusso) o per dirla
tecnicamente un Socket.
Affinche’ si possa stabilire questa connessione virtuale tra il
mio computer ed
il web server che contiene le pagine di www.flamenetworks.com
e’ indispensabile
introdurre il
concetto di porte Si immagini che il web
server stia servendo
contemporaneamente piu’ utenti i quali stanno navigando, nello
stesso lasso
temporale, le sue pagine: come fa il web server a discriminare i vari
client ? Come puo’ il web server
distinguere i vari
flussi di connessione, ovvero i differenti Socket?
La
discriminazione avviene grazie all’utilizzo del TCP delle porte.
Una porta non
e’ affatto un qualcosa di fisico ma virtuale: altro non e’
che un numero
identificativo di un Socket. Questo numero di porta e’ valore che
segue
l’indirizzo IP, sia di destinazione che sorgente. Avremmo,
quindi, che
interrogando www.flamenetworks.com
, l’indirizzo completo di destinazione, comprensivo di porta,
potrebbe essere www.flamenetworks.com:80.
Viceversa se
un qualche host del mondo esterno genera dei pacchetti destinati a noi,
questi
pacchetti avranno il nostro indirizzo IP nel destination address
seguito da un
numero di porta <nostro_indirizzo_IP>:1513
Figura pacchetto TCP
La
porta
diviene l’identificatore della sessione tra noi e l’altro,
ovvero del Socket,
ovvero del flusso di comunicazione. Supponiamo, ad esempio, di aprire
il nostro
internet browser e di iniziare a navigare sul sito www.repubblica.it ;
contemporaneamente,
supponiamo di aprirne un secondo e di avviare una nuova navigazione
sempre
sullo stesso sito internet www.repubblica.it:
avremmo due Socket differenti con porte differenti, ovvero due flussi
differenti distinti ed indipendenti tra due host identici (il nostro
computer
ed il web server di repubblica.it). E’ grazie alle porte distinte
che il nostro
computer discriminera’ i flussi di dati provenienti dal medesimo
web server di
repubblica.it per dirigerli verso le appropriate sessioni di
navigazione
internet: se cosi’ non fosse, i contenuti si mischierebbero.
L’uso
della
scelta della porta e’ in parte nota ed in parte casuale. In
verita’ la IANA ha
stabilito un certo numero di porte definendole well-known-ports
(porte ben conosciute): le porte dalla 0 alla 1023
sono well-known-ports e sono universalmente associate a determinati
servizi IP.
Se consultiamo la pagina http://www.iana.org/assignments/port-numbers
troveremo una lunghissima lista di porte tra cui le prime 1024
riservate a
specifici servizi. Volendo riassumere i servizi piu’ conosciuti
tra le
well-known ports si osservi la tabellina sottostante.
Per
meglio
comprendere il significato delle porte di questa tabella, e’ bene
chiarire che,
generalmente, queste porte sono quelle utilizzate dai server,
cioe’ da tutte
quelle macchine che in Internet svolgono la funzione di prestatore di
servizi
agli utenti. Ad esempio, se vogliamo scaricare la posta tramite il
nostro
client di posta elettronica (Outlook, Evolution, Eudora e
quant’altro),
configureremo quest’ultimo col nome del server e se il nostro
mail Server
lavorasse in pop-3, l’interrogazione dal nostro computer verso il
mail Server,
avverra’ di sicuro sulla porta 110.
Questo è il motivo per cui TCP e UDP hanno il concetto di porte.
Ogni pacchetto
contiene un campo per la `porta destinazione' che serve a indicare a
quale
servizio è diretto il pacchetto (l’insieme
dell’indirizzo e la porta prende il
nome di Socket). Per
esempio, alla
porta TCP 25 corrisponde il mail server, alla porta TCP 80 corrisponde
il web
server (sebbene qualche volta si possa trovare il web server anche su
porte
differenti). Una lista delle porte si può trovare nel file
`/etc/services'.
Inoltre se due finestre di Netscape stanno entrambe accedendo allo
stesso sito
web ma a pagine differenti, come fa la Linux box che esegue Netscape a
indirizzare correttamente i pacchetti di ritorno provenienti dal web
server ?
E' a questo punto che interviene la `porta
sorgente': ogni nuova connessione TCP si appropria sempre di una porta
sorgente
diversa, in questo modo possono comunicare indipendentemente, anche se
devono
utilizzare lo stesso indirizzo e porta di destinazione. Di solito la
prima
porta sorgente assegnata sarà la 1024, poi saranno assegnate le
successive.
2.4 Conclusioni
La
applicazioni
decideranno se scegliere TCP o UDP o ICMP. Le applicazioni, come
già accennato,
sono il browser per navigare in Internet (http), la posta elettronica
per
inviare mail (smtp) o per riceverle (pop3 o imap), per testare la
raggiungibilità di un host (ping), per testare il percorso fatto
dal pacchetto
(tracert), per aprire una sessione terminale (telnet), per scaricare
file (ftp
o tftp) ecc.
|
HTTP, HTTPS , SMTP, POP3, IMAP, FTP, DNS, SSH, IRC, SNMP, SIP, RTSP, Rsync, Telnet, HSRP, BitTorrent, ... |
|
|
Livello di rete |
|
|
Livello di collegamento o linea |
|
|
Doppino, Fibra ottica, Cavo coassiale, |
- Bridge e Switch
Con le reti di
tipo BUS,
sia realizzate con bus coassiale che con HUB, possiamo realizzare una
rete LAN
anche abbastanza estesa con molti host ma sempre con un grosso
svantaggio:
tutti gli host appartengono sempre alla stessa collision-Domain. Il
problema
esposto della collisione si ingigantisce esponenzialmente nelle reti
LAN in cui
coesistono molti host poiché, come è comprensibile, si
incrementa notevolmente
la probabilità di maggiori collisioni, maggiori tempi di attesa
dei timer e
maggiori ritrasmissioni di frame. Tutto questo si traduce in un
semplice
inconveniente: rallentamento delle comunicazioni in rete. Più
host collegheremo
in una collision-Domain, più la rete LAN rallenterà e
diverrà meno efficiente.
Per ovviare
all’inconveniente si pensò di dividere una rete LAN in
più collision-Domain e ciò
fu possibile tramite un apparato con funzionalità specifiche
chiamato Bridge.
Il
Bridge (in italiano ponte) è una macchina che, interposta tra
due bus o due HUB
di una rete LAN, stabilisce quali frame Ethernet far passare e quali no
sulla
base si una sua tabella interna chiamata Bridging table.
Così
facendo, il Bridge riesce a scindere una LAN in due o più
collision-Domain.
Il Bridge
è una macchina
ad auto-apprendimento ed ha insita due funzioni fondamentali di cui la
prima è
chiamata “Learning” che tradotto significa imparare.
Nella figura
sopra, si è
supposto di dividere una rete LAN a bus in due bus distinti,
cosicché da avere
un miglioramento delle performances. Cerchiamo ora di capire come
può un Bridge
dividere una singola LAN in due collision-Domain migliorando le
prestazione
della LAN stessa. Se l’host A genera una frame Ethernet destinata
all’host C,
questo frame si propagherà su tutto il primo bus e verrà
inequivocabilmente
letto da tutti gli host che condividono il primo bus (cioè B, C
e l’interfaccia
I1 del Bridge). Supponiamo inoltre che il Bridge sia nuovo e non abbia
nulla
nella sua bridging table. Il Bridge, leggendo il frame generato da A
(ed in
particolare leggendo il campo “Source Address”),
comprenderà che sul bus che si
affaccia sull’interfaccia I1 esiste un
host con un determinato MAC address: questo dato se lo segna
nella sua
bridging table. Allo stesso modo anche gli altri host genereranno,
prima o poi,
dei frame ed il Bridge, dopo un po’ avrà completato la sua
fase di learning, completando
la sua bridging table per questa rete LAN. Questi dati, il Bridge, li
terrà
nella sua tabella per un tempo determinato, dopodichè, se non
vede traffico da
parte di determinati host li cancella. La sua bridging table
sarà somigliante a
qualcosa del genere:
|
Interface |
MAC
Address |
|
I1 |
MAC
dell’host A |
|
I2 |
MAC
dell’host D |
|
I1 |
MAC
dell’host C |
|
I1 |
MAC
dell’host B |
|
I2 |
MAC
dell’host E |
La seconda
operazione
fatta da un Bridge, oltre al learning, è il “filtering
& forwarding”. Con
l’ausilio di questa sua tabella il Bridge può capire se un
frame deve passare o
meno sull’altro bus (filtering) e, nel caso il frame debba
passare, lo inoltra
(forwarding). Ad esempio, se A vuole parlare con E, genera il suo frame
che
verrà letto dal Bridge sull’interfaccia I1. Il Bridge
legge destination e
source address del pacchetto e comprenderà che il frame è
generato da A e
destinato ad E. Consulta, allora, la sua tabella e comprende che E
è attestato
all’interfaccia I2 per cui propagherà il frame da I1 ad
I2. Lo stesso frame
verrà letto anche da B e C e dopo la propagazione anche da D ma
B, C e D,
leggendo il destination address si accorgeranno di non essere i
destinatari e
quindi lo scarteranno. La situazione cambia, però, se A vuole
parlare con B o
con C: in tal caso il Bridge leggendo il frame generato da A e
consultando
sempre la sua tabella, comprende che il destinatario è sullo
stersso bus del
mittente e quindi non applica il forwarding sul secondo bus. In
quest’ultimo
caso si può ben comprendere che gli host D ed E non verranno
oberati del
traffico di A, B e C e in complesso diminuiranno drasticamente le
probabilità
di collisione. In sostanza A, B e C potranno parlare tra loro senza
oberare
inutilmente l’altro bus e così anche D ed E. La
situazione, però, non cambia se
due host dei due bus distinti devono parlare tra loro, poiché
col forwarding,
la rete LAN è come se non avesse alcun Brige.
Col Bridge, in
sostanza,
abbiamo due o più collision-Domain su una stessa LAN.
Al giorno
d’oggi trovare
un Bridge è come cercare un quadrifoglio in un prato di
trifogli. Di Bridge non
se ne usano più perché questa macchina è nata come
funzione software da far
girare su un normale computer: in pratica non esiste una vera e propria
macchina chiamata Bridge; piuttosto esiste un software che gira su un
computer
che lo trasforma in un Bridge. Per questo motivo il Bridge, ovvero
computer con
software di Bridging, è una macchina sostanzialmente lenta per
le esigenze
odierne. La sua evoluzione è un dispositivo dedicato velocissimo
e praticissimo
e che lo ha sostituito quasi immediatamente: lo Switch!
Lo Switch
fonda la sua
potenzialità sull’hardware: è una macchina
totalmente dedicata alle funzioni di
commutazione dei pacchetti Non hanno un vero e proprio software; anzi
parlare
di software su uno switch è un po’ anacronistico: è
meglio parlare di firmware!
Tutto ciò la rende una macchina velocissima che non può
essere paragonata a
Bridge ed Hub.
- Reti WAN
- Router
(mettere
in evidenza in questo capitolo la connectionless del mondo IP)
- MPLS
MPLS è
un termine che ascolteremo e leggeremo sempre più spesso nelle
tematiche
inerenti al mondo IP. E’ acronimo di Multi-Protocol Label
Switching che
tradotto potrebbe somigliare a “Commutazione multi-protocollo su
base
etichetta”. MPLS è sostanzialmente il tentativo di
migliorare la qualità di
servizio del mondo IP e di renderlo più affidabile per il
trasporto di nuovi
servizi con caratteristiche real-time come la voce e i flussi video. In
altre
parole costituisce un tentativo di forzare una connessione come la IP
che
nativamente è di tipo connectionless in un surrogato di
connessione
connection-oriented. L'avvento di servizi di telefonia mobile con
contenuti
Internet, voce su IP (VoIP – Voice over IP), messenger con
funzionalità di
videochiamata hanno spinto alla ricerca di sistemi migliorativi circa
l'affidabilità di consegna delle informazioni da parte del mondo
IP. Ad
esempio, per poter garantire un flusso di streaming video o di
streaming audio
senza scollamenti e senza interruzioni oltre che senza perdità
significativa di
dati, anche su lunghissime distanze, significa dover garantire maggiore
qualità
di servizio (QoS – Quality of Service) su rete IP.
- Indirizzi IP, classi e Subnet Mask
- NAT, Virtual Server e
Virtual Host
E’
il NAT che ha salvato Internet, o meglio, che ha salvato gli indirizzi
secondo
il classico formato a 4 ottetti che tutti conosciamo come ipv4. Se non
fosse
stato per il NAT, l’indirizzamento ipv4 sarebbe già morto
entro il 2000/2002,
secondo quanto dichiarava la IANA nel 1998. NAT è acronimo di
Network Address
Translation, ovvero Traduzione dell'indirizzo di rete. Pensate a tutti
i
routers domestici, i codiddetti routers SOHO (Small Office Home
Office), che i
produttori hanno venduto in giro per il mondo in tutte le varianti con
o senza
file (WiFi). Ma non solo... pensate a tutte le periferiche di rete
vendute in
seguito allo sviluppo di queste reti domestiche: dalle stampanti di
rete, ai
dischi NAS (Network Atached Storage, cioè i dischi di rete).
Ebbene, se
ciascuna periferica necessita di un proprio indirizzo IP, lo spazio che
IANA
avrebbe assegnato alle reti private non sarebbe sicuramente stato
sufficiente.
Per
ovviare all’impossibilità di connettere ad Internet e di
interconnettere tra
loro, reti con indirizzi identici, gli stessi produttori dei prodotti
per reti
SOHO hanno escogitato ed implementato la funzione NAT. La funzione NAT
è sempre
implementata nel dispositivo terminale collegato alla rete Internet:
tipicamente il modem. Tuttavia oggi si è largamente diffuso un
congegno che
integra tutte le funzioni di router, Access Point WiFi, e modem DSL: il
WiFi-ADSL-Router
In
tutti i Wifi-ADSL-Router è sicuramente implementata la funzione
NAT.
Detto
in parole povere, la
funzione NAT consiste nel
manipolare i pacchetti IP ed in particolare il campo Source IP address
dei
frame uscenti dalla propria rete verso il mondo Internet.Mentre
all’interno della propria rete SOHO i pacchetti generati dai vari
Host avranno
nel campo Source Address il proprio indirizzo IP appartenente alla
gamma
192.168.1.1-192.168.1.254, se uno dei dispositivi vuole comunicare
verso la
rete Internet, il WiFi-ADSL-Router o il modem, applicando la NAT, non
farà
altro che cancellare il suo indirizzo privato che inizierà con
192.168.1 con
quello pubblico assegnato dal provider, che ci garantisce la
connettività ad
Internet, al momento della connessione.
Avrete
notato che quasi tutti i routers SOHO hanno un indirizzo univoco pari a
192.168.1.1 e possono realizzare reti domestiche, sfruttando una classe
C con
indirizzi da 192.168.1.1 a 192.168.1.254, quindi con subnet mask
255.255.255.0.
Finché tutte le reti SOHO con classe 192.168.1.1/24 fossero
indipendenti ed
isolate tra loro e dal mondo Internet non avremmo alcun problema ma
volendo,
inoltre, consentire la connettività su internet, il problema si
incontrerebbe
nella non univocità degli indirizzi IP: non potrebbero
coesistere su Internet
duo o più indirizzi 192.168.1.1 o generalmente più
dispositivi con gli stessi
indirizzi in classe 192.168.1.1/24. E’ bene chiarire comunque che
per direttive
IANA mai dovrebbero presentarsi su Internet dispositivi con indirizzi
che
rientrano nella gamma degli indirizzi privati.
Nell’esempio
del disegno qui in alto, il NAT del router manipola il pacchetto IP
proveniente
dal computer desktop 192.168.1.2 della sua rete, sostituendogli il
Source
Address 192.168.1.2 con l’IP pubblico 83.190.11.132 assegnato
durante la fase
di connessione Internet. Il computer desktop, difatti, vuole aprire una
sessione per interrogare un sito web con indirizzo 83.190.11.132. Il
router,
svolgendo la funzione di gateway, inoltra sulla rete WAN Internet il
pacchetto
ma sostituendogli il source IP address 192.168.1.2 (che non potrebbe
essere
inoltrato all’esterno, sulla rete Internet, perché
è un indirizzo privato) con
l’indirizzo pubblico che il provider, garante della connessione
Internet, gli
ha assegnato per consentirgli l’accesso in Internet.
La
funzione NAT è quindi assimilabile ad una sorta di
“multiplessaggio” dei molteplici indirizzi in una rete
privata SOHO verso
l’unica porta (gateway) che conduce al mondo esterno di Internet.
La
funzione di Virtual Server, anch’essa implementata nei
WiFi-ADSL-Router, è invece la funzione opposta alla NAT, ovvero
comparabile ad
un “de-multiplessaggio” dal mondo Internet alla nostra rete
SOHO.
Difatti,
qualsiasi dispositivo della nostra piccola rete domestica, dal mondo
esterno di
Internet, è identificabile genericamente tramite
l’indirizzo pubblico
assegnatoci dal provider di connessione, ovvero 83.190.11.132.
Nell’esempio,
riportato sopra in figura, qualsiasi dato proveniente
dall’esterno e diretto a
noi, come può essere il contenuto web in risposta ad una nostra
interrogazione, può raggiungerci
grazie
all’univocità dell’indirizzo IP assegnatoci dal
provider al momento della
connessione. Cosicché se il nostro indirizzo è
83.190.11.132, chiunque
dall’esterno può raggiungerci (grazie ai DNS di
connessione del provider e
grazie alle tabelle di routing dei routers dello stesso provider).
Supponiamo, però,
che la richiesta di dati l’abbia fatta il computer desktop con
indirizzo IP
192.168.1.2 e che, quindi, quest’ultimo stia aspettando i dati di
risposta
dall’esterno.
Come
può il router discriminare quale dispositivo della sua rete, fra
i cinque
(poiché il destinatario potrebbe essere anche lui), debba essere
il
destinatario ? Di sicuro non potrebbe capirlo subito, dal momento in
cui si
vede arrivare pacchetti IP con destination address 83.190.11.132 che
identifica
genericamente tutta la nostra rete domestica e che non discrimina quale
dispositivo della nostra rete è il destinatario. Il router non
può sbagliare
inviando, magari dati non desiderati di una pagina web, al notebook
192.168.1.3, il quale non ha effettuato nessuna richiesta. Né
tantomeno al NAS
o la stampante.
La
soluzione sta nell’uso delle porte!
Quando
il router si è fatto da tramite per inoltrare la richiesta del
computer desktop
(vedi figura su argomento NAT) oltre ad aver applicato la funzione NAT
ed
inoltrato il pacchetto verso Internet ha anche memorizzato la porta con
cui il
computer desktop ha inoltrato la richiesta. La risposta con i dati
proveniente
dall’esterno avrà sicuramente una porta che è
progressiva a quella della
richiesta (ad esempio se la richiesta del computer desktop è
iniziata su porta
80??? la risposta avrà valore di porta 80+1=81).
Analogamente
alla funzione Virtual Server, anche i Web Server che immagazzinano i
contenuti
dei siti web, sfruttano la funzione di Virtual Hosts. Un Web Server
è un
software che gira su un computer con determinate caratteristiche (a
volte anche
apparentemente meno potenti dei nomali pc e workstation da tavolo). I
software
di Web Server sono svariati e dipendono dalla piattaforma del sistema
operativo. Ad esempio se il server dispone di un sistema operativo
Windows
Server, disporrà sicuramente del Web Server di Microsoft,
chiamato IIS. Se gira
sotto Linux, molto probabilmente utilizzerà Apache che è
anche il Web Server
più diffuso al mondo! Il Web Server
prevede la divisione dello spazio del disco rigido o dei dischi rigidi
in
quote; ciascuna quota coincide con un web-host-name. Ad esempio, se il
Web
Server contiene tre siti web (www.cirocarbone.it, www.mercatino.net, www.pincopalla.com ) avrà
il suo disco diviso in tre quote, ove ciascuna quota è relativa
ai contenuti
web di ciascun sito. Il Web Server, essendo montato su un singolo
computer,
potrà avere un solo indirizzo IP, ovvero l’indirizzo IP
assegnato a quel
computer. Supponiamo che questo indirizzo equivale a 85.200.150.83 che
è un
indirizzo pubblico che il maintener (il gestore di servizi di hosting
ed
housing di siti web) ha acquistato da IANA. Quando noi utenti di
Internet
vogliamo visitare un sito web contenuto nel Web Server in questione
avremo dai
DNS Servers l’indirizzo IP 85.200.150.83. La domanda lecita
è: se io voglio
interrogare www.cirocarbone.it ed
ottengo l’IP di destinazione 85.200.150.83 come riesce il Web
Server a capire
che il mio interesse è verso questo specifico sito e non verso
gli altri due?
Infatti, anche se volessi interrogare www.mercatino.net, riceverò lo stesso indirizzo IP
85.200.150.83, poiché questo secondo
sito è sullo stesso Web Server.
Come
avviene, allora, questa discriminazione?
La
risposta è: la discriminazione di differenti servizi web di uno
stesso Web
Server avviene grazie ad un software chiamato Virtual Host.
Ciascuna
richiesta, proveniente dall’esterno, dovrà passare prima
per l’analisi del
Virtual Host che discriminerà con precisione a quale servizio,
ovvero a quale
quota, del Web Server la richiesta vuole indirizzarsi. Il meccanismo di
discriminazione avviene tramite la lettura di alcuni header, ovvero di
alcuni
campi di livello 5 in cui i programmi applicativi, che noi utenti
utilizziamo
su Internet, scrivono/leggono per notificare informazioni dettagliate
che vanno
ben aldilà del semplice indirizzo IP di livello 3. Ad esempio
nel caso della
navigazione web, i nostri browser scrivono negli header HTTP 1.1 il
nome
dell’host che vogliamo visitare (il cosiddetto URI Uniform
Resource
Identifier), il tipo di browser, la risoluzione dello schermo ecc.. Il
Virtual
Host legge l’URI nell’ header HTTP 1.1 e, quindi, legge il
nome del sito web
che vogliamo visitare.
La
funzione di Virtual Host è praticamente analoga a quella Virtual
Server e
consente di condividere più quote su un’unica macchina Web
Server con un solo
indirizzo IP. Anche ciò si traduce in un risparmio di indirizzi
IP da
richiedere a IANA. La differenza tra Virtual Host e Virtual Server
consiste
nell’utilizzo del primo su dispositivi ad uso server e con
elementi
discriminanti di livello 5, del secondo su dispositivi ad uso client
con
elementi discriminanti di livello 4??? Ed in particolare le porte.
- IPv6
In
effetti la migrazione verso un sistema differente da ipv4
avverrà comunque
poiché con la diffusione dei servizi internet della telefonia
mobile,
l’esigenza di disporre di molti più indirizzi IP,
porterà all’esaurimento degli
indirizzi potenzialmente disponibili nello standard ipv4.