Perda de Ping numa VPN: agrupe os pedidos Echo antes da percentagem

Uma captura contém seis pedidos Echo e três respostas, e alguém escreve 50 por cento de perda de pacotes no ticket. Esse número pode ser verdadeiro para a captura e falso para o túnel. Os seis pedidos podem pertencer a duas conversas diferentes com dois contratos de entrega diferentes. Agrupe-os antes de dividir, e a proporção deixa de ser a parte interessante do relatório.

Passo 1: separar os fluxos por origem e destino

Um pedido Echo transporta uma origem e um destino, e esses dois campos definem a que conversa pertence. Uma sonda gerada pelo gateway usa o endereço do túnel do gateway, enquanto uma sonda encaminhada em nome de um anfitrião LAN mantém o endereço desse anfitrião. O lado remoto pode ter uma rota de retorno para uma e não para a outra, o que faz os dois grupos comportarem-se de forma diferente por razões que nada têm que ver com o túnel.

Divida a captura por esses campos antes de contar o que quer que seja, e mantenha o destino como parte da chave. Dois fluxos para pares diferentes não são comparáveis mesmo quando partilham uma origem.

Anote os grupos com as suas contagens, porque o passo seguinte decide que respostas pertencem a que grupo. Um grupo com três pedidos e nenhuma resposta correspondente é um achado. Um grupo com três pedidos e três respostas é uma linha de base.

Passo 2: corresponder pelo identificador e pela sequência

O formato Echo da RFC 792 transporta um identificador e um número de sequência, e trata-os como os campos que emparelham uma resposta com o seu pedido. Ambos são necessários para essa tarefa. Um número de sequência sozinho não é único, pois remetentes ou processos diferentes podem reutilizar o mesmo valor dentro de uma janela de captura. O identificador restringe o remetente e a sequência restringe a posição, e é o par em conjunto que torna uma correspondência defensável.

Uma resposta inverte a direção dos endereços do seu pedido, pelo que uma correspondência é um par pedido-resposta e não duas tuplas idênticas. Compare a origem do pedido com o destino da resposta e o destino do pedido com a origem da resposta, e depois confirme que o identificador e a sequência coincidem.

Guarde também a janela de observação, porque uma captura longa pode conter reutilização legítima de ambos os campos. Reduzir a janela a uma rajada elimina a maior parte dessa ambiguidade. Também torna as contagens reproduzíveis para quem ler 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

Passo 3: comparar as tuplas na mesma fronteira

Se a tradução de endereços de rede estiver entre o ponto de captura e o par, os endereços no pedido e na resposta diferirão por desenho. Compare as tuplas numa só fronteira, ou transporte o mapeamento explicitamente para que a diferença seja contabilizada. Misturar pedidos anteriores à tradução com respostas posteriores inventa desalinhamentos que nunca existiram no cabo.

Decida a fronteira antes de começar a contar, e indique-a no relatório para que a pessoa seguinte possa reproduzir o agrupamento. Uma captura do lado do cliente e outra do lado do servidor são duas fronteiras diferentes. Cada uma responde a uma pergunta diferente sobre onde a resposta desapareceu.

Um grupo de sondas traduzidas herda também o estado próprio do dispositivo de tradução, que pode ser a razão real pela qual uma resposta nunca chega. Verifique esse estado antes de culpar o caminho além dele.

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: dizer o que a captura pode e não pode provar

Um vazio observado não estabelece que o anfitrião remoto ficou em silêncio. O ponto de captura pode ver apenas uma direção, um filtro pode descartar a resposta, ou o buffer pode ter transbordado durante a janela. Cada um destes produz a mesma ausência e uma conclusão diferente.

Anote a localização da captura, a expressão do filtro e os contadores de descartes junto às contagens, porque uma proporção sem eles não pode ser auditada. São essas três linhas que tornam o número defensável mais tarde.

Depois separe o que a observação estabelece do que sugere, em duas frases em vez de uma. A primeira frase indica as contagens e a fronteira. A segunda indica a hipótese e o que a confirmaria.

Quando a pergunta é se um caminho concreto descarta pacotes, uma sonda controlada com um endereço de origem explícito é uma prova mais forte do que uma contagem passiva de tráfego misturado. Envie-a a partir da mesma máquina, à mesma hora, para o mesmo par. Mude uma variável e a comparação mantém-se.

Relate os grupos e a próxima fronteira

O relatório tem três linhas: a definição do grupo, as contagens emparelhadas dentro de cada grupo e a fronteira em que a comparação foi feita. O leitor pode então ver que um grupo respondeu por completo e outro não, o que aponta para uma rota ou uma permissão e não para uma perda aleatória.

Anexe o ficheiro de captura e as expressões dos filtros para que o agrupamento possa ser reproduzido. Um resumo sem o ficheiro é uma afirmação, não um 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

Quando um grupo mostra cinco respostas e o outro nenhuma, o achado é que uma origem tem uma rota de retorno funcional e a outra não. É um ticket muito melhor do que uma percentagem misturada, e aponta a verificação seguinte para a rota de retorno em vez de para uma instância VPN não relacionada.