Présentation des gouttes de remontage TCP

85746

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

Resolution

Ce document traite d'un scénario commun lors du dépannage des gouttes de paquets de remontage TCP

Voici une étude de cas où, un client, 172.22.136.50 tente de se connecter à un serveur 192.16.31.62 sur le port de destination 80. Le pare-feu est configuré avec l'adresse dynamique et la traduction de port, en raison de laquelle le SYN sur la réception et l'étape de transmission montrent différents numéros d'IP et de port, bien que l'ID IP reste le même.

Le client envoie le SYN. Le pare-feu reçoit le syn, exécute NAT et transmet le syn. Le serveur reçoit le SYN et répond avec un SYN-ACK. Le pare-feu reçoit le SYN-ACK, le dé-NAT et transmet le paquet de nouveau au client. Le SYN-ACK ne le fait jamais au client à partir du pare-feu, et par conséquent le client tente de se connecter 4 fois plus sur le même numéro de port, avant de tenter d'établir une connexion sur un nouveau numéro de port.

Le premier instantané montre syn du client au serveur, sur les étapes de réception, de pare-feu, de transmission et de chute (bien que Drop stage n'ait pas de paquets) du pare-feu. Le deuxième instantané montre SYN-accusés du serveur au client, encore une fois sur la réception, transmettre, pare-feu et les étapes de chute du pare-feu.

a) le client tente d'abord de se connecter au serveur avec un paquet SYN avec les valeurs IP et TCP ci-dessous:

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) le pare-feu reçoit le paquet, et traduit l'ip de 172.22.136.50 à 198.180.162.5 et les ports source de 44912 à 21081, de sorte que les paquets SYN à l'étape de transmission ont les valeurs ci-dessous IP et TCP

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) le SYN atteint éventuellement le serveur et le serveur répond avec un SYN-ACK. Le SYN-ACK Lorsqu'il est reçu sur le pare-feu ont les valeurs IP et TCP ci-dessous:

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) le pare-feu de-nat le SYN-ACK et transmet le paquet, avec les valeurs ci-dessous IP et TCP

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

Étant donné que le client n'a jamais reçu le SYN-ACK, il retente 4 fois plus sur la même adresse IP source, IP de destination, port source, port de destination, Seq # et ACK # avant de finalement abandonner, puis de tenter de se connecter à nouveau sur un nouveau numéro de port.

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

Le serveur reçoit tous ces syn et répond de nouveau à tous ces syn avec leur SYN-accusés. À l'inStar de SYN, le SYN-accusés a également la même adresse IP source, IP de destination, port source, port de destination, Seq # et 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

On s'attend à voir Ip.Id 0 pour SYN-accusés. Cela ne signifie pas que le paquet est mal formé.

Après les 4 premières tentatives échouées, le serveur continue à retransmettre le syn-accusés, mais maintenant sur une séquence différente #. Idéalement, un changement de Seq # dans le SYN-ACK n'aura pas d'importance pour le client, car le client ne connaît pas encore le SEQ # du serveur (le paquet SYN du client a un ACK # 0).

Comme indiqué dans les instantanés, le serveur retransmet syn-accusés avec les valeurs IP et TCP ci-dessous:

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

Le pare-feu reçoit ces SYN-accusés et les supprime avec le compteur ci-dessous:

tcp_drop_packet 2 0 WARN TCP pktproc paquets supprimés en raison de l'échec dans le remontage TCP

La raison de l'échec dans le remontage TCP peut être comprise en activant "TCP REASS", avec les filtres réguliers, captures et flux de base.

> Debug dataplane Packet-diag Set log Feature TCP
tous tous
fptcp fptcp
REASS REASS

> Debug dataplane paquet-diag Show Setting

.....

Enregistrement
activé: oui
log-Throttle: pas
de synchronisation-log-by-Ticks: oui
caractéristiques:
Flow: Basic
TCP: REASS fptcp
compteurs:

Les journaux ci-dessous pan_packet_diag expliquer comment les échecs TCP reassebly causé le paquet gouttes

a) journaux de la SYN transmis

= = 2015-09-01 13:21:45.170-0400 = =
paquet reçu à FastPath étape
info paquet: Len 74 port 30 interface 30 VSys 1
wQE index 227771 Packet 0x0x80000004162190e6 paquet
décodé dump:
L2:70:81:05: EC: D4:3F-> 00:1b: 17:00:04:1e, type 0x0800
IP: 172.22.136.50-> 192.16.31.62, Protocol 6
version 4, DIH 5, TOS 0x00, Len 60,
ID 24915, frag_off 0x4000, TTL 60, checksum 51665
TCP: sport 44912, dport 80, Seq 2033466733, ACK 0,
réservé 0, offset 10, Window 5840, checksum 49659,
Flags 0x0002 (SYN), données urgentes 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, exécuter adresse/port translation
2015-09-01 13:21:45.171-0400 Debug: pan_tcp_reass (pan_reass. c:1999): REASS: Work 0x8000000418bcdd00 session = 371381 seqno = 2033466733 tcplen = 0 l4plen = 0 C2S État 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 autorisé
2015-09-01 13:21:45.172-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:568): ignorer TCP option 8
2015-09-01 13:21:45.172-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP Echelle de fenêtre 0
syn cookie: pan_reass (init State): 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 travail 0x8000000418bcdd00 charge utile Len 0, TCP données Len 0, RET 0
recherche de transfert, Ingres interface 30
mode L3, Virtual-Router 2
recherche d'itinéraire dans Virtual-Router 2, IP 192.16.31.62

b) «moins» à travers les journaux pan_packet_diag, nous avons rencontré le premier SYN-ACK reçu par le pare-feu.

Le fireawall reçoit ce SYN-ACK à l'étape du chemin d'accès rapide et évalue le prochain paquet qu'il attend dans la direction C2S, à savoir le paquet avec unSeq # 2033466734(généralement le paquet ACK du client). De même, le prochain paquet qu'il attend de la direction S2C est un avec le Seq # 743112263. Après l'évaluation de ces conditions, le pare-feu transmet le paquet.

= = 2015-09-01 13:21:45.173-0400 = =
paquet reçu à FastPath étape
info paquet: Len 66 port 28 interface 28 VSys 0
wQE index 224088 Packet 0x0x8000000416faf0e6 paquet
décodé 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, Protocol 6
version 4, DIH 5, TOS 0x08, Len 52,
ID 0, frag_off 0x4000, TTL 57, checksum 63923
TCP: sport 80, dport 21081, Seq743112262,ACK2033466734,
Reserved 0, offset 8, Window 14600, checksum 47633,
Flags 0x0012 (SYN ACK), données urgentes 0
TCP option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09........ ....
Flow FastPath, session 371381
NAT session, exécuter adresse/port translation
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_reass (pan_reass. c:1999): REASS: Work 0x8000000418b5ab80 session = 371381 seqno = 743112262 tcplen = 0 l4plen = 0 S2C État 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 permis
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP window Echelle 9
syn cookie: Pan_reass (init State): 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 ): État TCP = 1 PREV = 3
2015-09-01 13:21:45.173-0400 Debug: pan_tcp_reass (pan_reass. c:2484):
session = 371381 Work 0x8000000418b5ab80 charge utile Len 0, TCP Data Len 0, RET 0
retransmission Lookup, Ingres interface 28
L3 mode, Virtual-Router 2
Recherche D'itinéraire dans Virtual-Router 2, IP 172.22.136.50
route trouvée, interface ethernet1/15, zone 8, nexthop 10.174.62.17
résoudre ARP pour IP 10.174.62.17 sur l'interface ETHERNET1/15
ARP entrée trouvée sur l'interface 30
transmettre paquet sur le port 30.

c) le pare-feu reçoit par la suite 3 paquets SYN-ACK retransmis avec les SEQ # 743112262 et ACK # 2033466734, et les transmet.

= = 2015-09-01 13:21:46.169-0400 = =
paquet reçu à FastPath étape
info paquet: Len 66 port 28 interface 28 VSys 0
wQE index 222187 Packet 0x0x80000004162018e6 paquet
décodé 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, Protocol 6
version 4, DIH 5, TOS 0x08, Len 52,
ID 0, frag_off 0x4000, TTL 57, checksum 63923
TCP: sport 80, dport 21081,Seq 743112262, ACK 2033466734,
Reserved 0, offset 8, Window 14600, checksum 47633,
Flags 0x0012 (SYN ACK), données urgentes 0
TCP option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09...... .. ....
Flow FastPath, session 371381
NAT session, exécuter adresse/port translation
2015-09-01 13:21:46.169-0400 Debug: pan_tcp_reass (pan_reass. c:1999): REASS: Work 0x8000000418b1f500 session = 371381 seqno = 743112262 tcplen = 0 l4plen = 0 S2C État 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 permis
2015-09-01 13:21:46.170-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP fenêtre Scale 9
syn cookie: pan_reass (nouveau 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 travail 0x8000000418b1f500 charge utile Len 0, TCP données Len 0, RET 0
recherche de transfert, Ingres interface 28
mode L3, Virtual-Router 2
recherche d'itinéraire dans Virtual-Router 2, IP 172.22.136.50
route trouvée, interface ethernet1/15, zone 8, nexthop 10.174.62.17
ReSOLVE ARP for IP 10.174.62.17 on interface ethernet1/15
ARP entrée trouvée sur l'Interface 30
transmettre le paquet sur le port 30
-------------------------------------------
= = 2015-09-01 13:21:48.169-0400 = =
paquet reçu à FastPath stage
info paquet: Len 66 port 28 interface 28 VSys 0
wQE index 227536 Packet 0x0x8000000416e7e8e6 paquet
décodé 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, protocole 6
version 4, DIH 5, TOS 0x08, Len 52,
ID 0, frag_off 0x4000, TTL 57, checksum 63923
TCP: sport 80, dport 21081,Seq 743112262, ACK 2033466734,
réservé 0, offset 8, Window 14600, checksum 47633,
Flags 0x0012 (SYN ACK), données urgentes 0
TCP option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09...... .. ....
Flow FastPath, session 371381
NAT session, exécuter adresse/port translation
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_reass (pan_reass. c:1999): REASS: Work 0x8000000418bc6780 session = 371381 seqno = 743112262 tcplen = 0 l4plen = 0 S2C État 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 permis
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP fenêtre Scale 9
syn cookie: pan_reass (nouveau 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 travail 0x8000000418bc6780 charge utile Len 0, TCP données Len 0, RET 0
recherche de transfert, Ingres interface 28
mode L3, Virtual-Router 2
recherche d'itinéraire dans Virtual-Router 2, IP 172.22.136.50
route trouvée, interface ethernet1/15, zone 8, nexthop 10.174.62.17
ReSOLVE ARP for IP 10.174.62.17 on interface ethernet1/15
ARP entrée trouvée sur l'Interface 30
transmettre le paquet sur le port 30
------------------------------------------

= = 2015-09-01 13:21:48.170-0400 = =
paquet reçu à FastPath étape
info paquet: Len 66 port 28 interface 28 VSys 0
wQE index 226639 Packet 0x0x8000000416a288e6 paquet
décodé 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, Protocol 6
version 4, DIH 5, TOS 0x08, Len 52,
ID 0, frag_off 0x4000, TTL 57, checksum 63923
TCP: sport 80, dport 21081,Seq 743112262, ACK 2033466734,
Reserved 0, offset 8, Window 14600, checksum 47633,
Flags 0x0012 (SYN ACK), données urgentes 0
TCP option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09...... .. ....
Flow FastPath, session 371381
NAT session, exécuter adresse/port translation
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_reass (pan_reass. c:1999): REASS: Work 0x8000000418baa700 session = 371381 seqno = 743112262 tcplen = 0 l4plen = 0 S2C État 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 permis
2015-09-01 13:21:48.170-0400 Debug: pan_tcp_parse_options_syn (pan_reass. c:553): TCP fenêtre Scale 9
syn cookie: pan_reass (nouveau 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 travail 0x8000000418baa700 charge utile Len 0, TCP données Len 0, RET 0
recherche de transfert, Ingres interface 28
mode L3, Virtual-Router 2
recherche d'itinéraire dans Virtual-Router 2, IP 172.22.136.50
route trouvée, interface ethernet1/15, zone 8, nexthop 10.174.62.17
Résoudre ARP pour IP 10.174.62.17 sur l'interface ethernet1/15
ARP entrée trouvée sur l'Interface 30
transmettre paquet sur le port 30

d) lorsque le pare-feu reçoit le prochain jeu de SYN-accusés à partir du serveur avec leSeq # 883668401 modifié, il supprime le paquet. Il s'agit d'un comportement attendu, car pendant que le pare-feu attend le délai d'attente de Handshake TCP de 10 secondes (durée maximale entre la réception de l'ack syn et l'ack ultérieur pour établir pleinement la session), il a suivi le prochain SEQ # attendu à partir du serveur côté comme 743112263, mais a reçu un paquet avec leSeq # 883668401. Cette incompatibilité dans le SEQ # provoque le pare-feu de supprimer le paquet. De même, tous les paquets ultérieurs avec le Seq # 883668401, sont supprimés par le Pan.

= = 2015-09-01 13:21:54.169-0400 = =
paquet reçu à FastPath étape
info paquet: Len 66 port 28 interface 28 VSys 0
wQE index 222256 Packet 0x0x80000004165330e6 paquet
décodé 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, Protocol 6
version 4, DIH 5, TOS 0x08, Len 52,
ID 0, frag_off 0x4000, TTL 57, checksum 63923
TCP: sport 80, dport 21081,Seq 883668401, ACK 2033466734,
Reserved 0, offset 8, Window 14600, checksum 64069,
Flags 0x0012 (SYN ACK), données urgentes 0
TCP option:
00000000:02 04 05 B4 01 01 04 02 01 03 03 09...... .. ....
Flow FastPath, session 371381
NAT session, exécuter adresse/port translation
2015-09-01 13:21:54.169-0400 Debug: pan_tcp_reass (pan_reass. c:1999): REASS: Work 0x8000000418b21780 session = 371381 seqno = 883668401 tcplen = 0 l4plen = 0 S2C État 1
2015-09-01 13:21:54.169-0400 Debug: pan_tcp_reass (pan_reass. c:2074): REASS: session = 371381seqno = 883668401rcv_nxt = 743112263nouvelle connexion
2015-09-01 13:21:54.169-0400 Debug: pan_tcp_reass (pan_reass. c:2090): Numéro de séquence dans SYN_ACK non cohérente (courant + 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 travail 0x8000000418b21780 charge utile Len 0, TCP données Len 0 ,RET 2
TCP reassembly failed: RET 2

Présentation des gouttes de remontage TCP

Resolution

Other users also viewed: