[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

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