J’arrive à capturer le trafic avec Wireshark, mais comment identifier une fragmentation ?
En revanche, quand je fais un “tcpdump -i tun0 udp port 1195” et que je met un fichier en téléchargement sur le client, rien n’est capturé. Normal ?
[quote=“Darel”]Serveur :
Client :
Ok. Je vais regarder.
Merci ![/quote]
Et tu télécharges sur le serveur, depuis le client ?
Non, du serveur vers le client, ou de testdebit vers le client en passant par OpenVPN.
[quote=“PascalHambourg”]Il faut lancer une capture de paquets (wireshark, tcpdump…) lors d’un téléchargement et vérifier la présence de fragments. Capturer :
- tous les paquets sur l’interface tun/tap du VPN
- les paquets UDP/1195 sur l’interface ethernet par laquelle passe le VPN.[/quote]
Je penses avoir trouver comment faire avec Wireshark…
Donc je suppose que oui, sa fragmente.
C’est bien ça, ou je suis complètement à coté de la plaque ?
Et si tu passes ton VPN en TCP ça donne quoi ?
J’était en train de me poser la question 
!
Je suis tombé sur ça : forums-web2.gentoo.org/viewtopic … art-0.html
Je vais tester.
Nop, c’est encore pire, je tombe à 20Mbps.
J’ai aussi éssayer de mettre ça :
tun-mtu 6000
fragment 0
mssfix 0
Idem.
[quote=“Darel”], quand je fais un “tcpdump -i tun0 udp port 1195” et que je met un fichier en téléchargement sur le client, rien n’est capturé. Normal ?
J’arrive à capturer le trafic avec Wireshark, mais comment identifier une fragmentation ?
En revanche, quand je fais un “tcpdump -i tun0 udp port 1195” et que je met un fichier en téléchargement sur le client, rien n’est capturé. Normal ?[/quote]
Oui, normal : tu n’as pas fait ce que j’ai dit dans mon message précédent. Les paquets UDP/1195 sont visibles à l’extérieur du VPN, donc sur l’interface ethernet (eth0 ?) et non l’interface tun/tap. Sur tun0, le plus simple est de tout capturer.
AMA “TCP segment of a reassembled PDU” affiché par wireshark correspond plutôt à la segmentation normale de TCP et pas à de la fragmentation IP. La taille réduite des segments (1407 octets) semble tenir compte de la surcharge d’encapsulation du VPN, pour éviter la fragmentation IP.
TCP dans TCP, ce n’est jamais terrible car la gestion de la congestion et des retransmissions des deux couches TCP empilées interfèrent l’une avec l’autre…
Donc si je comprends bien, ce n’est pas fragmenté ?
avec une trace tcpdump sur les interfaces tun et eth ce serait plus facile (pour moi) de vérifier.
tcpdump -i eth0 udp port 1195 : op2.labz.fr/tcpdump.txt
tcpdump -v -i eth0 udp port 1195 : op2.labz.fr/tcpdump-v.txt
tcpdump -vv -i eth0 udp port 1195 : op2.labz.fr/tcpdump-vv.txt
tcpdump -vvv -i eth0 udp port 1195 : op2.labz.fr/tcpdump-vvv.txt
Environ 10Mo par fichier.
Il n’était pas nécessaire de fournir une trace aussi volumineuse, un passage contenant quelques paquets de grosse taille (> 1000 octets) suffisait. Pas de fragmentation des paquets “à l’extérieur” du VPN en tout cas, ils ont même le flag “DF” qui empêche la fragmentation. Reste à vérifier à l’intérieur du VPN, avec
même si d’après la trace succinte de wireshark montrée plus haut cela ne semble pas être le cas non plus.
Là je ne sais plus trop quoi regarder.
Vous pensez qu’un VPN IPsec serait plus performant ?
Traditionnel un VPN s’appuie sur IPSec (Internet Protocol Security) pour créer un tunnel entre les deux extrémités.
Je suis curieux de la réponse qui peut être donnée, mais je ne pense pas que cela fasse une différence…
Abonnement
Dans les fichiers de conf serveur/client j’ai de nouveau joué sur le mtu…
tun-mtu 48000
fragment 0
mssfix 0
J’arrive à environ 30Mo/s, soit environ 240Mbps.
Si je met un MTU plus bas (ex: 30000), ou plus haut (ex: 54000), je flingue les perfs.
Il y a t’il une méthode pour trouver le meilleur rapport MTU/vitesse ?
Ou alors faut-il chercher à taton, tester…?
Merci pour toutes vos réponse !
Je poursuit les tests.
J’ai pris un deuxième serveur pour faire des tests.
i5 540, RAM 4Go, RAID 0, 1Gbps…
Même datacenter.
Sans jouer avec les 3 paramètres ci-dessus, je suis à environ 40Mo/s (contre 16Mo/s chez moi).
En jouant avec (même valeurs) je suis à 102Mo/s (contre 30Mo/s chez moi).
Ok, entre ces deux serveur, c’est limite du LAN…
Mais pourquoi une t’elle différence ? La latence (15ms) ?
Merci !
Une latence (ou Round-Trip Time, RTT) élevée entre le client et le serveur peut brider le débit effectif en TCP si la taille de la fenêtre de réception (RWIN) n’est pas suffisante, selon la formule : débit TCP max = RWIN / RTT. Mais dans ce cas le problème se manifesterait aussi hors du VPN.
Mmmh. Mais si c’était le cas, quand je télécharge un fichier du serveur vers le client sans passer par OpenVPN (ex: apache), le transfert serait aussi impacté, non ?
Oui, c’est ce que j’entendais par “le problème se manifesterait aussi hors du VPN”.
Je l’ai vu après.
Merci 
!