Retransmissões TCP contra rejeições de repetição IPsec: leia cada camada
Um sinalizador de retransmissão, um ACK duplicado e um contador de rejeições de repetição ESP medem eventos diferentes em camadas diferentes. Leia cada contador onde ele é produzido.
Três ferramentas diferentes relatam três duplicatas diferentes, e apenas uma delas é um evento de rede sobre o qual você pode agir. Uma retransmissão TCP é um emissor que reenvia um intervalo, um ACK duplicado é um receptor que repete uma confirmação, e uma rejeição de repetição ESP é uma associação de segurança que recusa um número de sequência que já aceitou. Nenhuma das três implica qualquer das outras. Leia cada contador na camada que o produz antes de reuni-los numa história.
Três contadores que nunca medem o mesmo evento
A anotação de retransmissão TCP significa que o emissor colocou novamente um intervalo de sequência no fio. A perda é uma das razões, e a captura que você tem pode simplesmente não ter o pacote original ou a confirmação que explicaria o momento. Um ACK duplicado é o receptor repetindo uma confirmação cumulativa segundo as regras de recuperação do TCP, o que não é nem uma escrita duplicada da aplicação nem uma segunda cópia dos dados.
O ESP trabalha no seu próprio espaço de sequência. Cada associação de segurança numera os pacotes que envia, e o receptor mantém uma janela de números que já aceitou, então um pacote ESP que chega duas vezes é descartado apenas por essas regras. Por isso um segmento TCP retransmitido viaja num novo pacote ESP com um novo número de sequência, o que é o comportamento correto nas duas camadas. Os mesmos bytes podem parecer novos num contador e velhos noutro, e nenhuma das camadas mente.
O que o analisador pode e não pode ver
Comece pelo vocabulário do analisador, porque os nomes dos filtros descrevem observações e não o interior dos extremos. Contar com os mesmos nomes que a ferramenta usa mantém você honesto sobre o que foi realmente medido. Uma contagem de uma captura incompleta é uma contagem do que sobreviveu, não do que aconteceu no fio.
tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l
Leia as informações especializadas ao lado desses números, porque avisos de soma de verificação e de ordenação mudam quanto peso eles merecem. Um rastro fundido de dois sensores pode mostrar um quadro duas vezes, e contar as duas cópias inventa um evento de recuperação que nunca ocorreu.
Os contadores ESP vivem no estado do núcleo
Os números de sequência ESP pertencem à associação de segurança, não ao fluxo TCP, então o gateway é o lugar de perguntar. A listagem de estado relata contadores de pacotes e erros por associação que nenhuma captura consegue reconstruir.
ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head
RFC 4303 define o número de sequência e a janela antirrepetição que o consome, e por isso o contador sobe mesmo quando nada está errado. Números de sequência externos monótonos sem anomalia TCP correspondente apontam para outro emissor ou um caminho duplicado em vez de uma tempestade de retransmissões. Uma captura externa de um túnel cifrado normalmente esconde os números de sequência TCP internos, então não pode provar o que a pilha interna fez. Capture dentro do túnel apenas onde a política permitir, e nunca desative a antirrepetição para silenciar um aviso não relacionado.
Onde o ponto de observação muda a resposta
Antes de escalar, anote como a captura foi feita: a interface, se o processo de captura relatou perdas e se os carimbos de tempo são comparáveis entre sensores. Um único ponto de observação não consegue ver as duas pontas de um caminho, então qualquer afirmação sobre o comportamento do receptor é uma inferência e não uma medição. Um rastro feito no gateway e um rastro feito no host discordarão sobre a ordenação sob carga, e essa discordância normalmente pertence à captura e não ao túnel. Correlacionar duas visões é o que transforma uma contagem em evidência.
Use um fluxo de aplicação permitido e anote os contadores dos extremos ao lado das contagens da captura no mesmo momento. Se os números discordarem, confie na camada que possui o evento e trate a outra como artefato de observação até que se prove o contrário. Essa regra resolve a maioria desses chamados sem tocar na configuração do túnel.
Ler os números na ordem correta
Comece pela camada onde a pergunta foi feita: um aviso TCP é respondido a partir de uma captura TCP, e uma rejeição ESP é respondida a partir dos contadores da associação de segurança no gateway. Só então pergunte se as duas visões descrevem o mesmo pacote. Uma conclusão que exige as duas camadas deve nomear as duas, porque uma afirmação sobre o túnel baseada apenas numa anotação TCP é um palpite.
Anote a camada, o contador e o ponto de observação para cada achado, e o próximo leitor não fundirá três eventos num único defeito imaginário. Escale com esses três campos e a correção normalmente decorre do primeiro.