Perda de Ping nunha VPN: agrupa as solicitudes Echo antes da porcentaxe

Unha captura contén seis solicitudes Echo e tres respostas, e alguén escribe no ticket unha perda de paquetes do 50 por cento. Ese número pode ser certo para a captura e falso para o túnel. Pode que as seis solicitudes pertenzan a dúas conversas distintas con dous contratos de entrega distintos. Agrúpaas antes de dividir, e a proporción deixa de ser a parte interesante do informe.

Paso 1: separa os fluxos por orixe e destino

Unha solicitude Echo leva unha orixe e un destino, e eses dous campos definen a que conversa pertence. Unha sonda xerada pola pasarela usa o enderezo do túnel da pasarela, mentres que unha sonda reenviada en nome dun host LAN conserva o enderezo dese host. O lado remoto pode ter unha ruta de retorno para unha e non para a outra, o que fai que os dous grupos se comporten de forma distinta por motivos que nada teñen que ver co túnel.

Divide a captura por eses campos antes de contar nada, e mantén o destino como parte da clave. Dous fluxos cara a pares distintos non son comparables aínda que compartan unha orixe.

Anota os grupos cos seus reconto, porque o paso seguinte decide que respostas pertencen a cada grupo. Un grupo con tres solicitudes e ningunha resposta coincidente é un achado. Un grupo con tres solicitudes e tres respostas é unha liña base.

Paso 2: empareja polo identificador e a secuencia

O formato Echo da RFC 792 leva un identificador e un número de secuencia, e trátaos como os campos que emparellan unha resposta coa súa solicitude. Ambos fan falta para esa tarefa. Un número de secuencia por si só non é único, xa que distintos emisores ou procesos poden reutilizar o mesmo valor dentro dunha ventá de captura. O identificador acouta o emisor e a secuencia acouta a posición, e a parella en conxunto é o que fai defendible unha coincidencia.

Unha resposta inverte a dirección de enderezos da súa solicitude, así que unha coincidencia é unha parella solicitude-resposta e non dúas tuplas idénticas. Compara a orixe da solicitude co destino da resposta e o destino da solicitude coa orixe da resposta, e despois confirma que o identificador e a secuencia coinciden.

Conserva tamén a ventá de observación, porque unha captura longa pode conter unha reutilización lexítima de ambos os campos. Recortar a ventá a unha ráfaga elimina a maior parte desa ambigüidade. Tamén fai que os reconto sexan reproducibles para quen lea o 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

Paso 3: compara as tuplas na mesma fronteira

Se a tradución de enderezos de rede se sitúa entre o punto de captura e o par, os enderezos da solicitude e da resposta diferirán por deseño. Compara as tuplas nunha soa fronteira, ou leva o mapeo de forma explícita para que a diferenza quede contabilizada. Mesturar solicitudes anteriores á tradución con respostas posteriores inventa desaxustes que nunca existiron no cable.

Decide a fronteira antes de comezar a contar, e indícaa no informe para que a seguinte persoa poida reproducir a agrupación. Unha captura no lado do cliente e outra no lado do servidor son dúas fronteiras distintas. Cada unha responde a unha pregunta distinta sobre onde desapareceu a resposta.

Un grupo de sondas traducidas tamén herda o estado propio do dispositivo de tradución, que pode ser a razón real pola que unha resposta nunca chega. Comproba ese estado antes de culpar o camiño que hai máis aló.

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

Paso 4: di que pode e que non pode demostrar a captura

Un oco observado non establece que o host remoto calase. O punto de captura pode ver só unha dirección, un filtro pode descartar a resposta, ou o búfer pode ter desbordado durante a ventá. Cada un deles produce a mesma ausencia e unha conclusión distinta.

Anota a localización da captura, a expresión do filtro e os contadores de descartes xunto aos reconto, porque unha proporción sen eles non se pode auditar. Esas tres liñas son o que fai defendible o número máis adiante.

Despois separa o que a observación establece do que suxire, en dúas frases en lugar dunha. A primeira frase indica os reconto e a fronteira. A segunda indica a hipótese e que a confirmaría.

Cando a pregunta é se unha ruta concreta descarta paquetes, unha sonda controlada cun enderezo de orixe explícito é unha evidencia máis forte que un reconto pasivo de tráfico mesturado. Envíaa desde a mesma máquina, á mesma hora, ao mesmo par. Cambia unha variable e a comparación mantense.

Informa dos grupos e da próxima fronteira

O informe ten tres liñas: a definición do grupo, os reconto emparellados dentro de cada grupo e a fronteira na que se fixo a comparación. Así o lector pode ver que un grupo respondeu por completo e outro non, o que apunta a unha ruta ou un permiso e non a unha perda aleatoria.

Anexa o ficheiro de captura e as expresións de filtro para que a agrupación se poida reproducir. Un resumo sen o ficheiro é unha afirmación, non un resultado.

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

Cando un grupo mostra cinco respostas e o outro ningunha, o achado é que unha orixe ten unha ruta de retorno que funciona e a outra non. É un ticket moito mellor que unha porcentaxe mesturada, e orienta a seguinte comprobación cara á ruta de retorno en lugar de cara a unha instancia VPN non relacionada.