Auteur Sujet: ping.online.net: coupure de connexion et mélimélo dans les ports TCP source (Lu 1169 fois)

vivien · « **le:** 16 novembre 2017 à 13:59:14 »

Je rencontre des problèmes avec http://ping.online.net : les téléchargements échouent et ce depuis plusieurs FAI.

Voici ce que cela donne avec Curl (depuis Adeli, connexion 1 Gb/s symétrique) :

$ curl -o /dev/null http://ping.online.net/1000Mo.dat % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 1 953M 1 15.7M 0 0 26892 0 10:19:45 0:10:13 10:09:32 0 curl: (56) Recv failure: Connexion terminée par expiration du délai d'attente vgu@lafibre:~$ curl -o /dev/null http://ping.online.net/100Mo.dat % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 15 95.3M 15 14.3M 0 0 24479 0 1:08:05 0:10:14 0:57:51 0 curl: (56) Recv failure: Connexion terminée par expiration du délai d'attente vgu@lafibre:~$ curl -o /dev/null http://ping.online.net/100Mo.dat % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 11 95.3M 11 11.0M 0 0 18811 0 1:28:36 0:10:14 1:18:22 0 curl: (56) Recv failure: Connexion terminée par expiration du délai d'attente vgu@lafibre:~$ curl -o /dev/null http://ping.online.net/100Mo.dat % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 17 95.3M 17 16.6M 0 0 28438 0 0:58:36 0:10:15 0:48:21 0 curl: (56) Recv failure: Connexion terminée par expiration du délai d'attente

J'ai mis en bleu la quantité de Mo téléchargé a chaque fois, environ 15 Mo quel que soit la taille du fichier demandé.

vivien · « **Réponse #1 le:** 16 novembre 2017 à 14:00:54 »

Une capture Wireshark apporte des éléments intéressants.
Vous pouvez télécharger cette capture de 11 Mo : 201711_ping-online_wireshark.pcap Elle est lisible avec Wireshark.

Au moment de l'ouverture de la connexion, sur un nouveau port, le serveur se mélange les pédales et pense qu'il a déjà une connexion active avec mon IP sur ce port : il répond a mon [SYN] par un acquittement indiquant que des données ont déjà été transférées. Pourtant les précédents transferts étaient sur d'autres ports source.

Mon Linux envoit alors un reset [RST] au serveur pour libérer cette connexion fantôme et èmet un nouveau [SYN] avec le même port source.
Là le serveur répond avec [SYN, ACK] et la connexion démarre normalement.

Wireshark a été troublé par le premier acquittement et pense a tord que c'est des retransmission, il ne faut pas en tenir compte.

Après avoir transféré une dizaine de Mo, le serveur brutalement ne répond plus : Ma pile TCP va alors envoyer des acquittements toutes les minutes en espérant qu'on va lui répondre.

La connexion se termine par time-out.

Au delà de la réparation, je suis intéressé pour savoir quelle configuration d'iptables peut générer ce problème d'où mon post public.

mikmak · « **Réponse #2 le:** 16 novembre 2017 à 22:48:06 »

c'est juste Arbor qui te fait coucou au niveau TCP ...

(TCP syn authentication)

vivien · « **Réponse #3 le:** 17 novembre 2017 à 14:09:11 »

Il considère que le serveur se fait DDOS et il le met sous mitigation...

En même temps je ne suis pas étonné, il y en a qui abusent des serveur de test de débit et notamment d'iperf.