Il TCP è stato progettato per supportare connessioni end-to-end, cioè un host che comunica direttamente con un altro host. Certo, c'erano ponti e router in mezzo, ma questi dispositivi non toccavano l'intestazione TCP o il carico utile. Questo, tuttavia, non è più il caso. Ora abbiamo cose come traduttori di indirizzi di rete, firewall, sistemi di prevenzione delle intrusioni e acceleratori di rete. Tutte queste cose possono modificare l'intestazione TCP, inviare conferme o resettare o semplicemente far cadere il pacchetto nel secchio dei bit. A peggiorare le cose, questi dispositivi si trovano ad ogni estremità della rete e a volte anche nel mezzo.
Immaginate il caso di un host A sulla rete B con una connessione all'host Y sulla rete Z. Davanti alla rete B c'è un acceleratore WAN che aumenta il throughput tramite lo spoofing dei riconoscimenti dell'host Y. Questo permette all'host A di inviare i dati il più velocemente possibile. L'acceleratore si occuperà di tutti i buffer e delle ritrasmissioni. Sfortunatamente, il sistema di prevenzione delle intrusioni di fronte alla rete Z sta facendo cadere un innocente ma sospettoso pacchetto dall'host A. L'host Y non lo vede mai e quindi non lo riconosce. L'acceleratore WAN davanti alla rete B ritrasmette, ma naturalmente il pacchetto viene di nuovo fatto cadere. L'acceleratore alla fine si spegne e invia un reset all'host A e all'host Y.
Cosa vede l'amministratore di sistema dell'host A quando cerca di capire cosa succede dopo che un utente si lamenta? Vede che i pacchetti lasciano l'host A ottenere il riconoscimento dell'host Y, ma nessuna risposta del livello di applicazione da parte dell'host Y e poi l'host Y resetta la connessione, niente che indichi un problema o perché l'host Y resetta la connessione. Cosa vede l'amministratore di sistema dell'host Y? Vede che l'host A ha appena smesso di inviare pacchetti e poi ha inviato un reset, di nuovo nulla che indichi un problema o il motivo per cui l'host A ha resettato la connessione.
L'ipotesi che l'host A stia comunicando direttamente con l'host Y è sbagliata e fare questa ipotesi fa sì che ogni amministratore dia la colpa all'altro sistema per l'errore di connessione.
Per capire cosa sta succedendo, è necessario prestare attenzione ai valori dei campi "non interessanti" nei dati di tracciamento dell'intestazione IP, campi come "Tipo di servizio", ID, Flags e "Time to Live" (TTL). I cambiamenti in questi campi, per esempio i pacchetti con dati hanno un TTL di 47 e i pacchetti senza dati hanno un TTL di 127, possono indicare che i pacchetti provengono da due fonti diverse.
Confrontando le tracce sia dell'ospite A che dell'ospite Y si può mettere in luce il problema. Non solo si possono vedere pacchetti in una traccia che non sono nell'altra, ma i cambiamenti in tutti quei campi di intestazione IP non interessanti o nei numeri di porta o di sequenza TCP indicheranno con il 100% di certezza che questi host non stanno comunicando direttamente tra loro.
Potrebbe non essere possibile spegnere l'acceleratore di rete o il sistema di prevenzione delle intrusioni (e potrebbe anche non essere una buona idea), ma sapere che ci sono e sapere cosa stanno facendo ti dà una migliore possibilità di capire e correggere i problemi quando si verificano.
Azienda