#128 – Analizzare la rete – Parte seconda

Siete sempre al lavoro con me, oggi vediamo la differenza tra un HUB e uno switch, come girano i pacchetti, come si possono analizzare con uno switch gestito (link sponsorizzato), il software Wireshark e come si può provare un DNS con il comando nslookup per Windows e Linux

Pillole di Bit (https://www.pilloledib.it/) è un podcast indipendente realizzato da Francesco Tucci, se vuoi metterti con contatto con me puoi scegliere tra diverse piattaforme: - Telegram (o anche solo il canale dedicato solo ai commenti delle puntate) - TikTok (per ora è un esperimento) - Twitter - BlueSky - Il mio blog personale ilTucci.com - Il mio canale telegram personale Le Cose - Mastodon personale - Mastodon del podcast - la mail (se mi vuoi scrivere in modo diretto e vuoi avere più spazio per il tuo messaggio) Rispondo sempre Se questo podcast ti piace, puoi contribuire alla sue realizzazione! Con una donazione diretta: - Singola con Satispay - Singola o ricorrente con Paypal Usando i link sponsorizzati - Con un acquisto su Amazon (accedi a questo link e metti le cose che vuoi nel carrello) - Attivando uno dei servizi di Ehiweb Se hai donato più di 5€ ricordati di compilare il form per ricevere i gadget!

Il sito è gentilmente hostato da ThirdEye (scrivete a domini AT thirdeye.it), un ottimo servizio che vi consiglio caldamente e il podcast è montato con gioia con PODucer, un software per Mac di Alex Raccuglia

Ciao a tutti e bentornati all’ascolto di Pillole di Bit, questa è la puntata 128 e io sono, come sempre, Francesco. Dove ero rimasto? Innanzitutto, se state ascoltando questa puntate e non avete ascoltato la precedente fermatevi subito e andate a recuperarla, questa è una seconda parte, se non ascoltate quella di prima non ci capite nulla. Riprendiamo. Dopo aver fatto il test con il cambio del mac address e aver appurato che il problema non era quello, è stato necessario attivare il cervello per capire come risolvere. Il passo successivo l’ho fatto cambiando IP del dispositivo, senza ottenere alcun risultato. Così per scrupolo, ho anche cambiato gli IP dei DNS configurati, togliendo quelli di Google e mettendo quelli di Cloudlfare, anche qui, ovviamente non cambia nulla. Mentre cercavo un po’ di documentazione su questo dispositivo, mi sono accorto che l’apertura dei siti dal mio PC era un po’ rallentata, come se ci volesse qualche secondo in più per risolvere il nome del sito. Dalle piccole cose nascono le scintille che poi accendono il fuoco. Ok, la smetto di dire fesserie, mi sono insospettito e ho fatto un test. Ho aperto la riga di comando e ho provato a risolvere dei nomi di siti con il comando nslookup. Dopo aver fatto un po’ di prove mi rendo conto che in questa rete il DNS primario di google, quello con indirizzo 8.8.8.8, non funzionava. Lo raggiungevo con il PING, ma la risoluzione non andava. Avevo sempre un timeout Facendo un po’ di test mi sono accorto che era solo quello a non andare. Avrei potuto chiamare il fornitore della connettività, ma visto che stavo lavorando in pausa pranzo, per non fermare la produttività della sede, ancora non potevo chiamarli. Il PC andava più lento perché avendo impostato due DNS, una volta fallita la chiamata sul primo, lui cercava sul secondo, quindi passavano circa 2 secondi che generavano il fastidioso ritardo. Ormai siamo abituati bene e un ritardo di due secondi dalla pressione del tasto INVIO è considerata eccessiva. E sul dispositivo, perché le cose ancora non andavano anche se avevo impostato altri DNS? Era necessario andare a fondo del problema e risolverlo definitivamente. Qui ho estratto dal cilindro, anzi, no, dal mio zaino, uno switch evoluto, i tecnici dicono “gestito” Qui serve una piccola parentesi su come funziona lo scambio dei dati attraverso uno switch. Quando si collegano dei dispositivi a uno switch, questo memorizza quale mac address è collegato su quale porta. Se uno switch è attaccato a un altro switch, i due si passano le liste dei mac address ad essi collegati. Quando da un dispositivo arriva un pacchetto che va consegnato a un certo mac address, visto che gli switch lavorano su un livello più basso del protocollo IP, lo switch inoltra quel pacchetto sulla porta dove sa essere attestato il mac address di destinazione. Fa un po’ come il postino: la cartolina è inviata a Mario Rossi in Via Roma 10, lui parte, la porta in via Roma 10 e suona il campanello. Per fare analisi sulla rete con un dispositivo terzo, questa cosa è problematica, perché se mi attacco ad un’altra porta di quello switch non vedrò mai passare i pacchetti che non sono indirizzati direttamente a me. Fino a qualche tempo fa si usavano dei vecchi HUB, che, a differenza degli switch, invece di mandare i pacchetti sulla porta dove è collegato il dispositivo di destinazione, mandano tutti i pacchetti che arrivano su tutte le porte. Un po’ come se l’ufficio postale, ricevuta una cartolina da inviare in via Roma 10, ne fa 100 copie e manda 100 postini ognuno per ogni numeri civico di via Roma dall’1 al 100, quello che arriva al 10, la imbuca, tutti gli altri al buttano nel cestino. Ovviamente in questo caso, se voglio vedere cosa passa, mi metto ad un qualsiasi civico di via Roma e chiedo al postino di carmi la cartolina, se questa è per via Roma 10. Spero di essermi spiegato in modo abbastanza chiaro. Visto che gli HUB in circolazione non ci sono più, ho preso questo switch e nella sua pagina di configurazione ho impostato che nella porta 1 mi deve mandare tutti i pacchetti che passano nella porta 2. Ho attaccato il dispositivo maledetto alla porta 2, il mio PC alla porta 1 e il resto della rete alla porta 3. Ho aperto il programma WireShark sul mio PC e gli ho detto “senti, adesso mi fai vedere tutti pacchetti che hanno origine o destinazione l’IP del dispositivo maledetto. A questo punto ho fatto partire il test. Primi pacchetti: il ping al gateway, con relativa risposta. Pacchetti successivi: il ping al DNS impostato, 8.8.8.8, con relativa risposta Terzo blocco di pacchetti: un tentativo di risoluzione del sito del servizio al quale si doveva collegare il dispositivo: nessuna risposta, sul display compare Fail. Adesso io andrei a prendere chi ha sviluppato il test di rete e lo appenderei per i pollici a un lampione. Se il test fallisce perché non risolve il nome, porcalamisreia, dimmi “fallito DNS”, così so dove andare a vedere! Ok, fin qui era previsto. Allora cambio il DNS. So che non va solo quello di Google 8.8.8.8, metto i due di Cloudflare e ci riprovo Primo blocco: come prima Secondo blocco: fa il ping al DNS di Cloudflare, funziona Terzo blocco: fa la chiamata DNS al DNS di google, il maledetto. Maschero il mio odio con un sorriso e riavvio il maledetto dispositivo. Il test va a buon fine, perché finalmente usa i DNS Di CloudFlare. Caro sviluppatore del dispositivo, quindi caro maledetto sviluppatore di un dispositivo maledetto, vorrei dirti alcune cose. Primo: se un test fallisce, devi dire cosa fallisce Secondo: se ci sono due server DNS nelle configurazioni del tuo dispositivo, perché usi solo il primo per fare il test e per la normale operatività? Fai come tutti i dispositivi di questo mondo: ce ne sono due e se il primo non va usi il secondo. Terzo: se per confermare il cambiamento delle impostazioni di rete devo riavviare il dispositivo, quando le salvo, scrivi un messaggio, dimmi che devo riavviare! Altro che appenderti per i pollici! Il tutto è durato poco meno di 2 ore, tra un santo e l’altro. Il provider ha poi sistemato la cosa del solo DNS di Google bloccato cambiando il router, adducendo a un problema di firmware mai corretto. I contatti Se ascoltate questo podcast da un po’ questa parte potrebbe essere un po’ noiosa, infatti l’idea è di renderla più corta rispetto al resto della puntata. Tutte le informazioni su come contattarmi via twitter, Telegram e posta elettronica le trovate sul sito www.pilloledib.it Sullo stesso sito trovate anche i link per le donazioni, se volete sostenere questo podcast, se donate 5€ o più, mi compilate il form apposito e vi mando gli adesivi a casa. Visto? Breve ed efficace. O almeno lo spero. Il tip Di solito il DNS è un servizio che, se non va, rende inutilizzabile una connessione, quindi è bene sapere come testarlo. Tutti i sistemi operativi hanno il comando “nslookup” che serve appunto a questo scopo. Aprite un prompt dei comandi, su windows dal menu start scrivete cmd e poi invio, su mac aprite l’app terminale e su Linux pure. Ma se usate linux sapete sicuramente come accedere al terminale. Il comando nslookup www.google.it vi restituisce l’indirizzo IP del server di Google, risolto con il vostro DNS principale Se invece volete usare un dns specifico basta metterlo dopo, quindi il comando diventa nslookup www.google.it 1.1.1.1 Nelle note dell’episodio vi lascio il link alla pagina con il manuale completo del comando, vale per tutti i sistemi operativi, circa. Bene è proprio tutto, non mi resta che salutarvi e darvi appuntamento alla prossima puntata. Ciao!