[Articolo] Il DNS: come funziona la risoluzione dei nomi

Oggi vediamo cosa succede quando sulla barra del browser scriviamo il nome di un sito, come ad esempio http://www.google.it, e quale arcano procedimento ci permette di collegarci realmente al sito desiderato.

Difficoltà articolo (0->10): 4

Oggi vediamo cosa succede quando sulla barra del browser scriviamo il nome di un sito, come ad esempio http://www.google.it, e quale arcano procedimento ci permette di collegarci realmente al sito desiderato.

google.it
Apertura di http://www.google.it da browser.

Alla base di tutto il processo si trova il protocollo DNS, il cui acronimo è Domain Name System, che è il sistema che si occupa di tradurre il nome completo di una risorsa di rete (URL) nel relativo indirizzo IP, in modo univoco. Dunque, questo protocollo ricopre un ruolo fondamentale per Internet e più in generale per una buona parte dei servizi di rete.

Ricordiamo che ogni dispositivo o risorsa collegata ad una rete (laptop, smartphone, sito web, server, …) deve possedere un indirizzo numerico chiamato indirizzo IP, nella forma x.x.x.x e che identifica in modo univoco quel dispositivo, un po’ come i numeri telefonici sono associati in modo univoco ad un telefono (non possono esistere 2 cellulari con lo stesso numero!).

Prendiamo un esempio di navigazione su Internet: vogliamo aprire nel browser la pagina di Google (www.google.it), ma cosa succede realmente? Il nostro sistema operativo manderà una richiesta al server DNS: “Ehi, devo andare su http://www.google.it e non conosco il suo indirizzo IP, qual’è?”. Il server DNS ci risponderà: “L’indirizzo IP di http://www.google.it è 173.194.35.23, puoi usare questo!”. Dunque, il nostro sistema operativo userà questo indirizzo IP per contattare il sito (il server web che gestisce il sito) e richiedere la pagina desiderata.

dns-richiesta-google
Risoluzione http://www.google.it in indirizzo IP.

Molto famosi sono i server DNS di Google i quali hanno indirizzi che possono essere facilmente memorizzabili, e che sono liberamente utilizzabili da ciascuno di noi:

  • IP del DNS primario: 8.8.8.8
  • IP del DNS secondario 8.8.4.4

Nulla vieta di usare altri server DNS che non siano quelli di Google. Per le linee Internet casalinghe, tipicamente viene usato un server DNS del proprio fornitore di connettività, che ci viene assegnato automaticamente dal fornitore:

Config DNS ADSL
Parametri di rete forniti in automatico da un fornitore italiano di rete.

E’ chiaramente comprensibile che il DNS sia un sistema fondamentale per il corretto funzionamento di Internet, senza il quale ci risulterebbe molto più difficoltosa la navigazione e l’utilizzo di moltissimi sistemi. Pensate per esempio a dover ricordare anche solamente alcuni dei vostri siti preferiti tramite indirizzo IP in questo modo:

Tutto bello, ma ora se vogliamo trovare l’indirizzo IP associato ad un nome, come posso fare? Qual’è il procedimento inverso? Semplice, ci sono vari strumenti di sistema che possono aiutarci in questo, tra cui:

  • ping
  • nslookup
  • dig (su Linux)
ping www.facebook.it
ping su Windows.
nslookup www.facebook.it
nslookup su Windows.

Adesso che abbiamo visto cos’è e come funziona il DNS, andiamo un po’ più nel dettaglio per i curiosi ;-)…

Abbiamo detto finora che il server DNS esaudisce ogni nostra richiesta traducendo un nome in indirizzo IP, questo è vero, ma non del tutto. Quando facciamo una richiesta, il primo ad essere contattato non è il server DNS, ma un file specifico all’interno del proprio sistema operativo, qualunque sia il sistema, Windows, MacOS, o Linux. Il file in questione si chiama file hosts, su Windows si trova  di default all’interno della cartella di sistema “C:\Windows\System32\drivers\etc\” mentre su Linux in “/etc/“. Pertanto, quando vogliamo aprire una determinata pagina web, prima viene controllato questo file, per vedere se l’URL è contenuto al suo interno e:

  • se il file hosts contiene la corrispondenza URL -> IP, allora viene usato questo indirizzo IP per aprire la pagina desiderata.
  • se il file hosts non contiene l’URL, allora viene contattato il server DNS a cui viene chiesto di risolvere l’URL in indirizzo IP.

Vediamo com’è fatto il file hosts, e ricordiamo che possiamo divertirci inserendo al suo interno tutto ciò che vogliamo, se abbiamo necessità particolari.

Windows file hosts
File hosts su Windows.

Il file hosts ha una sua formattazione, come spiegato all’inizio del file una volta aperto, e viene dunque consultato prima di inoltrare la

Dobbiamo sapere inoltre che l’associazione di un nome con un indirizzo IP può non essere singola, ma un nome potrebbe avere associati più indirizzi IP. Come mai? Cosa succede allora? Questo avviene in genere per siti importanti, relativi ad enti o grandi realtà, quando dietro di essi ci sono non un pc o comunque una solo server, ma spesso molti sistemi/server differenti che hanno la funzionalità di:

  • bilanciatori di carico
  • ridondanza

Immaginate se dietro http://www.google.it ci fosse un solo server a rispondere alle richieste di milioni di persone che si collegano. Cosa succederebbe se dovesse avere un problema o un blocco? Saremmo tutti fermi non potendo più aprire la pagina di Google! Ad esempio al sito di Ducati corrispondono 2 indirizzi IP principali:

nslookup www.ducati.it
IP multipli associati ad un sito.

Con questo articolo abbiamo visto solo la punta dell’iceberg del protocollo DNS e del suo funzionamento, ma per approfondimenti ecco alcuni link:

roghan

[Articolo] L’indirizzo IP e la Rete

Ho deciso di scrivere un post che cercherà di spiegare cos’è un indirizzo IP e quale visibilità ha un dispositivo collegato a Internet rispettivamente dietro ad un modem, un router, e un firewall.

Difficoltà articolo (0->10): 3

Requisiti: nessuno in particolare.

Ho deciso di scrivere un post che cercherà di spiegare cos’è un indirizzo IP e quale visibilità ha un computer su Internet, dopo che molte volte mi sono state rivolte domande a riguardo. Buona lettura ;-).

Ogni dispositivo collegato ad Internet (computer, palmare, cellulare, …), e più in generale a qualsiasi rete, è dotato di un proprio indirizzo che lo identifica in modo univoco. Possiamo pensare ai cellulari: ogni cellulare ha un proprio numero univoco, e quindi diverso da tutti gli altri (anche se in realtà il numero viene assegnato alla scheda sim, ma questo è un altro argomento), e questo numero ha una struttura fissa composta da 10 numeri. E’ naturale pensare che non possano esistere due cellulari diversi con lo stesso numero X, altrimenti se entrambi fossero accesi e qualcuno volesse chiamare proprio il numero X cosa succederebbe? La rete telefonica non saprebbe a quale dei due cellulari inoltrare la telefonata! Quello che succede per i cellulari può essere paragonato ai computer e a Internet. Ogni computer, al momento che si collega ad una qualunque rete (sia su Internet che all’interno di una rete locale (LAN)), deve possedere un proprio indirizzo IP, assegnato dal suo Internet Service Provider – ISP (Alice, Tele2, Tiscali, …) ed avente la forma X.X.X.X, dove ogni X può essere un qualsiasi numero da 0 a 255 (con alcune eccezioni). Esempi di indirizzi IP sono 192.168.3.45, oppure 155.123.111.13, ma anche 2.3.4.5 è un indirizzo valido.

indirizzo_ip

Per conoscere il proprio indirizzo è possibile utilizzare un comando specifico da terminale. In caso di windows è necessario aprire il prompt dei comandi e digitare:

ipconfig

e tra i dati visualizzati si potrà vedere proprio l’indirizzo IP. Ovviamente facciamo attenzione a controllare la scheda giusta, se abbiamo più schede di rete all’interno del computer, e solitamente la scheda di rete è identificata come “Ethernet Adapter”, “LAN Adapter”, “Ethernet Wireless Adapter” nel caso di una scheda wireless, ecc. Ecco un esempio (l’indirizzo IP è 192.168.1.2, assegnato appunto alla scheda “Ethernet Adapter”):

ipconfig
ipconfig su Windows

Da notare che aggiungendo l’opzione /all al comando verranno visualizzate tutte le informazioni relative alla rete (server DNS, gateway, …).

Nel caso di Linux invece il comando da digitare all’interno della shell è:

# ifconfig

(per maggiori dettagli vedere l’articolo rete in Linux).

A questo punto, possiamo provare a controllare l’IP visibile da Internet attraverso uno dei tanti siti che si trovano in giro sul web, ad esempio www.ip-adress.com. L’indirizzo visibile sul sito non corrisponde a quello della macchina? Potrebbe essere così, perché c’è il trucco :-). Come ho scritto su, è vero che ogni computer collegato ad Internet riceve un indirizzo univoco, ma solo se questo è collegato direttamente alla Rete. Molto spesso invece un computer si trova dietro ad un router, come nei sistemi casalinghi, o addirittura all’interno di una LAN più o meno complessa e comunque sempre dietro ad un router e/o firewall, come nei sistemi aziendali dove i pc sono molti. Dunque, esistono due tipi di indirizzi IP: pubblici e privati. La figura mostra un esempio tipico di connessione, dove i singoli computer (PC1, PC2, PC2) sono collegati ad Internet attraverso un router. E’ possibile osservare che ogni computer ha assegnato un indirizzo IP privato, e poi tutti sono collegati allo stesso router (passando per un hub/switch) che funge da punto di contatto tra i pc e Internet. A questo punto è naturale pensare che al router venga assegnato un indirizzo IP pubblico, essendo l’unico punto visibile sulla Rete “esterna”.

topologia_rete
Topologia di una rete

Più in generale, ogni computer o dispositivo collegato direttamente ad Internet (come utilizzando un modem, e non un router!) avrà un indirizzo pubblico, altrimenti se è posto dietro ad un router/firewall avrà un IP privato, ossia visibile solo nella rete locale. I motivi per cui viene assegnato un IP diverso ai computer che si trovano dietro ad un router sono molteplici:

  • utilizzando un router è possibile collegare ad Internet un elevato numero di computer o in più in generale dispositivi, altrimenti per ognuno servirebbe un modem diverso. Inoltre il numero di dispositivi collegati ad Internet sta aumentando sempre più, e poiché il numero totale dei possibili indirizzi IP è limitato (ricordiamo la struttura X.X.X.X, con numero massimo 255 per ogni X), un po’ come le targhe delle macchine, ai computer dietro ad un router vengono assegnati degli indirizzi privati, ossia non visibili da Internet. Ciò significa che due computer diversi, che si trovano dietro a router diversi, possono avere lo stesso indirizzo IP privato;
  • i computer collegati ad Internet attraverso un router risultano anche più protetti, in quanto solo il router risulterà visibile sul web, ma non i computer dietro ad esso e con gli indirizzi privati.

Un’altra precisazione, per chi non sapesse la differenza tra modem e router… Il modem (contrazione di modulator-demodulator) è un dispositivo che traduce i dati inviati da un solo computer in modo tale da trasmetterli sulla Rete, quindi un dispositivo un po’ stupido che esegue solamente questo compito. Quindi se avessimo 10 computer da collegare ad Internet avremmo bisogno di 10 modem. Un router invece è una sorta di “mini-computer”, che non solamente trasmette i dati a/da Internet, ma che ha in genere molte altre funzionalità, tipo quella di firewall (per la protezione dalle intrusioni esterne), di access point (per la creazione di una rete wireless), e la possibilità di collegare ad esso più computer. Quindi con un router è possibile collegare ad Internet un numero elevatissimo di dispositivi, ovviamente in base al tipo e qualità del router. Ci possono essere router casalinghi, da poche decine di euro (TP-Link, Netgear, …), o router professionali dal costo di migliaia di euro (Cisco, Juniper, …). Per maggiori approfondimenti (oltre alla consueta wikipedia):

roghan

[Articolo] Il comando netstat in Windows: come interpretare le connessioni

Analizziamo oggi il comando netstat, uno dei principali comandi per fare troubleshooting delle reti in ambiente Windows e per controllare quali connessioni sono stabilite.

Vediamo i 5 casi di utilizzo più importanti e da tenere sott’occhio. […]

Difficoltà articolo (0->10): 6

Analizziamo oggi il comando netstat, uno dei principali comandi per fare troubleshooting delle reti in ambiente Windows e per controllare quali connessioni sono stabilite.

Vediamo i 5 casi di utilizzo più importanti e da tenere sott’occhio.

1 – Lista connessioni e porte in ascolto: netstat -an

Questo è il caso più semplice di utilizzo del comando che elenca tutte le connessioni comprese quelle attive (stato ESTABLISHED), e quelle con una porta in ascolto (stato LISTENING). L’opzione n non è essenziale, ma è secondo me utile perché effettua un DNS lookup andando a mostrare indirizzo IP al posto di ogni hostname. I possibili stati in cui una connessione può trovarsi sono quelli mostrati nella tabella seguente.

Stato Descrizione
CLOSED Indica che il server ha ricevuto dal client un messaggio ACK e la connessione è chiusa.
CLOSE_WAIT Indica che il server ha ricevuto dal client il primo FIN e la connessione è in fase di chiusura.
ESTABLISHED Indica che il server ha ricevuto dal client un SYN e la sessione è stata stabilita.
FIN_WAIT_1 Indica che la connessione è ancora attiva ma al momento non è usata e verrà chiusa.
FIN_WAIT_2 Indica che il client ha ricevuto l’ACK del server, dopo che il server ha ricevuto il primo FIN dal client.
LAST_ACK Indica che il server sta per inviare il proprio messaggio FYN.
LISTENING Indica che il server è in ascolto e pronto ad accettare una nuova connessione.
SYN_RECEIVED Indica che il server ha ricevuto il SYN inviato dal client.
SYN_SEND Indica che la connessione è attiva.
TIME_WAIT Indica che la connessione è in fase di chiusura, ma è ancora attiva.
screen_netstat1
netstat -an

Tutti zero nella colonna “Foreign” significa che ancora non ci sono indirizzi remoti, e pertanto la linea rappresenta un servizio in ascolto. Nel momento in cui un servizio riceve una connessione in ingresso, allora verrà stabilita una nuova connessione e dunque verrà mostrata una linea specifica all’interno della lista di connessioni.

Su questo sito si trova un’ottima spiegazione degli stadi e delle transizioni nel protocollo TCP, e il diagramma mostrato è veramente ben fatto:

TCP-StateTransitionDiagram-NormalTransitions

2 – Fully qualified domain name: netstat -f

Con questo parametro il comando mostra il nome intero (FQDN) di ogni indirizzo IP, risolvendolo internamente o se possibile esternamente.

netstat -f
netstat -f

3 – Tabella di routing: netstat -r

L’opzione permette di mostrare la tabella di routing del sistema, ed è l’analogo del comando route print.

netstat -r
netstat -r

4 – Processo per ogni porta: netstat -aon oppure nestat -b

In questo modo per ogni porta aperta nel sistema vengono elencati lo stato e l’identificativo del processo (PID) che ha aperto la porta. L’opzione b è migliore perché mostra direttamente l’eseguibile del processo in esecuzione ma richiede i permessi di amministratore per poter essere eseguita.

netstat -aon
netstat -aon

5 – Statistiche di rete: netstat -s -p IP

Mostra le statistiche di rete relative al livello 3, ossia IP. E’ possibile in questo modo vedere eventuali errori o problemi di connessione.

netstat -s -p IP
netstat -s -p IP

Sono utili anche la possibilità di mantenere la lista aggiornata ad un certo intervallo (ad esempio ogni 5 secondi):

nestat -an 5

e quella di salvare l’output del comando in un file:

netstat -an >> C:\connections_list.txt

roghan

Privilegi root per bind di porte 1-1023 in Java

Se dobbiamo creare un server in Java per accettare comunicazioni su TCP, è necessario usare la classe ServerSocket, mentre quella Socket è specifica per il lato client. Durante la creazione della componente client, bisogna fare particolare attenzione a quali porte indichiamo se ci troviamo su sistemi Linux/Unix. […]

Se dobbiamo creare un server in Java per accettare comunicazioni su TCP, è necessario usare la classe ServerSocket, mentre quella Socket è specifica per il lato client. Durante la creazione della componente client, bisogna fare particolare attenzione a quali porte indichiamo se ci troviamo su sistemi Linux/Unix. Ad esempio, il codice per mettere in ascolto un server sulla porta 80 è il seguente:

try
{
     ServerSocket server= new ServerSocket(80);
}catch (IOException iex)
{
     System.err.println(ex);
}

Il codice è corretto, ma potrebbe essere sollevata un’eccezione su sistemi Unix/Linux o anche Windows, in quanto sono necessari i privilegi di root/administrator per poter usare le porte nel range 1-1023.

roghan

Come risolvere i problemi di connessione – parte 1

Spesso capita che la rete non funzioni, e ci chiediamo quale e dove possa essere il problema. E’ il nostro sistema che non va? E’ il server che non risponde? E’ la trasmissione che non funziona? Insomma ci sono sempre tante domande e non sempre è immediato trovare la risposta, e finiamo per cambiare parametri e impostazioni nel tentativo di ripristinare la connessione! Gli utenti più inesperti poi finisco per installare svariati tipi di software che promettono di ripristinare la connessione e di sistemare tutto, come questo Connectivity fixer. Non ci sono programmi più inutili e magari dannosi (chi ha detto spyware?! Io no ;-)…). […]

Spesso capita che la rete non funzioni, e ci chiediamo quale e dove possa essere il problema. E’ il nostro sistema che non va? E’ il server che non risponde? E’ la trasmissione che non funziona? Insomma ci sono sempre tante domande e non sempre è immediato trovare la risposta, e finiamo per cambiare parametri e impostazioni nel tentativo di ripristinare la connessione! Gli utenti più inesperti poi finisco per installare svariati tipi di software che promettono di ripristinare la connessione e di sistemare tutto, come questo Connectivity fixer. Non ci sono programmi più inutili e magari dannosi (chi ha detto spyware?! Io no ;-)…).

Questo post rappresenta invece la prima parte di un altro post che avevo scritto qualche tempo fa, in cui spiegavo come fare troubleshooting della rete e verificare il collegamento ad Internet. In questo articolo invece esaminiamo il problema partendo dalla connessione alla rete locale, e senza far uso di risoluzioni DNS.

 

Prendiamo come esempio l’architettura di rete visibile in figura, e supponiamo di essere il sistema Bob con indirizzo IP 172.17.10.3 e di voler contattare la macchina Server con indirizzo 172.17.30.2. Nell’immagine non ho specificato le subnet per semplificare il tutto e renderlo fruibile anche a chi può avere meno conoscenze informatiche, comunque possiamo assumere che la subnet sia /24, uguale per ogni indirizzo.

diagramma_rete
Diagramma di rete

Come è visibile dal grafico si tratta di una piccola rete, tuttavia il problema può facilmente essere esteso ad una rete molto più grande come anche ad Internet (semplicemente non ci sarà un solo router tra sorgente e destinazione ma una serie di N dispositivi, come backbone, …). Vediamo i passi da fare per controllare il funzionamento della rete dal punto di vista di Bob:

  1. Test del loopback. Apriamo un terminale (prompt cmd in Windows, shell in Linux e MacOS) e facciamo ping verso 127.0.0.1.
    $ ping 127.0.0.1
    PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.773 ms
    64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.125 ms
    64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.080 ms
    64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.083 ms
    --- 127.0.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.080/0.265/0.773/0.293 ms

    Questo è l’indirizzo di loopback e se il risultato è positivo significa che lo stack TCP/IP è stato inizializzato correttamente. In caso invece di fallimento il servizio che gestisce lo stack TCP/IP deve essere ripristinato all’interno del sistema operativo. Per effettuare il ripristino dello stack in Windows è possibile consultare questo link, mentre per Linux quest’altro.

  2. Test della scheda di rete. Adesso facciamo ping verso l’indirizzo IP del sistema locale, nell’esempio 172.17.10.3.
    $ ping 172.17.10.3
    PING 172.17.10.3 (172.17.10.3) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.111 ms
    64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.079 ms
    64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.080 ms
    64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.078 ms
    --- 127.0.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.078/0.087/0.111/0.013 ms

    Se con il ping vengono ricevute le risposte significa che la NIC funziona correttamente così come i driver/moduli di sistema, ma ciò non indica che la rete è esente da problemi quali cavi rotti o collegamenti interrotti. Un esito invece negativo potrebbe essere indice di scheda di rete guasta o di driver/moduli non installati correttamente. Provate a riavviare il sistema e, su Windows, a reinstallare i driver, mentre su Linux ad aggiornare il kernel e riavviare moduli e servizi secondo le istruzioni a questo link.

  3. Test del gateway. Ora è in turno del gateway/router. Effettuate il ping verso il default gateway per testare la comunicazione nella rete locale, nell’esempio 172.17.10.1.
    $ ping 172.17.10.1
    PING 172.17.10.1 (172.17.10.1) 56(84) bytes of data.
    64 bytes from 192.168.139.2: icmp_req=1 ttl=128 time=0.255 ms
    64 bytes from 192.168.139.2: icmp_req=2 ttl=128 time=0.237 ms
    64 bytes from 192.168.139.2: icmp_req=3 ttl=128 time=0.241 ms
    64 bytes from 192.168.139.2: icmp_req=4 ttl=128 time=0.219 ms
    --- 192.168.139.2 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3004ms
    rtt min/avg/max/mdev = 0.219/0.238/0.255/0.012 ms

    Un esito negativo significa che c’è un problema o nella trasmissione dei dati (cavo rotto/scollegato), o nel default gateway che non è in grado di elaborare le richieste, oppure un blocco delle richieste da parte di un firewall o altro dispositivo interconnesso tra Bob e il default gateway (switch, hub, AP, …).

  4. Test del server remoto. Infine, se tutti i 3 punti precedenti hanno avuto esito positivo, testiamo la connessione verso il server remoto, nel nostro esempio  172.17.30.2.
    $ ping 172.17.30.2
    PING 172.17.30.2 (172.17.30.2) 56(84) bytes of data.
    64 bytes from 172.20.0.1: icmp_req=1 ttl=128 time=1.46 ms
    64 bytes from 172.20.0.1: icmp_req=2 ttl=128 time=0.913 ms
    64 bytes from 172.20.0.1: icmp_req=3 ttl=128 time=2.40 ms
    64 bytes from 172.20.0.1: icmp_req=4 ttl=128 time=0.714 ms
    --- 172.20.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3005ms
    rtt min/avg/max/mdev = 0.714/1.375/2.407/0.657 ms

    Se l’esito è negativo significa che il problema è da ricercarsi nella rete remota. Inoltre, nel caso in cui sia possibile raggiungere la rete remota con il ping, sarebbe ideale poter replicare i test partendo dal server remoto verso il sistema sorgente.

Nel caso di connessione a Internet (e non locale) anche se tutti e 4 i punti hanno avuto esito positivo la comunicazione potrebbe non funzionare. In questo caso il problema potrebbe essere il servizio DNS, e rimando alla seconda parte dell’articolo.

roghan

[Articolo] Vantaggi di uno switch layer 2/3

In questo articolo vedremo le differenze che c’è tra uno switch che supporta solo il livello 2 e uno che supporta anche le funzionalità del livello 3, e soprattutto in quali circostanze è consigliato usare l’uno e in quali l’altro.

Difficoltà articolo (0->10): 4

In questo articolo vedremo le differenze che c’è tra uno switch che supporta solo il livello 2 e uno che supporta anche le funzionalità del livello 3, e soprattutto in quali circostanze è consigliato usare l’uno e in quali l’altro.

Prima di addentrarci nell’argomento è bene ricordare brevemente cosa sono le VLAN. Il termine VLAN è acronimo di Virtual Local Area Network, ed indica una rete locale di dispositivi raggruppati in modo logico, ossia senza alcun legame specifico con la posizione fisica. Ad esempio possono appartenere ad una stessa VLAN dispositivi connessi a switch differenti. Inoltre le VLAN operano a livello 2, mentre con le LAN si opera a livello 3.

Nel momento in cui viene fatto il design di un ambiente con VLAN, è opportuno che i dispositivi di una stessa VLAN facciano parte anche della stessa subnet. Questo però non significa che una VLAN è una subnet, e che una subnet è una VLAN! Infatti come ho detto prima, le VLAN sono un concetto relativo al livello 2, mentre le subnet al livello 3 ossia a quello IP. E’ abbastanza ragionevole il fatto che gli stessi device all’interno di una VLAN debbano appartenere anche alla stessa subnet affinché possano comunicare tra di loro.

Studiamo adesso la seguente figura, e supponiamo che un computer della VLAN 10 voglia comunicare con uno della VLAN 20. E’ da notare che i computer delle VLAN si trovano correttamente anche su subnet diverse.

VLAN

Il pc nella VLAN 10, prima di inviare il pacchetto controlla se il destinatario è nella stessa subnet oppure no, e poiché si trova su una differente, il pacchetto deve essere inviato al default router. In pratica il pacchetto viene inviato allo switch, e poi inoltrato al router. A sua volta il router analizza il pacchetto controllando il destinatario, ricostruisce il pacchetto e lo invia indietro allo switch fino al destinatario della VLAN 20.

Come è facile immaginare, quando i pacchetti inviati sono tanti questo processo è oneroso sia in termini di banda utilizzata sia in termini di latenza. E’ qui che entrano in gioco gli switch di livello 3, o meglio di livello 2 e 3, chiamati anche switch multilivello. Questi sono difatti in grado di operare scelte di routing, supportando svariati tipi di protocolli (RIP, OSPF, BGP, …). In una rete con switch di questo tipo infatti i pacchetti non vengono inviati al router per decidere l’instradamento, ma è lo switch stesso ad avere la logica decisionale e a sapere dove inviare i messaggi. Nel mondo Enterprise ormai quasi ogni switch supporta praticamente anche il livello 3, o quantomeno ha le funzionalità al suo interno, a volte utilizzabili dopo aver acquistato la relativa licenza.

L’utilizzo degli switch di vecchio stampo che supportano solo il livello 2 è pertanto relegato ad ambienti piccoli/casalinghi, dove non si hanno necessità particolari e dove i dispositivi interconnessi sono pochi. In questo caso solitamente non si ha bisogno neppure di particolari performance, e l’aumento della latenza o una minimale perdita di banda non costituiscono grandi problemi, diversamente da ambienti critici e di fascia medio/alta.

Dunque riepilogando ecco i pro e i contro per l’utilizzo di switch di livello 2 o 2/3:

switch di “solo” livello 2:

  • pro:
    • prezzo competitivo
    • configurazione minimale
  • contro:
    • calo prestazionale al crescere della dimensione della rete
    • sicurezza minore avendo una rete piatta con tutti i dispositivi tra loro interconnessi

switch di livello 2/3:

  • pro:
    • prestazione maggiori con una suddivisione e configurazione accorta della rete (VLAN, subnet, …)
    • maggiore sicurezza di tutta la rete
  • contro:
    • è richiesta una maggiore conoscenza delle reti e più tempo per la configurazione di tutto
    • costo degli apparati maggiore

roghan

Reti locali e scelta degli indirizzi IP

L’idea di questo articolo nasce da una discussione iniziata su un noto forum del web. In particolare vedremo in che modo devono essere scelti gli indirizzi IP all’interno di una LAN e il perché di questa scelta. Tipicamente all’interno di una rete locale vengono impiegati quegli indirizzi che sono chiamati “privati”, appartenenti ad una delle 3 categorie […]

L’idea di questo articolo nasce da una discussione iniziata su un noto forum del web. In particolare vedremo in che modo devono essere scelti gli indirizzi IP all’interno di una LAN e il perché di questa scelta. Tipicamente all’interno di una rete locale vengono impiegati quegli indirizzi che sono chiamati “privati”, appartenenti ad una delle 3 categorie:

  • 10.0.0.0-10.255.255.255
  • 172.16.0.0-172.31.255.255
  • 192.168.0.0-192.168.255.255

Per una descrizione sul funzionamento degli indirizzi IP e sulla differenza tra indirizzi pubblici e privati leggete quest’altro articolo.

lan

Tutti noi che abbiamo in casa un router ADSL, sia wireless che con connessione via cavo, facciamo inconsapevolmente uso degli indirizzi IP privati. Infatti spesso i router assegnano ai dispositivi connessi gli indirizzi compresi tra 192.168.1.0 e 192.168.1.255 (estremi esclusi), mentre per la connessione di management del router viene utilizzato il canonico 192.169.1.1. Ovviamente non tutti i router utilizzano esattamente questo range, infatti potrebbe essere invece utilizzato 192.168.0.0-192.168.0.255, o altri ancora comunque sempre facenti parte delle 3 categorie di indirizzi privati. Vediamone adesso il motivo.

Quali implicazioni ci sarebbero ad usare un range differente da quello degli  indirizzi privati? Ad esempio cosa succede se in una LAN vengono assegnati ai PC gli indirizzi nel range 17.18.1.0-17.18.1.255? Se la LAN non è connessa ad Internet teoricamente tutto potrebbe funzionare tranquillamente, in quanto il dialogo tra i dispositivi della LAN avverrebbe come con qualunque altro indirizzo IP (privato o non). Il problema nasce al momento che  la LAN viene connessa ad Internet. Riprendendo il nostro esempio, se la LAN con indirizzi nel range 17.18.1.0-17.18.1.255 accedesse ad Internet, non sarebbe in grado di collegarsi ai dispositivi sul web che hanno veramente quegli indirizzi. Supponiamo che un PC della LAN, con indirizzo 17.18.1.10 voglia accedere ad un server su Internet con IP 17.18.1.200: a livello di routing, il PC che effettua la richiesta crederà di essere già all’interno della subnet del server, quindi tutte le richieste rimarranno nella rete locale senza essere inviate su Internet dal router.

Conclusione: dovendo assegnare indirizzi IP ad una rete locale è bene usare solamente gli indirizzi IP privati, in modo da non complicarsi la vita, anche se teoricamente in una LAN scollegata da Internet potrebbero essere usati anche indirizzi appartenenti ad altri range diversi da quelli privati. Più in generale, quest’ultimo caso lo consiglio solo per ambienti di test, e quando si vogliono fare esperimenti con le reti ;-), ma non per un uso prolungato.

roghan

Configurare la rete

Sotto Linux, i due comandi principali che permettono di controllare e configurare i parametri di rete sono due: ifconfig e route. Altri due comandi utili, che però non verranno trattati in questo howto, sono iwconfig, per la gestione specifica delle schede di rete wireless, e il comando ip, che è una sorta di comando universale con funzionalità simile a ifconfig e route. Vediamo in dettaglio cosa permettono di fare ifconfig e route.
Il comando ifconfig serve sia per ottenere informazioni sulle configurazioni delle schede di rete, sia per configare le schede stesse. Per visualizzare le configurazioni è necessario digitandorlo da solo senza alcun parametro. […]

Sotto Linux, i due comandi principali che permettono di controllare e configurare i parametri di rete sono due: ifconfig e route. Altri due comandi utili, che però non verranno trattati in questo howto, sono iwconfig, per la gestione specifica delle schede di rete wireless, e il comando ip, che è una sorta di comando universale con funzionalità simili a ifconfig e route. Vediamo in dettaglio cosa permettono di fare ifconfig e route.

Il comando ifconfig serve sia per ottenere informazioni sulle configurazioni delle schede di rete, sia per configare le schede stesse. Per visualizzare le configurazioni è necessario digitandorlo da solo senza alcun parametro. Un esempio di output è il seguente

# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1B:24:27:59:84
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Memory:da000000-da020000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:41 errors:0 dropped:0 overruns:0 frame:0
TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4740 (4.6 KiB) TX bytes:4740 (4.6 KiB)
wlan1 Link encap:Ethernet HWaddr 00:1B:77:22:CD:2D
inet addr:172.20.100.77 Bcast:172.20.100.255 Mask:255.255.255.0
inet6 addr: fe80::21b:77ff:fe22:cd2d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2805 errors:0 dropped:0 overruns:0 frame:0
TX packets:2720 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1993718 (1.9 MiB) TX bytes:477093 (465.9 KiB)

Come è visibile nell’esempio precedente, solitamente le interfacce mostrate da ifconfig sono le seguenti:

  • eth0, eth1, … sono le schede di rete presenti sulla macchina;
  • wlan1, … sono le interfacce wireless;
  • lo è l’interfaccia logica, denominata anche di loopback, e a cui è assegnato l’indirizzo IP 127.0.0.1. Questa interfaccia indica la macchina stessa e deve essere sempre attiva, anche se il sistema non è collegato ad alcuna rete.

Nel caso in cui si voglia usare ifconfig per la configurazione di una scheda di rete, è necessario prima disattivare la scheda che si vuole andare a modificare, e solo dopo inserire i nuovi parametri. La sintassi è la seguente:

# ifconfig <interfaccia> <indirizzo_ip> down
# ifconfig <interfaccia> <indirizzo_ip> netmask <subnet_mask> broadcast <indirizzo_broadcast>

Il comando route invece serve per gestire l’instradamento dei dati, sia per visualizzare le impostazioni correnti del sistema, sia per definirne di nuove. Senza alcun parametro, o con il parametro n (per avere in output dei valori numerici), mostra le tabelle di instradamento attuali. Ecco un esempio:

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.20.100.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan1
0.0.0.0 172.20.100.254 0.0.0.0 UG 0 0 0 wlan1

Importante, nonché utile, è l’opzione con cui si può definire un nuovo default gateway (per tutti gli indirizzi):

# route add default gw <indirizzo_ip>

Di seguito viene mostrato un semplice esempio. Supponiamo di voler configurare la scheda di rete eth0 con l’indirizzo IP 192.168.1.4, maschera di rete 255.255.255.0, e gateway 192.168.1.1. I comandi da digitare sono i seguenti:

# ifconfig eth0 down
# ifconfig eth0 192.168.1.4 netmask 255.255.255.0 broadcast 192.168.1.255
# ifconfig eth0 up
# route add default gw 192.168.1.1

Con pochi e semplici comandi è possibile configurare una qualsiasi scheda di rete. Dopo aver apportato delle modifiche è buona norma riavviare il servizio che si occupa delle rete, anche se non è sempre necessario. Ecco come fare sulle distro Red Hat-like:

# service network restart

e sulle distro Debian-like:

# /etc/init.d/networking restart

Link di approfondimento:

http://www.coresis.com/extra/linuxcorsobase/12-1.htm

http://www.firenze.linux.it/~piccardi/corso/netadmin/node12.html

roghan