TCP-omsändningar mot IPsec-replay-avvisningar: läs varje lager

Tre olika verktyg rapporterar tre olika dubbletter, och bara en av dem är en nätverkshändelse du kan agera på. En TCP-omsändning är en avsändare som skickar ett intervall igen, en duplicerad ACK är en mottagare som upprepar en bekräftelse, och en ESP-replay-avvisning är en säkerhetsassociation som avvisar ett sekvensnummer den redan har accepterat. Ingen av de tre förutsätter någon av de andra. Läs varje räknare på det lager som producerar den, innan du knyter ihop dem till en historia.

Tre räknare som aldrig mäter samma händelse

TCP-omsändningsmarkeringen betyder att avsändaren återigen lade ett sekvensintervall på ledningen. Förlust är en av orsakerna, och den inspelning du har saknar kanske bara det ursprungliga paketet eller bekräftelsen som skulle förklara tidsangivelsen. En duplicerad ACK är mottagaren som upprepar en kumulativ bekräftelse enligt TCP:s återställningsregler, vilket varken är en duplicerad applikationsskrivning eller en andra kopia av data.

ESP arbetar i sitt eget sekvensutrymme. Varje säkerhetsassociation numrerar paketen den skickar, och mottagaren håller ett fönster av nummer som redan accepterats, så ett ESP-paket som anländer två gånger kastas enbart på den grunden. Ett omsänt TCP-segment färdas därför i ett nytt ESP-paket med ett nytt sekvensnummer, vilket är korrekt beteende på båda lagren. Samma byte kan se nya ut i en räknare och gamla ut i en annan, och ingen av lagren ljuger.

Vad analyzern kan och inte kan se

Börja med analyzerns ordförråd, eftersom filternamnen beskriver observationer och inte det inre hos ändpunkterna. Att räkna med samma namn som verktyget använder håller dig ärlig om vad som faktiskt mättes. En räkning från en ofullständig inspelning är en räkning av det som överlevde, inte av det som hände på ledningen.

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

Läs expertinformationen bredvid siffrorna, eftersom varningar om kontrollsumma och ordning ändrar hur mycket vikt de förtjänar. Ett sammanslaget spår från två sensorer kan visa en ram två gånger, och att räkna båda kopiorna hittar på en återställningshändelse som aldrig inträffade.

ESP-räknare bor i kärntillståndet

ESP-sekvensnummer tillhör säkerhetsassociationen, inte TCP-strömmen, så gatewayen är platsen att fråga. Tillståndslistan rapporterar paket- och felräknare per association som ingen inspelning kan rekonstruera.

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

RFC 4303 definierar sekvensnummeret och anti-replay-fönstret som förbrukar det, och därför stiger räknaren även när inget är fel. Monotona yttre sekvensnummer utan en motsvarande TCP-anomali pekar på en annan avsändare eller en duplicerad väg snarare än på en omsändningsstorm. En yttre inspelning av en krypterad tunnel döljer vanligtvis de inre TCP-sekvensnumren, så den kan inte bevisa vad den inre stacken gjorde. Spela bara in inne i tunneln där policyn tillåter det, och slå aldrig av anti-replay för att tysta en orelaterad varning.

Där observationspunkten ändrar svaret

Innan du eskalerar, skriv ner hur inspelningen gjordes: gränssnittet, om inspelningsprocessen rapporterade förluster och om tidsstämplarna är jämförbara mellan sensorer. En observationspunkt kan inte se båda ändarna av en väg, så varje uttalande om mottagarens beteende är en slutsats och inte en mätning. Ett spår taget på gatewayen och ett spår taget på värden kommer att vara oense om ordningen under belastning, och den oenigheten tillhör vanligtvis inspelningen och inte tunneln. Att korrelera två vyer är det som gör en räkning till bevis.

Använd ett tillåtet applikationsflöde och notera ändpunkternas räknare bredvid inspelningens siffror i samma ögonblick. Om siffrorna inte stämmer, lita på lagret som äger händelsen och behandla det andra som en observationseffekt tills motsatsen bevisats. Den regeln avgör de flesta av dessa ärenden utan att röra tunnelkonfigurationen.

Att läsa siffrorna i rätt ordning

Börja på lagret där frågan ställdes: en TCP-varning besvaras från en TCP-inspelning, och en ESP-avvisning besvaras från säkerhetsassociationens räknare på gatewayen. Först då frågar du om de två vyerna beskriver samma paket. En slutsats som behöver båda lagren bör nämna båda, eftersom ett påstående om tunneln som vilar enbart på en TCP-markering är en gissning.

Notera lagret, räknaren och observationspunkten för varje fynd, och nästa läsare kommer inte att smälta samman tre händelser till ett inbillat fel. Eskalera med de tre fälten, och rättelsen följer vanligtvis från det första.