Aiuto di FrameSeer: Un problema tipico

Un problema tipico

Non riesco a controllare la posta!

È una lamentela udita molto spesso. Se si pensa a cosa succede alla pressione del pulsante "Controlla posta", ci si stupisce quanto il processo sia generalmente affidabile. Guardate la figura 1 e assumete che il client debba recuperare la posta dal server posta.

Network Diagram

Il client potrebbe avere una configurazione TCP/IP manuale o potrebbe recuperarla dinamicamente tramite DHCP (complicazione che per il momento ignoreremo). Supponiamo che la configurazione sia la seguente:

Indirizzo IP 192.168.1.100
Maschera di sottorete 255.255.255.0
Gateway di default: 192.168.1.1
Server DNS 192.168.2.10

In più, il programma di posta del client (Mail, Eudora, Outlook Express) è configurato per recuperare la posta da un nome tipo "posta.dominio.it", che il server DNS risolve in 192.168.2.11.

Prima che il client possa aprire una connessione POP3 con il server, deve prima chiedere al server DNS "qual'è l'indirizzo IP di posta.dominio.it?"; il client sa già l'indirizzo IP del server DNS (dalla sua configurazione) e quindi può costruire la richiesta DNS e passarla all'IP per la trasmissione.

La prima domanda che lo stack IP del client deve fare è "l'indirizzo IP del server DNS è sulla mia sottorete?", cosa che deduce da un'operazione di AND fra la maschera di sottorete e gli IP del mittente (il client stesso) e del destinatario (il server DNS). Se le porzioni mascherate (la "rete") sono le stesse, i due indirizzi sono sulla stessa sottorete.

Se le porzioni mascherate non sono le stesse, com'è nel nostro caso, il pacchetto deve essere inviato al router; il client sa già l'indirizzo IP del router (il gateway di default della sua configurazione), che per definizione si trova sulla stessa sottorete.

A questo punto entra in gioco il protocollo ARP (Address Resolution Protocol); il client invia una richiesta ARP broadcast che contiene la domanda "chi ha l'indirizzo IP 192.168.1.1 può mandarmi il suo indirizzo ethernet?", cui il router risponde. Il client inserisce questa risposta in una cache per evitare di dover rifare la stessa domanda in seguito.

Ora la richiesta DNS viene mandata al router via ethernet; il router consulta le sue tabelle e vede che il pacchetto deve essere inoltrato attraverso l'interfaccia 192.168.2.1, e invia una richiesta ARP broadcast attraverso di essa per ottenere l'indirizzo ethernet corrispondente all'IP 192.168.1.10, ottenuto il quale (e inseritolo in cache) invia la richiesta DNS.

Il server DNS formula la risposta 192.168.2.11 alla domanda originale del client ("qual'è l'indirizzo IP del server di posta?"). Come il client, lo stack del server DNS determina che la risposta deve andare su un'altra sottorete, fa una richiesta ARP per conoscere l'indirizzo ethernet del suo router che mette in cache e manda finalmente la risposta al router che la inoltra al client.

Le richieste e le risposte DNS vengono trasmessi tramite datagrammi UDP. L'UDP è spesso detto "inaffidabile", ma ciò significa semplicemente che non è previsto esplicitamente che il client sappia se il server ha ricevuto la sua richiesta; se la risposta del server non arriva, non c'è modo di sapere se il problema è dovuto al server o a qualcosa nel mezzo.

Non appena il client riceve la risposta DNS conosce l'indirizzo IP del server di posta e può chiedere al TCP di aprire una connessione sulla porta logica del protocollo POP3 (la porta 110). L'apertura di una connessione TCP comporta lo scambio di tre pacchetti: il primo è mandato dal client e include uno speciale flag chiamato SYN che richiede la "sincronizzazione dei numeri di sequenza".

Il SYN iniziale segue lo stesso percorso della richiesta DNS; il client determina che l'indirizzo destinazione del server POP3 non è sulla sua stessa sottorete e invia il pacchetto al router, di cui conosce già l'indirizzo ethernet (è in cache). Il router potrebbe dover inviare una richiesta ARP per conoscere l'indirizzo ethernet del server POP3 e inoltrare così il pacchetto SYN.

Il pacchetto SYN arriva quindi al server di posta; se il software che fornisce il servizio POP3 è in funzione, manda un pacchetto al client con i flag SYN e ACK, e il client reagisce con un pacchetto ACK: la connessione è ora aperta e il client di posta può iniziare a recuperare la posta.

Il TCP è detto "affidabile": il client sa che il server è attivo e accetta connessioni, e ogni pacchetto mandato riceve un'esplicita conferma con un pacchetto ACK. Il solo fatto che una connessione TCP sia aperta vi dice parecchio sullo stato di una rete.

Quando si verifica un problema, la percezione dell'utente su ciò che non funziona dipende da quanta informazione fornisce il client di posta.

L'utente ha tipicamente tre scelte:

Ignorare il problema e sperare che sparisca;
Chiamare l' help desk o un amico amministratore di sistema;
Cercare di capire dove si è manifestato il problema.

FrameSeer vi aiuta con la terza opzione; anche se non potete eliminare voi stessi il problema, potete aiutare l'help desk a determinarlo. Ecco una lista di cosa può andar male:

Il client usa l'interfaccia sbagliata	Controllate quale interfaccia FrameSeer seleziona per default all'apertura di un nuovo documento; se non è l'interfaccia che vi aspettate, verificate le vostre connessioni e le preferenze del Network.
L'interfaccia è inattiva o configurata erroneamente	Controllate il messaggio di stato che FrameSeer associa all'interfaccia fisica.
FrameSeer rimane in stato di "ascolto" (niente traffico).	Potreste essere connessi al vostro hub o switch locale (cosa che fa pensare al Mac OS X che l'interfaccia sia attiva) ma un'apparecchiatura più a monte è spenta o disconnessa. Se non vedete nessun traffico per un po', questo è un buon punto di partenza.
Nessuna richiesta ARP per il router parte dal client	Se non vedete richieste ARP in uscita, aprite una finestra di terminale e date il comando arp -a. Se vedete l'indirizzo IP e MAC del router vuol dire che quest'ultimo è in cache e non sono necessarie richieste ARP; se credete che l'indirizzo MAC sia sbagliato cancellatelo (date il comando man arp per dettagli) forzando il client a rifare una richiesta ARP.
Il client non riceve risposta alla sua richiesta ARP per l'indirizzo MAC del router	È probabile che il router sia spento, oppure che lo stack IP sia configurato erroneamente sul client, sul router o su entrambi.
Non ci sono richieste DNS per il server di posta che partono dal client	Controllate la configurazione IP, potreste non aver inserito il server DNS.
Il client non riceve risposta alla richiesta DNS per l'indirizzo IP del server di posta	Il server DNS potrebbe essere spento, o in alternativa potreste avere inserito l'indirizzo IP sbagliato del server DNS nella vostra configurazione (un problema che avviene tipicamente quando gli amministratori di rete modificano l'indirizzo del server DNS).
Ricevete una risposta DNS che non contiene un valore, o questo valore è sbagliato per quanto ne sapete.	Se il server DNS non può risolvere correttamente il nome dell'indirizzo di posta, quest'ultimo potrebbe aver cambiato indirizzo, oppure il server DNS potrebbe avere un file di configurazione sbagliato.
La richiesta DNS parte ma il router emette un pacchetto ICMP con il codice "destination unreachable" (destinazione irraggiungibile)	Il router non riesce a trovare la rotta verso la sottorete di destinazione: o una connessione non funziona o qualcuno ha manipolato erroneamente la configurazione del router stesso.
Il pacchetto TCP SYN parte per attivare la connessione POP3 ma non c'è ritorno	In mancanza di altre informazioni questo caso suggerisce che il server di posta non sia in esecuzione.
Il pacchetto TCP SYN parte ma la risposta è un pacchetto TCP RST	Il server di posta è attivo ma non accetta connessioni POP3; l'amministratore potrebbe aver chiuso temporaneamente il servizio oppure il software potrebbe essere andato in crash senza ripartire.
Si vede l'handshake TCP (SYN, SYN+ACK, ACK) ma la connessione viene chiusa (RST) subito dopo	Controllando il payload potete vedere se il server sta comunicando messaggi come "password errata" o "provate più tardi" o altri messaggi amministrativi.