2008-10-19 7 views
0

Nous utilisons Debian avec un noyau 2.6.16, avec iptables activé. Le système exécute un proxy HTTP personnalisé, qui est soumis à une charge légère (il fonctionne correctement avec la même charge sur d'autres sites). Le système comprend 4 serveurs qui sont précédés d'un équilibreur de charge avec une adresse IP virtuelle, précédée d'un tableau de 4 machines ISA 2004, de sorte que la topologie de base est:Les paquets SYN sont parfois supprimés sous Linux

Client -> ISA [1-4] -> Load Balancer -> Notre proxy [1-4] -> Internet

Occasionnellement, l'ISA va nous envoyer un paquet SYN, auquel aucun SYN-ACK n'est envoyé. Il réessayera après 3 secondes, et une troisième fois après 6 secondes, après quoi il signalera le proxy et passera à la connexion directe. Pendant ce temps, c'est-à-dire avant, entre et après ces 3 SYNs, d'autres SYNs du même ISA arrivent et reçoivent une réponse positive.

Un problème similaire est rapporté par d'autres (sans solution, cependant):

Tout provenant d'un goût de Linux appelé CentOS. Sa particularité est d'avoir iptables activé par défaut.

http://www.linuxhelpforum.com/showthread.php?t=931912&mode=linear http://www.centos.org/modules/newbb/viewtopic.php?topic_id=16147

Presque la même: mais un peu différent: http://www.linuxquestions.org/questions/linux-networking-3/tcp-handshake-fails-synack-ignored-by-system.-637171/

semble également pertinent: http://groups.google.com/group/comp.os.linux.networking/browse_thread/thread/b1c000e2d65e0034

Je soupçonne iptables d'être un coupable, mais des commentaires supplémentaires sera le bienvenu.

Répondre

2

Regardez le second paramètre de l'appel d'écoute, comme mentionné dans le premier lien que vous avez publié. C'est le nombre maximum de connexions en attente (pas encore acceptées). Selon la page de manuel listen (2), si le protocole supporte la retransmission (TCP), la demande de connexion sera abandonnée lorsque la file d'attente est pleine (en attendant une retransmission ultérieure qui créera la connexion s'il y a suffisamment d'espace dans la file).

+0

Cela n'explique pas que d'autres demandes au même port réussissent, alors que celles-ci échouent. – user29402

+0

Les autres requêtes ont probablement de la chance et viennent après que la file d'attente se vide un peu (c'est-à-dire après que le serveur a accepté certaines des connexions en attente). – CesarB

+0

Ensuite, le prochain SYN serait entré, ou le suivant - mais si on reste sans réponse, tous les trois sont sans réponse. J'ai du mal à l'expliquer par chance. – user29402

0

En effet, les iptables se sont révélés être le culrpit, avec la règle qui a abandonné les paquets INVALID. Nous ne savons toujours pas avec certitude ce qui a permis à iptables de penser que ces SYNs n'étaient pas valides (pas de TIME_WAIT à coup sûr, puisque nous n'avions aucun trafic avec les mêmes ports source pendant au moins 30 minutes avant les gouttes).