Perdita di Ping su una VPN: raggruppa le richieste Echo prima della percentuale

Una cattura contiene sei richieste Echo e tre risposte, e qualcuno scrive nel ticket una perdita di pacchetti del 50 per cento. Quel numero può essere vero per la cattura e falso per il tunnel. Le sei richieste potrebbero appartenere a due conversazioni diverse con due contratti di consegna diversi. Raggruppale prima di dividere, e il rapporto smette di essere la parte interessante del report.

Passo 1: separa i flussi per origine e destinazione

Una richiesta Echo porta un'origine e una destinazione, e questi due campi definiscono a quale conversazione appartiene. Una sonda generata dal gateway usa l'indirizzo del tunnel del gateway, mentre una sonda inoltrata per conto di un host LAN conserva l'indirizzo di quell'host. Il lato remoto può avere una rotta di ritorno per una e non per l'altra, il che fa comportare i due gruppi in modo diverso per motivi che non hanno nulla a che vedere con il tunnel.

Dividi la cattura su questi campi prima di contare qualsiasi cosa, e mantieni la destinazione come parte della chiave. Due flussi verso peer diversi non sono confrontabili anche quando condividono un'origine.

Annota i gruppi con i loro conteggi, perché il passo successivo decide quali risposte appartengono a quale gruppo. Un gruppo con tre richieste e nessuna risposta corrispondente è un riscontro. Un gruppo con tre richieste e tre risposte è una linea di base.

Passo 2: abbina su identificatore e sequenza

Il formato Echo nella RFC 792 porta un identificatore e un numero di sequenza, e li tratta come i campi che accoppiano una risposta alla sua richiesta. Entrambi servono per quel compito. Un numero di sequenza da solo non è univoco, poiché mittenti o processi diversi possono riutilizzare lo stesso valore all'interno di una finestra di cattura. L'identificatore restringe il mittente e la sequenza restringe la posizione, ed è la coppia insieme che rende difendibile un abbinamento.

Una risposta inverte la direzione degli indirizzi della sua richiesta, quindi un abbinamento è una coppia richiesta-risposta e non due tuple identiche. Confronta l'origine della richiesta con la destinazione della risposta e la destinazione della richiesta con l'origine della risposta, poi conferma che identificatore e sequenza coincidono.

Conserva anche la finestra di osservazione, perché una cattura lunga può contenere un riutilizzo legittimo di entrambi i campi. Ridurre la finestra a una raffica elimina la maggior parte di quell'ambiguità. Rende anche i conteggi riproducibili per chiunque legga il ticket.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Passo 3: confronta le tuple allo stesso confine

Se la traduzione degli indirizzi di rete si trova tra il punto di cattura e il peer, gli indirizzi nella richiesta e nella risposta differiranno per progetto. Confronta le tuple a un solo confine, oppure porta la mappatura in modo esplicito perché la differenza sia conteggiata. Mescolare richieste prima della traduzione con risposte dopo la traduzione inventa disallineamenti che non sono mai esistiti sul cavo.

Decidi il confine prima di iniziare a contare, e dichiaralo nel report così che la persona successiva possa riprodurre il raggruppamento. Una cattura lato client e un'altra lato server sono due confini diversi. Ciascuna risponde a una domanda diversa su dove è scomparsa la risposta.

Un gruppo di sonde tradotte eredita anche lo stato proprio del dispositivo di traduzione, che può essere la ragione reale per cui una risposta non arriva mai. Controlla quello stato prima di dare la colpa al percorso oltre di esso.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Passo 4: dire cosa la cattura può e non può dimostrare

Un vuoto osservato non stabilisce che l'host remoto sia rimasto in silenzio. Il punto di cattura può vedere solo una direzione, un filtro può scartare la risposta, oppure il buffer può essersi riempito durante la finestra. Ognuno di questi produce la stessa assenza e una conclusione diversa.

Annota la posizione della cattura, l'espressione del filtro e i contatori degli scarti accanto ai conteggi, perché un rapporto senza di essi non può essere verificato. Sono quelle tre righe a rendere difendibile il numero in seguito.

Poi separa ciò che l'osservazione stabilisce da ciò che suggerisce, in due frasi invece di una. La prima frase indica i conteggi e il confine. La seconda indica l'ipotesi e cosa la confermerebbe.

Quando la domanda è se un percorso specifico scarta pacchetti, una sonda controllata con un indirizzo di origine esplicito è una prova più forte di un conteggio passivo di traffico misto. Inviala dalla stessa macchina, nello stesso momento, allo stesso peer. Cambia una variabile e il confronto regge.

Riporta i gruppi e il confine successivo

Il report ha tre righe: la definizione del gruppo, i conteggi abbinati all'interno di ciascun gruppo e il confine in cui è stato fatto il confronto. Il lettore può quindi vedere che un gruppo ha risposto completamente e un altro no, il che punta a una rotta o a un permesso e non a una perdita casuale.

Allega il file di cattura e le espressioni dei filtri perché il raggruppamento sia riproducibile. Un riepilogo senza il file è un'affermazione, non un risultato.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

Quando un gruppo mostra cinque risposte e l'altro nessuna, il riscontro è che un'origine ha una rotta di ritorno funzionante e l'altra no. È un ticket molto migliore di una percentuale mista, e indirizza il controllo successivo verso la rotta di ritorno invece che verso un'istanza VPN non correlata.