TCP-gentransmissioner kontra IPsec-genafspilningsafvisninger: læs hvert lag

Tre forskellige værktøjer rapporterer tre forskellige dubletter, og kun én af dem er en netværkshændelse, du kan handle på. En TCP-gentransmission er en afsender, der sender et område igen, en duplikeret ACK er en modtager, der gentager en bekræftelse, og et ESP-genafspilningsdrop er en sikkerhedsassociation, der afviser et sekvensnummer, den allerede har accepteret. Ingen af de tre forudsætter nogen af de andre. Læs hver tæller på det lag, der producerer den, før du forbinder dem til en historie.

Tre tællere, der aldrig måler den samme hændelse

TCP-gentransmissionsmarkeringen betyder, at afsenderen igen har lagt et sekvensområde på ledningen. Tab er en af grundene til det, og den optagelse, du har, mangler måske bare den oprindelige pakke eller den bekræftelse, der ville forklare timingen. En duplikeret ACK er modtageren, der gentager en kumulativ bekræftelse efter TCP-genopretningsreglerne, hvilket hverken er en duplikeret applikationsskrivning eller en anden kopi af dataene.

ESP arbejder i sit eget sekvensrum. Hver sikkerhedsassociation nummererer de pakker, den sender, og modtageren holder et vindue af numre, den allerede har accepteret, så en ESP-pakke, der ankommer to gange, kasseres alene på det grundlag. Et gensendt TCP-segment rejser derfor i en ny ESP-pakke med et nyt sekvensnummer, hvilket er korrekt adfærd på begge lag. De samme bytes kan se nye ud i én tæller og gamle ud i en anden, og ingen af lagene lyver.

Hvad analysatoren kan og ikke kan se

Begynd med analysatorens ordforråd, fordi filternavnene beskriver observationer frem for endepunkternes indre. At tælle med de samme navne, som værktøjet bruger, holder dig ærlig om, hvad der faktisk blev målt. Et tal fra en ufuldstændig optagelse er et tal for det, der overlevede, ikke for det, der skete 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 ekspertinformationen ved siden af tallene, fordi advarsler om kontrolsum og rækkefølge ændrer, hvor meget vægt de fortjener. Et sammenflettet spor fra to sensorer kan vise én ramme to gange, og at tælle begge kopier opfinder en genopretningshændelse, der aldrig skete.

ESP-tællere bor i kernetilstanden

ESP-sekvensnumre tilhører sikkerhedsassociationen, ikke TCP-strømmen, så gatewayen er stedet at spørge. Tilstandsoversigten rapporterer pakke- og fejltællere per association, som ingen optagelse kan rekonstruere.

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

RFC 4303 definerer sekvensnummeret og det anti-genafspilningsvindue, der forbruger det, og derfor stiger tælleren, selv når intet er galt. Monotone ydre sekvensnumre uden en tilsvarende TCP-anomali peger på en anden afsender eller en duplikeret rute frem for på en gentransmissionsstorm. En ydre optagelse af en krypteret tunnel skjuler normalt de indre TCP-sekvensnumre, så den kan ikke bevise, hvad den indre stak gjorde. Optag kun inde i tunnelen, hvor politikken tillader det, og slå aldrig anti-genafspilning fra for at gøre en irrelevant advarsel tavs.

Hvor observationspunktet ændrer svaret

Før du eskalerer, skriv ned, hvordan optagelsen blev lavet: grænsefladen, om optagelsesprocessen rapporterede tab, og om tidsstemplerne er sammenlignelige på tværs af sensorer. Et observationspunkt kan ikke se begge ender af en rute, så enhver udtalelse om modtagerens adfærd er en slutning, ikke en måling. Et spor taget på gatewayen og et spor taget på værten vil være uenige om rækkefølgen under belastning, og den uenighed tilhører normalt optagelsen frem for tunnelen. At korrelere to visninger er det, der gør et tal til bevis.

Brug én tilladt applikationsstrøm og notér endepunkternes tællere ved siden af optagelsens tal i samme øjeblik. Hvis tallene er uenige, tro på det lag, der ejer hændelsen, og behandl det andet som en observationsartefakt, indtil det modsatte er bevist. Den regel afgør de fleste af disse sager uden at røre tunnelkonfigurationen.

At læse tallene i den rigtige rækkefølge

Begynd ved det lag, hvor spørgsmålet blev stillet: en TCP-advarsel besvares ud fra en TCP-optagelse, og et ESP-drop besvares ud fra sikkerhedsassociationens tællere på gatewayen. Spørg først derefter, om de to visninger beskriver den samme pakke. En konklusion, der kræver begge lag, bør nævne begge, fordi en påstand om tunnelen, der hviler på en TCP-markering alene, er et gæt.

Notér laget, tælleren og observationspunktet for hver fund, og den næste læser vil ikke smelte tre hændelser sammen til én indbildt fejl. Eskaler med de tre felter, og rettelsen følger normalt af det første.