Opakované přenosy TCP versus zahazování opakování IPsec: čtěte každou vrstvu

Tři různé nástroje hlásí tři různé duplikáty a jen jeden z nich je síťová událost, se kterou můžete něco dělat. Opakovaný přenos TCP je odesílatel, který znovu posílá rozsah, duplicitní ACK je příjemce, který opakuje potvrzení, a zahození opakování ESP je bezpečnostní asociace, která odmítá pořadové číslo, jež už přijala. Žádné ze tří nevyplývá z ostatních. Čtěte každý čítač na vrstvě, která ho vytváří, než je spojíte do jednoho příběhu.

Tři čítače, které nikdy neměří stejnou událost

Anotace opakovaného přenosu TCP znamená, že odesílatel znovu položil rozsah sekvence na drát. Ztráta je jedním z důvodů a zachycený záznam, který máte, může prostě postrádat původní paket nebo potvrzení, které by vysvětlilo časování. Duplicitní ACK je příjemce, který opakuje kumulativní potvrzení podle pravidel obnovy TCP, což není ani duplicitní zápis aplikace, ani druhá kopie dat.

ESP pracuje ve vlastním sekvenčním prostoru. Každá bezpečnostní asociace čísluje pakety, které odesílá, a příjemce udržuje okno čísel, která už přijal, takže ESP paket, který dorazí dvakrát, je zahozen jen na základě těchto pravidel. Opakovaně odeslaný TCP segment proto putuje v novém ESP paketu s novým pořadovým číslem, což je správné chování na obou vrstvách. Stejné bajty mohou vypadat nově v jednom čítači a starě v jiném a ani jedna vrstva nelže.

Co analyzátor vidí a co ne

Začněte slovníkem analyzátoru, protože názvy filtrů popisují pozorování, nikoli vnitřek koncových bodů. Počítání se stejnými názvy, které nástroj používá, vás udrží poctivými v tom, co bylo skutečně změřeno. Počet z neúplného záznamu je počet toho, co přežilo, ne toho, co se stalo na drátě.

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

Čtěte expertní informace vedle těch čísel, protože varování ke kontrolnímu součtu a pořadí mění, jakou váhu si zaslouží. Sloučený záznam ze dvou senzorů může ukázat jeden rámec dvakrát a počítání obou kopií vymýšlí událost obnovy, která se nikdy nestala.

Čítače ESP žijí ve stavu jádra

Pořadová čísla ESP patří bezpečnostní asociaci, ne TCP toku, takže brána je místo, kde se ptát. Výpis stavu uvádí čítače paketů a chyb pro každou asociaci, které žádný záznam nedokáže rekonstruovat.

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

RFC 4303 definuje pořadové číslo a okno proti opakování, které ho spotřebovává, a proto čítač roste, i když není nic špatně. Monotónní vnější pořadová čísla bez odpovídající TCP anomálie ukazují na jiného odesílatele nebo duplikovanou cestu, nikoli na bouři opakovaných přenosů. Vnější záznam šifrovaného tunelu obvykle skrývá vnitřní pořadová čísla TCP, takže nemůže dokázat, co vnitřní zásobník udělal. Zaznamenávejte uvnitř tunelu jen tam, kde to politika dovoluje, a nikdy nevypínejte ochranu proti opakování, abyste umlčeli nesouvisející varování.

Kde pozorovací bod mění odpověď

Před eskalací zapište, jak byl záznam pořízen: rozhraní, zda proces záznamu hlásil ztráty a zda jsou časové značky mezi senzory srovnatelné. Jeden pozorovací bod nevidí oba konce cesty, takže každé tvrzení o chování příjemce je odvození, nikoli měření. Záznam pořízený na bráně a záznam pořízený na hostiteli se budou v pořadí při zátěži rozcházet a tento rozpor obvykle patří záznamu, ne tunelu. Korelace dvou pohledů je to, co mění počítání v důkaz.

Použijte jeden povolený aplikační tok a poznamenejte čítače koncových bodů vedle počtů ze záznamu ve stejný okamžik. Pokud se čísla rozcházejí, věřte vrstvě, která událost vlastní, a druhou považujte za artefakt pozorování, dokud se neprokáže opak. Toto pravidlo vyřeší většinu těchto případů, aniž by se sahlo na konfiguraci tunelu.

Čtení čísel ve správném pořadí

Začněte vrstvou, kde byla otázka položena: na varování TCP se odpovídá ze záznamu TCP a na zahození ESP se odpovídá z čítačů bezpečnostní asociace na bráně. Teprve potom se ptejte, zda oba pohledy popisují stejný paket. Závěr, který potřebuje obě vrstvy, má jmenovat obě, protože tvrzení o tunelu opírající se jen o anotaci TCP je dohad.

Zaznamenejte vrstvu, čítač a pozorovací bod u každého zjištění a další čtenář nespojí tři události v jednu vymyšlenou závadu. Eskalujte s těmito třemi poli a oprava obvykle vyplyne z prvního.