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

Confronto tra i principali protocolli di routing

Ho messo a confronto in un file excel, e riassunto, le caratteristiche principali dei seguenti protocolli di routing: RIP, RIPv2, IGRP, EIGRP, e OSPF.

Potete scaricare liberamente il file:

download diretto

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

Lavorare nel settore “sicurezza informatica”

Da quando ho finito l’università e mi sono laureato ho iniziato seriamente ad interessarmi al settore della sicurezza in rete, o più in generale della sicurezza informatica. Non che prima non mi interessasse questo ambito, anzi, mi attirava molto il mondo un po’ underground degli hacker, degli worm e dei cavalli di troia, quello visto nei film in cui il ragazzino adolescente riesce in pochi attimi ad entrare in qualche mega computer della CIA. Il problema è che non avevo mai avuto veramente il tempo ma anche la voglia durante tutto il periodo universitario di interessarmi a questo mondo, dato che il carico di studio era davvero moooooooolto elevato! Solo con la tesi finale sono riuscito a scegliere un argomento che mi interessasse davvero (strumenti per l’anonimato in Rete), e da lì ho capito quale sarebbe stato il mio futuro :-D… Finita l’università ho deciso poi di cercare un master/corso che avesse come argomento principale proprio la sicurezza, ma data l’impossibilità di frequentare un master a Roma o Milano (quota dai 6000/7000 euro in su più i soldi necessari per vitto e alloggio!) ho optato per un corso disponibile a Firenze: il Cisco CCNA Security. […]

(in costante aggiornamento)

Da quando ho finito l’università e mi sono laureato ho iniziato seriamente ad interessarmi al settore della sicurezza in rete, o più in generale della sicurezza informatica. Non che prima non mi interessasse questo ambito, anzi, mi attirava molto il mondo un po’ underground degli hacker, degli worm e dei cavalli di troia, quello visto nei film in cui il ragazzino adolescente riesce in pochi attimi ad entrare in qualche mega computer della CIA.

Il problema è che non avevo mai avuto veramente il tempo ma anche la voglia durante tutto il periodo universitario di interessarmi a questo mondo, dato che il carico di studio era davvero moooooooolto elevato! Solo con la tesi finale sono riuscito a scegliere un argomento che mi interessasse davvero (strumenti per l’anonimato in Rete), e da lì ho capito quale sarebbe stato il mio futuro :-D… Finita l’università ho deciso poi di cercare un master/corso che avesse come argomento principale proprio la sicurezza, ma data l’impossibilità di frequentare un master a Roma o Milano (quota dai 6000/7000 euro in su più i soldi necessari per vitto e alloggio!) ho optato per un corso disponibile a Firenze: il Cisco CCNA Security. Solo dopo aver iniziato il corso però ho compreso due cose: la prima è che il corso era rivolto unicamente agli amministratori di rete, in modo da fornire loro delle basi relative alla sicurezza sui router/switch; secondo che era necessaria la certificazione CCNA per sostenere quella relativa alla security :-O, e in più la notevole difficoltà che ho incontrato a seguire il corso! Le conoscenze fornitemi dalla laurea non erano proprio sufficienti :-(, e ho dovuto faticare non poco per sostenere l’esame per la certificazione… Comunque ora che ho iniziato a muovere i primi passi nel settore IT posso cercare di fare una lista di quelle che sono le figure principali che ruotano attorno al settore della sicurezza informatica:

  • (Network) Security Administrator: è la persona che lavora parallelamente all’amministratore di rete, e si occupa di rendere sicura una certa rete configurando firewall/ACL, gestendo le autenticazioni degli utenti, crittografando le connessioni, e più in generale opera sulle configurazioni di router/switch/server/pc al fine di rendere la rete sicura. Una scheda che descrive il profilo (anche se orientato a soluzioni Microsoft) è disponibile al link profilo Security Administrator.
  • (Network) Security Manager:  è colui che si occupa di configurare  l’infrastruttura di rete e di applicare le procedure di sicurezza definite dall’azienda per cui lavora e conformi alle misure normative italiane. Inoltre deve garantire la sicurezza e la disponibilità dei dati, monitorare le performance, i database e gli eventi sospetti. E’ una figura centrale nell’infrastruttura informatica aziendale in quanto si occupa di gestire trasversalmente le procedure e le diverse soluzioni implementate con il compito specifico di assicurare quotidianamente l’affidabilità e la sicurezza dell’intero sistema informatico. Rispetto al Network Security Aministrator è una figura dalla preparazione più ampia (non solo configurazione di router/server).
  • Penetration Tester: è colui che determina il reale grado di sicurezza di una rete, cercando di violarla con una grande varietà di attacchi e non. L’obiettivo è quello di individuare eventuali vulnerabilità sfruttabili da terzi per ottenere accessi non autorizzati ai servizi e ai sistemi analizzati. Oltre ai problemi di sicurezza, devono essere rilevati, quali possibili punti deboli, i problemi relativi alla configurazione, che incidono sulla robustezza e le performance del sistema, e gli errori di progettazione della rete. A volte una cattiva configurazione è più pericolosa di un bug. Una descrizione di questo profilo e di cosa sono i penetration test è al link Penetration Tester.
  • (Network) Security Consultant: è il libero professionista, o colui che lavora assieme ad un piccolo team di persone (in genere da 2 a 4) o anche come dipendente di un’azienda, che viene ingaggiato da terze parti per configurare e gestire la sicurezza delle reti o dei sistemi.

Inoltre ci sono altre figure che possono operare a stretto contatto con la sicurezza, come:

  • System Administrator: è l’esperto di sistemi, come Linux e Windows, generalmente lato server, con buone conoscenze spesso anche di ambienti virtualizzati, di networking, e di sicurezza. Si occupa di amministrare i sistemi in questione, configurandone spesso anche gli aspetti di networking e hardening.
  • Network Administrator: è colui che gestisce tutto ciò che riguarda le reti, dalla configurazione di router e switch, a quella dei server, dei proxy, dei firewall, sia dal lato LAN che WAN. Oltre a ciò, molto spesso si occupa anche della parte di sicurezza inerente alle reti che gestisce, o comunque lavora a stretto contatto con le figure che si occupa di sicurezza di rete.

roghan