Pourquoi un serveur n'enverrait-il pas un paquet SYN/ACK en réponse à un paquet SYN ?

Nous avons eu exactement le même problème. La simple désactivation des horodatages TCP a résolu le problème.

sysctl -w net.ipv4.tcp_timestamps=0

Pour rendre cette modification permanente, faites une entrée dans le fichier /etc/sysctl.conf .

Soyez très prudent lorsque vous désactivez l'option TCP Window Scale. Cette option l'option est importante pour offrir des performances maximales sur l'internet. Une personne disposant d'une connexion de 10 mégabits/seconde aura un transfert sous-optimal si la connexion de l'internet est de 10 mégabits/seconde. durée du voyage aller-retour (identique au ping) est supérieur à 55 ms.

Nous avons vraiment remarqué ce problème lorsqu'il y avait plusieurs appareils derrière le même NAT. Je soupçonne le serveur d'avoir été confus en voyant les horodatages des appareils Android et des machines OSX en même temps, car ils ont mis des valeurs complètement différentes dans les champs d'horodatage.

Dans mon cas, la commande suivante a permis de résoudre le problème des réponses SYN/ACK manquantes du serveur Linux :

sysctl -w net.ipv4.tcp_tw_recycle=0

Je pense que c'est plus correct que de désactiver les horodatages TCP, car les horodatages TCP sont utiles pour haute performance (PAWS, mise à l'échelle des fenêtres, etc.).

La documentation sur le tcp_tw_recycle indique explicitement qu'il n'est pas recommandé de l'activer, car de nombreux routeurs NAT conservent les horodatages et les PAWS interviennent donc, car les horodatages provenant de la même adresse IP ne sont pas cohérents.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

Nous venons de rencontrer exactement le même problème (il nous a fallu un certain temps pour déterminer que le serveur n'envoyait pas de syn-ack).

"La solution a consisté à désactiver les fonctions tcp Windows scaling et tcp timestamps sur nos serveurs accessibles au public".

L'absence de SYN/ACK peut être due à des limites trop basses de votre protection SYNFLOOD sur le pare-feu. Cela dépend du nombre de connexions que l'utilisateur crée sur votre serveur. L'utilisation de spdy réduirait le nombre de connexions et pourrait aider dans les cas où l'activation de la protection SYNFLOOD est nécessaire. net.ipv4.tcp_timestamps n'aide pas.

Pour poursuivre ce qu'Ansis a dit, j'ai vu des problèmes de ce type lorsque le pare-feu ne prend pas en charge le TCP Windows Scaling. Quelle marque/modèle de pare-feu se trouve entre ces deux hôtes ?