Pèrdua de Ping en una VPN: agrupa les peticions Echo abans del percentatge

Una captura conté sis peticions Echo i tres respostes, i algú escriu al tiquet una pèrdua de paquets del 50 per cent. Aquest número pot ser cert per a la captura i fals per al túnel. Potser les sis peticions pertanyen a dues converses diferents amb dos contractes de lliurament diferents. Agrupa-les abans de dividir, i la proporció deixa de ser la part interessant de l'informe.

Pas 1: separa els fluxos per origen i destinació

Una petició Echo porta un origen i una destinació, i aquests dos camps defineixen a quina conversa pertany. Una sonda generada per la passarel·la utilitza l'adreça del túnel de la passarel·la, mentre que una sonda reenviada en nom d'un amfitrió LAN conserva l'adreça d'aquest amfitrió. El costat remot pot tenir una ruta de retorn per a una i no per a l'altra, cosa que fa que els dos grups es comportin de manera diferent per motius que no tenen res a veure amb el túnel.

Divideix la captura per aquests camps abans de comptar res, i mantén la destinació com a part de la clau. Dos fluxos cap a parells diferents no són comparables encara que comparteixin un origen.

Anota els grups amb els seus comptes, perquè el pas següent decideix quines respostes pertanyen a cada grup. Un grup amb tres peticions i cap resposta coincident és una troballa. Un grup amb tres peticions i tres respostes és una línia base.

Pas 2: emparella per l'identificador i la seqüència

El format Echo de l'RFC 792 porta un identificador i un número de seqüència, i els tracta com els camps que emparellen una resposta amb la seva petició. Tots dos calen per a aquesta feina. Un número de seqüència sol no és únic, ja que remitents o processos diferents poden reutilitzar el mateix valor dins d'una finestra de captura. L'identificador estreta el remitent i la seqüència estreta la posició, i la parella juntes és el que fa defensable una coincidència.

Una resposta inverteix la direcció d'adreces de la seva petició, així que una coincidència és una parella petició-resposta i no dues tuples idèntiques. Compara l'origen de la petició amb la destinació de la resposta i la destinació de la petició amb l'origen de la resposta, i després confirma que l'identificador i la seqüència coincideixen.

Conserva també la finestra d'observació, perquè una captura llarga pot contenir una reutilització legítima dels dos camps. Retallar la finestra a una ràfega elimina la major part d'aquesta ambigüitat. També fa que els comptes siguin reproduïbles per a qui llegeixi el tiquet.

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

Pas 3: compara les tuples a la mateixa frontera

Si la traducció d'adreces de xarxa se situa entre el punt de captura i el parell, les adreces de la petició i la resposta diferiran per disseny. Compara les tuples en una sola frontera, o bé porta el mapatge explícitament perquè la diferència quedi comptabilitzada. Barrejar peticions prèvies a la traducció amb respostes posteriors inventa desajustos que mai van existir al cable.

Decideix la frontera abans de començar a comptar, i indica-la a l'informe perquè la propera persona pugui reproduir l'agrupació. Una captura al costat del client i una altra al costat del servidor són dues fronteres diferents. Cadascuna respon una pregunta diferent sobre on va desaparèixer la resposta.

Un grup de sondes traduïdes també hereta l'estat propi del dispositiu de traducció, que pot ser la raó real per la qual una resposta no arriba mai. Comprova aquest estat abans de culpar el camí que hi ha més enllà.

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

Pas 4: digues què pot i què no pot demostrar la captura

Un buit observat no estableix que l'amfitrió remot hagi callat. El punt de captura pot veure només una direcció, un filtre pot descartar la resposta, o el búfer pot haver desbordat durant la finestra. Cadascun d'aquests produeix la mateixa absència i una conclusió diferent.

Anota la ubicació de la captura, l'expressió del filtre i els comptadors de descartades al costat dels comptes, perquè una proporció sense ells no es pot auditar. Aquestes tres línies són el que fa defensable el número més endavant.

Després separa què estableix l'observació del que suggereix, en dues frases en lloc d'una. La primera frase indica els comptes i la frontera. La segona indica la hipòtesi i què la confirmaria.

Quan la pregunta és si un camí concret descarta paquets, una sonda controlada amb una adreça d'origen explícita és una evidència més forta que un recompte passiu de trànsit barrejat. Envia-la des de la mateixa màquina, a la mateixa hora, al mateix parell. Canvia una variable i la comparació es manté.

Informa dels grups i de la propera frontera

L'informe té tres línies: la definició del grup, els comptes emparellats dins de cada grup i la frontera on es va fer la comparació. Aleshores el lector pot veure que un grup va respondre completament i l'altre no, cosa que apunta a una ruta o un permís i no a una pèrdua aleatòria.

Adjunta el fitxer de captura i les expressions dels filtres perquè l'agrupació es pugui reproduir. Un resum sense el fitxer és una afirmació, no un resultat.

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

Quan un grup mostra cinc respostes i l'altre cap, la troballa és que un origen té una ruta de retorn que funciona i l'altre no. És un tiquet molt millor que un percentatge barrejat, i apunta la propera comprovació a la ruta de retorn en lloc d'una instància VPN no relacionada.