Dicono la verità, a meno che non siano registrate in modo errato. In questi casi, i pacchetti possono davvero dire bugie sfacciate.
Durante la ricerca nei file di traccia, potremmo imbatterci in sintomi nei pacchetti che farebbero storcere il naso a molti. Si tratta di eventi che sembrano strani in superficie e possono persino distrarci temporaneamente dalla risoluzione dei problemi. Alcuni di questi problemi in realtà hanno tratto in inganno. network analisti per ore, se non giorni, costringendoli a inseguire problemi ed eventi che semplicemente non esistono sul network.
La maggior parte di questi esempi può essere facilmente evitata catturando i pacchetti da un network Test Access Point (TAP) anziché sulla macchina in cui viene generato il traffico. Con un network TAP, puoi catturare il network dati in modo trasparente e inalterato e vedere cosa viene realmente trasmesso via cavo.
Nella maggior parte dei casi, i pacchetti non dovrebbero essere più grandi del massimo Ethernet di 1518 byte, o di quanto specificato per il link MTU. Tuttavia, questo è vero solo se non stiamo usando tag 802Q o siamo in un ambiente jumbo frame.
Come è possibile avere pacchetti più grandi del massimo Ethernet? In parole povere, li catturiamo prima che vengano segmentati dalla NIC. Molti stack TCP/IP oggi usano TCP Segmentation Offload, che delega l'onere della segmentazione dei pacchetti alla NIC. Il driver WinPcap o Libpcap cattura i pacchetti prima che questo processo abbia luogo, quindi alcuni dei pacchetti potrebbero sembrare troppo grandi per essere legittimi.
Se la stessa attività è stata catturata su network, questi grandi telai verrebbero suddivisi in più telai più piccoli per il trasporto.
Zero Delta Tempo
Tempi delta pari a zero significa che non c'è tempo misurato tra i pacchetti. Quando questi pacchetti entrano nel dispositivo di cattura, ricevono un timestamp e un delta time misurabile. Il timestamp di ingresso sul dispositivo di cattura non è riuscito a tenere il passo con il volume dei pacchetti. D'altro canto, se questi pacchetti fossero stati catturati con un server tap esterno, potremmo probabilmente ottenere un timestamp senza errori.
Pacchetti precedenti non catturati
Questo avviso viene visualizzato perché Wireshark ha notato un gap nel flusso di dati TCP. Può determinare dai numeri sequenziati che manca un pacchetto. A volte questo è giustificato dalla perdita di pacchetti upstream. Tuttavia, potrebbe anche essere un sintomo che l'analizzatore o SPAN ha eliminato il pacchetto perché non è riuscito a tenere il passo con il carico.
Dopo questo avviso, dovresti cercare una serie di pacchetti ACK duplicati invece di un pacchetto difettoso. Ciò indica che un pacchetto è stato effettivamente perso e deve essere ritrasmesso. Se non vedi pacchetti ritrasmessi o difettosi, probabilmente l'analizzatore o lo SPAN non sono riusciti a tenere il passo con il flusso di dati. Il pacchetto era effettivamente sul network, ma non l'abbiamo visto.
Segmenti non rilevati da TCP
In questo caso, viene visualizzato un riconoscimento per un pacchetto dati che non è stato rilevato. Il pacchetto dati potrebbe aver preso un percorso diverso o il dispositivo di cattura potrebbe semplicemente non averlo notato.
Di recente ho visto questi eventi su file di traccia catturati da switch, router e firewall. Poiché la cattura del traffico ha una priorità inferiore rispetto all'inoltro (grazie al cielo!), il dispositivo potrebbe semplicemente perdere alcuni frame nel flusso di dati. Dopo aver visto la conferma, sappiamo che il pacchetto è arrivato a destinazione.
Per la maggior parte, i pacchetti dicono la verità. Possono condurci alla causa principale dei nostri network e problemi applicativi. Poiché presentano dati così chiari e dettagliati, è molto importante che li registriamo il più vicino possibile alla network il più possibile. Ciò significa che dobbiamo acquisirli durante la trasmissione, anziché sul server stesso. Questo ci aiuta a non perdere tempo con falsi negativi.
Se volete saperne di più su network Considerazioni sulla visualizzazione per i professionisti: scarica la nostra infografica gratuita, TAP vs SPAN.
Condividi questo blog:
Timur è il fondatore e CEO di NEOX Networks, Un fornitore leader di network soluzioni di visibilità e sicurezza. Con oltre 25 anni di esperienza nel settore, Timur ha una profonda comprensione delle sfide che i team IT e OT di oggi devono affrontare in network e domini di sicurezza. È appassionato di sfruttare la tecnologia per risolvere problemi complessi e crede che un'efficace network La visibilità è fondamentale per il successo di qualsiasi organizzazione in termini di disponibilità e sicurezza delle applicazioni aziendali. Timur si impegna a fornire soluzioni innovative che soddisfino le esigenze in continua evoluzione dei clienti NEOX.