TCP-hertransmissies versus IPsec-replay-verwerpingen: lees elke laag

Drie verschillende hulpmiddelen melden drie verschillende duplicaten, en slechts één daarvan is een netwerkgebeurtenis waarop u kunt ingrijpen. Een TCP-hertransmissie is een zender die een bereik opnieuw verstuurt, een dubbele ACK is een ontvanger die een bevestiging herhaalt, en een ESP-replay-verwerping is een beveiligingsassociatie die een volgnummer weigert dat zij al heeft geaccepteerd. Geen van de drie impliceert een van de andere. Lees elke teller op de laag die hem produceert voordat u ze tot één verhaal verbindt.

Drie tellers die nooit dezelfde gebeurtenis meten

De TCP-hertransmissie-annotatie betekent dat de zender een volgbereik opnieuw op de lijn heeft gezet. Verlies is een van de redenen daarvoor, en de opname die u hebt mist misschien gewoon het oorspronkelijke pakket of de bevestiging die de timing zou verklaren. Een dubbele ACK is de ontvanger die een cumulatieve bevestiging herhaalt volgens de TCP-herstelregels, wat noch een dubbele applicatieschrijfactie noch een tweede kopie van de gegevens is.

ESP werkt in zijn eigen volgnummerruimte. Elke beveiligingsassociatie nummert de pakketten die zij verstuurt, en de ontvanger houdt een venster bij van nummers die hij al heeft geaccepteerd, dus een ESP-pakket dat twee keer aankomt wordt alleen op die grond verworpen. Een opnieuw verzonden TCP-segment reist daarom in een nieuw ESP-pakket met een nieuw volgnummer, wat op beide lagen correct gedrag is. Dezelfde bytes kunnen in de ene teller nieuw lijken en in de andere oud, en geen van beide lagen liegt.

Wat de analysator wel en niet kan zien

Begin met het vocabulaire van de analysator, want de filternamen beschrijven waarnemingen en niet het inwendige van de eindpunten. Met dezelfde namen tellen als het hulpmiddel gebruikt, houdt u eerlijk over wat feitelijk is gemeten. Een telling uit een onvolledige opname is een telling van wat overleefde, niet van wat op de lijn gebeurde.

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

Lees de deskundige informatie naast die getallen, want waarschuwingen over controlesom en ordening veranderen hoeveel gewicht ze verdienen. Een samengevoegd spoor van twee sensoren kan één frame twee keer tonen, en beide kopieën tellen verzint een herstelgebeurtenis die nooit plaatsvond.

ESP-tellers leven in de kernelstatus

ESP-volgnummers horen bij de beveiligingsassociatie, niet bij de TCP-stroom, dus de gateway is de plek om te vragen. De statuslijst rapporteert pakket- en fouttellers per associatie die geen enkele opname kan reconstrueren.

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

RFC 4303 definieert het volgnummer en het anti-replay-venster dat het verbruikt, waardoor de teller stijgt zelfs wanneer er niets mis is. Monotone buitenste volgnummers zonder bijbehorende TCP-anomalie wijzen op een andere zender of een gedupliceerd pad in plaats van op een hertransmissiestorm. Een buitenste opname van een versleutelde tunnel verbergt gewoonlijk de binnenste TCP-volgnummers, dus kan niet bewijzen wat de binnenste stack deed. Maak alleen opnamen binnen de tunnel waar beleid dat toestaat, en schakel nooit anti-replay uit om een ongerelateerde waarschuwing te dempen.

Waar het waarnemingspunt het antwoord verandert

Voordat u escaleert, schrijft u op hoe de opname tot stand kwam: de interface, of het opnameproces verliezen meldde en of de tijdstempels tussen sensoren vergelijkbaar zijn. Eén waarnemingspunt kan niet beide uiteinden van een pad zien, dus elke uitspraak over het gedrag van de ontvanger is een gevolgtrekking en geen meting. Een spoor op de gateway en een spoor op de host zullen het onder belasting oneens zijn over de ordening, en die onenigheid hoort meestal bij de opname en niet bij de tunnel. Twee weergaven correleren is wat een telling in bewijs verandert.

Gebruik één toegestane applicatiestroom en noteer de tellers van de eindpunten naast de tellingen van de opname op hetzelfde moment. Als de getallen niet overeenkomen, vertrouw dan op de laag die de gebeurtenis bezit en behandel de andere als een waarnemingsartefact tot het tegendeel is bewezen. Die regel beslecht de meeste van deze gevallen zonder de tunnelconfiguratie aan te raken.

De getallen in de juiste volgorde lezen

Begin bij de laag waar de vraag is gesteld: een TCP-waarschuwing wordt beantwoord vanuit een TCP-opname, en een ESP-verwerping wordt beantwoord vanuit de tellers van de beveiligingsassociatie op de gateway. Vraag pas daarna of de twee weergaven hetzelfde pakket beschrijven. Een conclusie die beide lagen nodig heeft, moet beide noemen, want een bewering over de tunnel die alleen op een TCP-annotatie rust, is een gok.

Noteer de laag, de teller en het waarnemingspunt voor elke bevinding, en de volgende lezer zal drie gebeurtenissen niet tot één denkbeeldig defect samensmelten. Escaleer met die drie velden en de oplossing volgt meestal uit het eerste.