TCP-Reassembly-Tropfen verstehen

85734

Created On 09/25/18 19:21 PM - Last Modified 06/13/23 13:41 PM

Resolution

Dieses Dokument diskutiert ein gemeinsames Szenario bei der Fehlerbehebung von TCP-Wiederherstellung-Paketen

Hier ist eine Fallstudie, wo, ein Client, 172.22.136.50 versucht, mit einem Server 192.16.31.62 auf Ziel-Port 80 zu verbinden. Die Firewall ist mit dynamischer Adresse und Port-Übersetzung konfiguriert, aufgrund derer die SYN auf dem Empfangs-und der Sende Bühne unterschiedliche IP-und Portnummern zeigen, obwohl die IP-ID gleich bleibt.

Der Kunde schickt die SYN. Die Firewall empfängt die SYN, führt NAT durch und überträgt die SYN. Der Server empfängt das SYN und antwortet mit einem SYN-ACK. Die Firewall empfängt das SYN-ACK, de-NATs es und überträgt das Paket an den Client zurück. Der SYN-ACK macht es nie an den Client von der Firewall, und daher versucht der Client erneut, 4 weitere Male auf der gleichen Portnummer zu verbinden, bevor er versucht, eine Verbindung auf einer neuen Portnummer herzustellen.

Der erste Schnappschuss zeigt SYNs vom Client auf den Server, auf die Empfangs-, Firewall, Sende-und die Drop-Stadien (obwohl Drop-Stage keine Pakete hat) der Firewall. Der zweite Schnappschuss zeigt SYN-ACKs vom Server zum Client, wieder auf der Empfangs-, sende-, Firewall und den Drop-Stadien der Firewall.

a) der Client versucht zunächst, sich mit einem SYN-Paket mit den folgenden IP-und TCP-Werten mit dem Server zu verbinden:

S IP: 172.22.136.50, D IP: 192.16.31.62, Ip.Id 24915, src Port 44912, dest Port 80, Seq # 2033466733, ACK # 0

b) die Firewall empfängt das Paket und übersetzt die IP von 172.22.136.50 auf 198.180.162.5 und die Quell Ports von 44912 auf 21081, so dass die SYN-Pakete in der Sende Stufe die unten stehenden IP-und TCP-Werte haben.

S IP: 198.180.162.5, D IP: 192.16.31.62, IP.ID 24915 src Port 21081, dest Port 80, Seq # 2033466733, ACK # 0

c) der SYN erreicht schließlich den Server und der Server antwortet mit einem SYN-ACK. Der SYN-ACK, wenn er auf der Firewall empfangen wird, hat die folgenden IP-und TCP-Werte:

S IP: 192.16.31.62, D IP: 198.180.162.5, IP.ID 0, src Port 80, dest Port 21081, Seq # 743112262, ACK # 2033466734

d) die Firewall de-NATs the SYN-ACK und überträgt das Paket aus, mit den unten stehenden IP und TCP-Werten

S IP: 192.16.31.62, D IP: 172.22.136.50, IP.ID 0, src Port 80, dest Port 44912, Seq # 743112262, ACK # 2033466734

Avinash-Syn. JPG

Avinash-Dell-pcap-Analysis. jpg

Da der Client nie den SYN-ACK erhalten hat, versucht er 4 weitere Male auf der gleichen Quelle IP, Destination IP, Quell Port, Destination Port, Seq # und ACK #, bevor er schließlich aufgibt, und dann versucht, sich wieder auf eine neue Portnummer zu verbinden.

S IP: 172.22.136.50, D IP: 192.16.31.62, Ip.Id 24916, src Port 44912, dest Port 80, Seq # 2033466733, ACK # 0

S IP: 172.22.136.50, D IP: 192.16.31.62, Ip.Id 24917, src Port 44912, dest Port 80, Seq # 2033466733, ACK # 0

S IP: 172.22.136.50, D IP: 192.16.31.62, Ip.Id 24918, src Port 44912, dest Port 80, Seq # 2033466733, ACK # 0

S IP: 172.22.136.50, D IP: 192.16.31.62, Ip.Id 24919, src Port 44912, dest Port 80, Seq # 2033466733, ACK # 0

Der Server empfängt all diese SYNs und reagiert mit ihren SYN-ACKs auf all diese SYNs zurück. Ähnlich wie SYN haben auch die SYN-ACKs die gleiche Quelle IP, Destination IP, Quell Port, Destination Port, Seq # und ACK #.

S IP: 192.16.31.62, D IP: 198.180.162.5, IP.ID 0, src Port 80, dest Port 21081, Seq # 743112262, ACK # 2033466734

Es wird erwartet, dass Ip.Id 0 für SYN-ACKs. Das bedeutet nicht, dass das Paket fehl gebildet ist.

Nach den ersten 4 gescheiterten Versuchen überträgt der Server die SYN-ACKs weiter, aber jetzt auf einer anderen Sequenz #. IdealErweise wird eine Änderung des SEQ # im SYN-ACK für den Client keine Rolle spielen, da der Client nicht über den SEQ # des Servers Bescheid weiß (das SYN-Paket des Clients hat einen ACK # 0).

Wie in den Schnappschüssen gezeigt, überträgt der Server SYN-ACKs mit den folgenden IP-und TCP-Werten:

S IP: 192.16.31.62, D IP: 198.180.162.5, IP.ID 0, src Port 80, dest Port 21081, Seq # 883668401, ACK # 2033466734

Die Firewall empfängt diese SYN-ACKs und lässt Sie mit dem folgenden Zähler fallen:

tcp_drop_packet 2 0 warnen TCP pktproc-Pakete, die wegen des Ausfalls in TCP-Wiederherstellung fallen gelassen wurden

Der Grund für den Ausfall in TCP-Wiederherstellung kann verstanden werden, indem "TCP reass" zusammen mit den regulären filtern, Aufnahmen und Flow Basic ermöglicht wird.

> Debug-dataplane-Paket-Diag-Set-Log-Feature TCP
alle
fptcp fptcp
reass reass

> Debug-dataplane-Paket-Diag-Show-Setting

.....

Protokollierung
aktiviert: Ja
Log-throttle: kein
Sync-Log-by-Zecken: Ja
Features:
Flow: Basic
TCP: reass fptcp-
Zähler:

Die folgenden pan_packet_diag-Protokolle erklären, wie die TCP-vernünfttlich-Fehler die Packung fallen ließen

a) Protokolle der übermittelten SYN

= = 2015-09-01 13:21:45.170-0400 = =
Paket, das bei FastPath-Bühnen
Paket-info: len 74 Port 30 Interface 30 Vsys 1
wqe-Index 227771 Paket 0X0x80000004162190e6
Packet ENTSCHLÜSSELT Dump:
L2:70:81:05:.: 0x0800
IP: 172.22.136.50-> 192.16.31.62, Protokoll 6
Version 4, IHL 5, TOS 0x00, len 60,
ID 24915, frag_off 0x4000, TTL 60, Prüfsumme 51665
TCP: Sport 44912, dport 80, FF 2033466733, ACK 0,
reserviert 0, Offset 10, Fenster 5840, Prüfsumme 49659
Flaggen 0x0002 (SYN), dringende Daten 0
TCP Option:
00000000:02 04 05 B4 04 02 08 0A 99 03 5C 3E 00 00 00 00........ .. \>....
00000010:01 03 03 00....
Flow FastPath, Session 371381
NAT Session, Lauf Adresse/Port Translation
2015-09-01 13:21:45.171-0400 Debug: pan_tcp_reass (pan_reass. c:1999): reass: Arbeit 0x8000000418bcdd00 Session = 371381 Seqno = 2033466733 tcplen = 0 l4plen = 0 C2S Zustand 0
2015-09-01 13:21:45.171-0400 Debug: pan_tcp_tcb_init_base (pan_reass. c:612): SYN: C2S
2015-09-01 13:21:45.171-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:539): TCP MSS 1460
2015-09-01 13:21:45.171-0400 Debug: pan_tcp_parse_ options_syn (pan_reass. c:560): Sack erlaubt
2015-09-01 13:21:45.172-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:568): Ignorieren der TCP-Option 8
2015-09-01 13:21:45.172-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP Fenster Skala 0
SYN Cookie: pan_reass (init-Zustand): C2S: 0 C2S: nxtseq 2033466734 C2S: startseq 2033466734 C2S: Win 0 C2S: St 3 C2S: newsyn 0:: S2C: nxtseq 0 S2C: startseq 0 S2C: Win 5840 S2C: St 0 S2C: newsyn 0 ACK 0 nosyn 0
2015-09-01 13:21:45.172-0400 Debug : pan_tcp_reass (pan_reass. c:2484):
Session = 371381 Arbeit 0x8000000418bcdd00 Payload len 0, TCP Data len 0, ret 0
Spedition Lookup, eindrINgen Interface 30
L3 Mode, Virtual-Router 2
Route Lookup in Virtual-Router 2, IP 192.16.31.62

b) "Lessing" durch die pan_packet_diag Logs, stoßen wir auf das erste SYN-ACK, das von der Firewall empfangen wird.

Der fireawall empfängt diesen SYN-ACK auf der schnell Pfad-Bühne und wertet das nächste Paket aus, das er in der C2S-Richtung erwartet, also Paket mit einemSEQ # 2033466734(typischerweise das ACK-Paket vom Client). Ebenso ist das nächste Paket, das es von der S2C-Richtung erwartet, eines mit dem SEQ # 743112263. Nach Auswertung dieser Bedingungen überträgt die Firewall das Paket aus.

= = 2015-09-01 13:21:45.173-0400 = =
Paket, das bei FastPath Stage
Paket info: len 66 Port 28 Interface 28 Vsys 0
wqe Index 224088 Paket 0x0x8000000416faf0e6
Packet entschlüsselt Dump:
L2: B4:14:89:85:4E: 43-> 00:1B: 17:00:04:1C, Type 0x0800
IP: 192.16.31.62-> 198.180.162.5, Protokoll 6
Version 4, IHL 5, TOS 0x08, len 52,
ID 0, frag_off 0x4000, TTL 57, Prüfsumme 63923
TCP: Sport 80, dport 21081, FF743112262,ACK2033466734,
reserviert 0, Offset 8, Fenster 14600, Prüfsumme 47633,
Fahnen 0x0012 (SYN ACK), dringende Daten 0
TCP Option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09....... . ....
Flow FastPath, Session 371381
NAT Session, Lauf Adresse/Port Translation
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_reass (pan_reass. c:1999): reass: Arbeit 0x8000000418b5ab80 Session = 371381 Seqno = 743112262 tcplen = 0 l4plen = 0 S2C Zustand 0
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_tcb_init_base (pan_reass. c:612): SYN: S2C
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:539): TCP MSS 1460
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_parse_ options_syn (pan_reass. c:560): Sack erlaubt
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP-Fenster Skala 9
SYN Cookie: Pan_reass (init-Zustand): C2S: 1 C2S: nxtseq2033466734C2S: startseq 2033466734 C2S: Win 14600 C2S: St 3 C2S: newsyn 0:: S2C: nxtseq743112263S2C: startseq 743112263 S2C: Win 5840 S2C: St 3 S2C: newsyn 0 ACK2033466734nosyn 0
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_tcb_upd_state (pan_reass. c:783 ): TCP State = 1 Prev = 3
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_reass (pan_reass. c:2484):
Session = 371381 Arbeit 0x8000000418b5ab80 Payload len 0, TCP Data len 0, ret 0
Spedition Lookup, eIndringen Interface 28
L3 Mode, Virtual-Router 2
Route Lookup in Virtual-Router 2, IP 172.22.136.50
Route gefunden, Interface Ethernet1/15, Zone 8, nexthop 10.174.62.17
lösen ARP für IP-10.174.62.17 auf Interface ETHERNET1/15
ARP-Eintrag auf Interface 30 über
tragen Paket auf Port gefunden 30.

c) die Firewall erhält auch nachfolgende 3 wieder übertragene SYN-ACK-Pakete mit dem SEQ # 743112262 und dem ACK # 2033466734 und überträgt sie aus.

= = 2015-09-01 13:21:46.169-0400 = =
Paket, das bei FastPath-Bühnen
Paket info: len 66 Port 28 Interface 28 Vsys 0
wqe Index 222187 Paket 0x0x80000004162018e6
Packet entschlüsselt Dump:
L2: B4:14:89:85:4E: 43-> 00:1B: 17:00:04: 0x0800
IP: 192.16.31.62-> 198.180.162.5, Protokoll 6
Version 4, IHL 5, TOS 0x08, len 52,
ID 0, frag_off 0x4000, TTL 57, Prüfsumme 63923
TCP: Sport 80, dport 21081,FF 743112262, ACK 2033466734,
reserviert 0, Offset 8, Fenster 14600 Prüfsumme 47633,
Flags 0x0012 (SYN ACK), dringende Daten 0
TCP Option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09....... . ....
Flow FastPath, Session 371381
NAT Session, Lauf Adresse/Port Translation
2015-09-01 13:21:46.169-0400 Debug: pan_tcp_reass (pan_reass. c:1999): reass: Arbeit 0x8000000418b1f500 Session = 371381 Seqno = 743112262 tcplen = 0 l4plen = 0 S2C Zustand 1
2015-09-01 13:21:46.169-0400 Debug: pan_tcp_tcb_init_base (pan_reass. c:612): SYN: S2C
2015-09-01 13:21:46.169-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:539): TCP MSS 1460
2015-09-01 13:21:46.169-0400 Debug: pan_tcp_parse_ options_syn (pan_reass. c:560): Sack erlaubt
2015-09-01 13:21:46.170-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP Window Scale 9
SYN Cookie: pan_reass (New SYN): C2S: 1C2S: nxtseq 2033466734C2S: startseq 2033466734 C2S: Win 14600 C2S: St 3 C2S: newsyn 0::S2C: nxtseq 743112263S2C: startseq 743112263 S2C: Win 5840 S2C: St 1 S2C: newsyn 0 ACK 2033466734 nosyn 0
2015-09-01 13:21:46.170-0400 Debug: pan_tcp_reass (pan_reass. c:2484):
Session = 371381 work 0x8000000418b1f500 Payload len 0, TCP Data len 0, ret 0
Spedition Lookup, Eindringen Interface 28
L3 Mode, Virtual-Router 2
Route Lookup in Virtual-Router 2, IP 172.22.136.50
Route gefunden, Interface Ethernet1/15, Zone 8, nexthop 10.174.62.17
Lösen Sie ARP für IP-10.174.62.17 auf Interface Ethernet1/15
ARP-Eintrag auf Interface 30 über
tragen Paket auf Port 30
-------------------------------------------
= = 2015-09-01 13:21:48.169-0400 = =
Paket erhalten bei FastPath Bühnen
Paket info: len 66 Port 28 Interface 28 Vsys 0
wqe Index 227536 Paket 0x0x8000000416e7e8e6
Packet entschlüsselt Dump:
L2: B4:14:89:85:4E: 43-> 00:1B: 17:00:04:1C, Type 0x0800
IP: 192.16.31.62-> 198.180.162.5, Protokoll 6
Version 4, IHL 5, TOS 0x08, len 52,
ID frag_off 0x4000, TTL 57, Prüfsumme 63923
TCP: Sport 80, dport 21081,FF 743112262, ACK 2033466734,
reserviert 0, Offset 8, Fenster 14600, Prüfsumme 47633,
Flags 0x0012 (SYN ACK), dringende Daten 0
TCP Option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09........ ....
Flow FastPath, Session 371381
NAT Session, Lauf Adresse/Port Translation
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_reass (pan_reass. c:1999): reass: Arbeit 0x8000000418bc6780 Session = 371381 Seqno = 743112262 tcplen = 0 l4plen = 0 S2C Zustand 1
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_tcb_init_base (pan_reass. c:612): SYN: S2C
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:539): TCP MSS 1460
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_parse_ options_syn (pan_reass. c:560): Sack erlaubt
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP Window Scale 9
SYN Cookie: pan_reass (New SYN): C2S: 1C2S: nxtseq 2033466734C2S: startseq 2033466734 C2S: Win 14600 C2S: St 3 C2S: newsyn 0::S2C: nxtseq 743112263S2C: startseq 743112263 S2C: Win 5840 S2C: St 1 S2C: newsyn 0 ACK 2033466734 nosyn 0
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_reass (pan_reass. c:2484):
Session = 371381 work 0x8000000418bc6780 Payload len 0, TCP Data len 0, ret 0
Spedition Lookup, Eindringen Interface 28
L3 Mode, Virtual-Router 2
Route Lookup in Virtual-Router 2, IP 172.22.136.50
Route gefunden, Interface Ethernet1/15, Zone 8, nexthop 10.174.62.17
Lösen Sie ARP für IP-10.174.62.17 auf Interface Ethernet1/15
ARP-Eintrag auf Interface 30 über
tragen Paket auf Port 30
------------------------------------------

= = 2015-09-01 13:21:48.170-0400 = =
Paket, das auf dem FastPath-Bühnen
Paket info: len 66 Port 28 Interface 28 Vsys 0
wqe Index 226639 Paket 0x0x8000000416a288e6
Packet entschlüsselt Dump: L2: B4:17::
04:4E: 43-> 00:1B: 0x0800
IP: 192.16.31.62-> 198.180.162.5, Protokoll 6
Version 4, IHL 5, TOS 0x08, len 52,
ID 0, frag_off 0x4000, TTL 57, Prüfsumme 63923
TCP: Sport 80, dport 21081,FF 743112262, ACK 2033466734,
reserviert 0, Offset 8, Fenster 14600 Prüfsumme 47633,
Flags 0x0012 (SYN ACK), dringende Daten 0
TCP Option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09....... . ....
Flow FastPath, Session 371381
NAT Session, Lauf Adresse/Port Translation
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_reass (pan_reass. c:1999): reass: Arbeit 0x8000000418baa700 Session = 371381 Seqno = 743112262 tcplen = 0 l4plen = 0 S2C Zustand 1
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_tcb_init_base (pan_reass. c:612): SYN: S2C
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:539): TCP MSS 1460
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_parse_ options_syn (pan_reass. c:560): Sack erlaubt
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP Window Scale 9
SYN Cookie: pan_reass (New SYN): C2S: 1C2S: nxtseq 2033466734C2S: startseq 2033466734 C2S: Win 14600 C2S: St 3 C2S: newsyn 0::S2C: nxtseq 743112263S2C: startseq 743112263 S2C: Win 5840 S2C: St 1 S2C: newsyn 0 ACK 2033466734 nosyn 0
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_reass (pan_reass. c:2484):
Session = 371381 work 0x8000000418baa700 Payload len 0, TCP Data len 0, ret 0
Spedition Lookup, Eindringen Interface 28
L3 Mode, Virtual-Router 2
Route Lookup in Virtual-Router 2, IP 172.22.136.50
Route gefunden, Interface Ethernet1/15, Zone 8, nexthop 10.174.62.17
Lösen Sie ARP für IP-10.174.62.17 auf Interface Ethernet1/15
ARP-Eintrag auf Interface 30 über
tragen Paket auf Port 30

d) Wenn die Firewall den nächsten Satz von SYN-ACKs vom Server mit dem geändertenSEQ # 883668401 empfängt, lässt Sie das Paket fallen. Dies ist ein erwartetes Verhalten, denn während die Firewall auf das TCP-Handshake-Timeout von 10 Sekunden wartet (maximale Zeitspanne zwischen dem Empfang des SYN-ACK und dem anschließenden ACK, um die Session vollständig zu etablieren), behielt Sie den Überblick über den nächsten erwarteten SEQ # vom Server Seite als 743112263, erhielt aber ein Paket mit demSEQ # 883668401. Dieses Missverhältnis im SEQ # bewirkt, dass die Firewall das Paket fallen lässt. Ebenso werden alle nachfolgenden Pakete mit dem Seq # 883668401 durch die Pfanne fallen gelassen.

= = 2015-09-01 13:21:54.169-0400 = =
Paket, das bei FastPath-Bühnen
Paket info: len 66 Port 28 Interface 28 Vsys 0
wqe Index 222256 Paket 0x0x80000004165330e6
Packet entschlüsselt Dump:
L2: B4:14:89:85:4E: 43-> 00:1B: 17:00:04: 0x0800
IP: 192.16.31.62-> 198.180.162.5, Protokoll 6
Version 4, IHL 5, TOS 0x08, len 52,
ID 0, frag_off 0x4000, TTL 57, Prüfsumme 63923
TCP: Sport 80, dport 21081,FF 883668401, ACK 2033466734,
reserviert 0, Offset 8, Fenster 14600 Prüfsumme 64069,
Flags 0x0012 (SYN ACK), dringende Daten 0
TCP Option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09....... . ....
Flow FastPath, Session 371381
NAT Session, Lauf Adresse/Port Translation
2015-09-01 13:21:54.169-0400 Debug: pan_tcp_reass (pan_reass. c:1999): reass: Arbeit 0x8000000418b21780 Session = 371381 Seqno = 883668401 tcplen = 0 l4plen = 0 S2C Zustand 1
2015-09-01 13:21:54.169-0400 Debug: pan_tcp_reass (pan_reass. c:2074): REASS: Session = 371381Seqno = 883668401rcv_nxt = 743112263neue Verbindung
2015-09-01 13:21:54.169-0400 Debug: pan_tcp_reass (pan_reass. c:2090): Sequenznummer in SYN_ACK nicht konsistent (aktuell + 1 883668402 vs start_seq 743112263),Drop
2015-09-01 13:21:54.169-0400 Debug: pan_tcp_reass (pan_reass. c:2484):
Session = 371381 work 0x8000000418b21780 Nutzlast len 0, TCP Data len 0 ,ret 2
TCP Wiederherstellung failed: ret 2

TCP-Reassembly-Tropfen verstehen

Resolution

Other users also viewed: