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.

 

Casella di testo: Pin	Assignment
1	Transmit + (TX+)
2	Transmit - (TX-)
3	Receive + (RX+)
4	Reserved
5	Reserved
6	Receive - (RX-)
7	Reserved
8	Reserved

 

 

 

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.

 

 

 

 

 

 

  1. 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   

Query: IT. Query type: Any record
Recursive query: Yes Authoritative answer: No
Query time: 46 ms. Server name: dnsti.interbusiness.it

Answer:

Authority:
. 3600000 NS j.root-servers.net.
. 3600000 NS k.root-servers.net.
. 3600000 NS l.root-servers.net.
. 3600000 NS m.root-servers.net.
. 3600000 NS a.root-servers.net.
. 3600000 NS b.root-servers.net.
. 3600000 NS c.root-servers.net.
. 3600000 NS d.root-servers.net.
. 3600000 NS e.root-servers.net.
. 3600000 NS f.root-servers.net.
. 3600000 NS g.root-servers.net.
. 3600000 NS h.root-servers.net.
. 3600000 NS i.root-servers.net.

Additional:
a.root-servers.net. 13284 A 198.41.0.4
b.root-servers.net. 13284 A 192.228.79.201
c.root-servers.net. 13284 A 192.33.4.12
d.root-servers.net. 13284 A 128.8.10.90
e.root-servers.net. 13284 A 192.203.230.10
f.root-servers.net. 13284 A 192.5.5.241
g.root-servers.net. 13284 A 192.112.36.4
h.root-servers.net. 13284 A 128.63.2.53
i.root-servers.net. 13284 A 192.36.148.17
j.root-servers.net. 13284 A 192.58.128.30
k.root-servers.net. 13284 A 193.0.14.129
l.root-servers.net. 13284 A 198.32.64.12
m.root-servers.net. 13284 A 202.12.27.33


       

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   

Query: IT. Query type: Any record
Recursive query: Yes Authoritative answer: No
Query time: 172 ms. Server name: h.root-servers.net

Answer:

Authority:
it. 172800 NS nameserver.cnr.it.
it. 172800 NS dns.nic.it.
it. 172800 NS dns2.it.net.
it. 172800 NS ns.ripe.net.
it. 172800 NS server2.infn.it.
it. 172800 NS dns2.iunet.it.
it. 172800 NS auth2.dns.cogentco.com.
it. 172800 NS it2.mix-it.net.

Additional:
nameserver.cnr.it. 172800 A 194.119.192.34
dns.nic.it.  172800 A 193.205.245.5
dns2.it.net.  
172800 A 151.1.2.1
ns.ripe.net.  172800 A 193.0.0.193
server2.infn.it. 172800 A 131.154.1.3
dns2.iunet.it. 172800 A 192.106.1.31
auth2.dns.cogentco.com. 172800 A 66.28.0.30
it2.mix-it.net. 172800 A 217.29.76.4
   


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   
Query: prozone.it. Query type: Any record
Recursive query: Yes Authoritative answer: No
Query time: 47 ms. Server name: nameserver.cnr.it.

Answer:

Authority:
prozone.it. 86400 NS ns2.th.seeweb.it.
prozone.it. 86400 NS ns1.th.seeweb.it.
 

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   
Query: prozone.it. Query type: Any record
Recursive query: Yes Authoritative answer: Yes
Query time: 2329 ms. Server name: ns1.th.seeweb.it

Answer:
prozone.it. 172800 SOA ns1.th.seeweb.it.
   hostmaster.seeweb.it.
   2004100500; serial
   86400; refresh (1 day)
   7200; retry (2 hours)
   2592000; expire (30 days)
   86400; minimum (1 day)
prozone.it. 172800 NS ns2.th.seeweb.it.
prozone.it. 172800 NS ns1.th.seeweb.it.
prozone.it. 172800 MX 20  smtp-f3.seeweb.it.
prozone.it. 172800 MX 20  smtp-f4.seeweb.it.
prozone.it. 172800 MX 10  m-01b.th.seeweb.it.
prozone.it. 172800 MX 20  smtp-f1.seeweb.it.
prozone.it. 172800 MX 20  smtp-f2.seeweb.it.

Additional:
ns1.th.seeweb.it. 172800 A 217.64.201.170
ns2.th.seeweb.it. 172800 A 217.64.202.202
m-01b.th.seeweb.it. 172800 A 217.64.202.206
 

 

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.

 

 

 

Livello applicazioni

HTTP, HTTPS , SMTP, POP3, IMAP, FTP, DNS, SSH, IRC, SNMP, SIP, RTSP, Rsync, Telnet, HSRP, BitTorrent, ...  

Livello di trasporto

TCP, UDP, SCTP, DCCP, RTP, ICMP,  ... 

Livello di rete

IPv4, IPv6, DHCP, BGP, OSPF,
RIP, IGRP, IGMP,ARP,IPsec...   

Livello di collegamento o linea

Ethernet, WiFi, PPP, Token ring, ATM, FDDI, LLC, SLIP ...     

Livello fisico

Doppino, Fibra ottica, Cavo coassiale,
Codifica Manchester, Codifica 4B/5B, WiFi

 

   

 

 

  1. 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.

 

 

  1. Reti WAN

 

  1. Router

(mettere in evidenza in questo capitolo la connectionless del mondo IP)

 

  1. 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.

 

 

  1. Indirizzi IP, classi e Subnet Mask

 

 

 

 

 

 

  1. 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.

 

 

 

  1. 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.