Retransmisións TCP fronte aos descartes de repetición IPsec: lea cada capa
Un indicador de retransmisión, un ACK duplicado e un contador de descartes de repetición ESP miden eventos distintos en capas distintas. Lea cada contador onde se produce.
Tres ferramentas distintas informan de tres duplicados distintos, e só un deles é un evento de rede sobre o que pode actuar. Unha retransmisión TCP é un emisor que volve enviar un rango, un ACK duplicado é un receptor que repite unha confirmación, e un descarte de repetición ESP é unha asociación de seguridade que rexeita un número de secuencia que xa aceptou. Ningún dos tres implica os outros. Lea cada contador na capa que o produce antes de unilos nunha historia.
Tres contadores que nunca miden o mesmo evento
A anotación de retransmisión TCP significa que o emisor volveu poñer un rango de secuencia no cable. A perda é unha das razóns diso, e a captura que ten pode simplemente carecer do paquete orixinal ou da confirmación que explicaría o momento. Un ACK duplicado é o receptor repetindo unha confirmación acumulativa segundo as regras de recuperación de TCP, o que non é nin unha escritura duplicada da aplicación nin unha segunda copia dos datos.
ESP traballa no seu propio espazo de secuencia. Cada asociación de seguridade numera os paquetes que envía, e o receptor mantén unha xanela de números que xa aceptou, así que un paquete ESP que chega dúas veces descártase só por esas regras. Por iso un segmento TCP retransmitido viaxa nun paquete ESP novo cun número de secuencia novo, o que é o comportamento correcto en ambas as capas. Os mesmos bytes poden parecer novos nun contador e vellos noutro, e ningunha das dúas capas mente.
Que pode ver o analizador e que non
Empece polo vocabulario do analizador, porque os nomes dos filtros describen observacións e non o interior dos extremos. Contar cos mesmos nomes que usa a ferramenta mantéñeno honesto sobre o que se mediu realmente. Un reconto dunha captura incompleta é un reconto do que sobreviviu, non do que ocorreu no cable.
tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l
Lea a información de experto xunto a eses números, porque os avisos de suma de comprobación e de orde cambian canto peso merecen. Un rastro fusionado de dous sensores pode mostrar unha trama dúas veces, e contar ambas as copias inventa un evento de recuperación que nunca ocorreu.
Os contadores ESP viven no estado do núcleo
Os números de secuencia ESP pertencen á asociación de seguridade, non ao fluxo TCP, así que a pasarela é o lugar onde preguntar. O listado de estado informa contadores de paquetes e erros por asociación que ningunha captura pode reconstruír.
ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head
RFC 4303 define o número de secuencia e a xanela antirrepetición que o consome, e por iso o contador sobe mesmo cando nada vai mal. Os números de secuencia externos monótonos sen unha anomalía TCP correspondente apuntan a outro emisor ou a unha ruta duplicada máis que a unha tormenta de retransmisións. Unha captura externa dun túnel cifrado adoita ocultar os números de secuencia TCP internos, así que non pode demostrar que fixo a pila interna. Capture dentro do túnel só onde a política o permita, e nunca desactive a antirrepetición para silenciar un aviso non relacionado.
Onde o punto de observación cambia a resposta
Antes de escalar, anote como se tomou a captura: a interface, se o proceso de captura informou de perdas e se as marcas de tempo son comparables entre sensores. Un punto de observación non pode ver ambos os extremos dunha ruta, así que calquera afirmación sobre o comportamento do receptor é unha inferencia e non unha medición. Un rastro tomado na pasarela e un rastro tomado no host discreparán sobre a orde baixo carga, e esa discrepancia adoita pertencer á captura e non ao túnel. Correlacionar dúas vistas é o que converte un reconto en evidencia.
Use un fluxo de aplicación permitido e anote os contadores dos extremos xunto aos recontos da captura no mesmo momento. Se os números discrepan, confíe na capa que posúe o evento e trate a outra como un artefacto de observación ata que se demostre o contrario. Ese principio resolve a maioría destes casos sen tocar a configuración do túnel.
Ler os números na orde correcta
Empece pola capa onde se fixo a pregunta: un aviso TCP respóndese cunha captura TCP, e un descarte ESP respóndese cos contadores da asociación de seguridade na pasarela. Só entón pregunte se as dúas vistas describen o mesmo paquete. Unha conclusión que necesita ambas as capas debería nomear as dúas, porque unha afirmación sobre o túnel baseada só nunha anotación TCP é unha conxectura.
Anote a capa, o contador e o punto de observación de cada achado, e o seguinte lector non fusionará tres eventos nunha falla imaxinaria. Escale con eses tres campos e a corrección adoita seguir do primeiro.