OpenVPN - Port TCP 443 mauvaise performance
-
Est il possible de tester Pfsense sur un serveur matériel dédié ? Cela donnerait un autre éclairage sans doute. Free BSD est connu pour avoir une pile réseau particulièrement rapide mais pas nécessairement dans un environnement virtualisé. Il serait intéressant de lever le doute.
-
Bonjour,
Merci de vos réponses.
Pour tester Pfsense sur du dédié ça sera normalement possible d'ici quelques temps je l'espère.
Il n'y aurait pas des paramètres TCP que l'on pourrait tester ? Ou bien des paramètres du OpenVPN comme tun-mtu, mssfix etc etc ?Merci
-
Pour la virtualisation de BSD, il faudrait une machine physique ou deux identiques : l'une avec proxmox, l'autre sans, et une install pfsense de part et d'autres.
J'ai eu l'occasion de tester : je ne suis presque sûr que pfSense en virtualisé ne tient pas le choc.Pour OpenVPN, je vous recommande de lire les réflexions d'OpenVPN, le pourquoi du comment, … et de migrer à 1194/udp.
Je reconnais qu'il est curieux qu'UDP soit là plus performant, mais il faut savoir que NFS utilise udp, que tout n'utilise pas tcp.
OpenVPN est un VPN donc il doit nécessairement encapsuler un flux dans un autre, tout comme PPP (PPPoE).
Or chacun sait que PPP réduit la taille des paquets du fait de l'encapsulation (mtu 1492 au lieu de 1500).
Vous pourrez constater qu'1194/udp est plus performant que 443/tcp.Je ne crois pas à l'utilisation de mtu spécifique même si on peut trouver des exemples de config avec mtu modifié.
En général, quand on joue avec le mtu c'est à tort. A considérer --link-mtu.
Vous voyez que l'encapsulation joue un grand rôle ...NB : ma première utilisation d'OpenVPN utilisait aussi 443/tcp parce que, moi aussi, j'ai cru à "la bonne idée". J'en suis revenu !
-
Quand je suis chez moi ou derrière une liaison non firewallée ça ne me pose aucun soucis de faire de l'OpenVPN via UDP/1194, je fais même de l'IpSec d'ailleurs à côté. Ca marche et j'en suis très content.
Là ma recherche s'effectue sur du TCP/443 uniquement car je veux pouvoir me connecter à travers les firewalls qui bloquent certaines applications (exemple Skype), je veux pouvoir m'en servir en connexion "de secours", mais avec un débit acceptable.
-
Salut,
Si je résume, le problème ne survient qu'en TCP ?
Si oui, merci de faire une capture réseau (wireshark) lors d'une connexion afin de voir si on a un comportement anormal ( beaucoup de retransmission, ou des demande de resize de transmit Windows). Je pense à un problème de MTU par exemple, retester en abaissant le MTU de la carte WAN et voir si le débit s'améliore.Si le problème se présente sur les deux type de connexion UDP et TCP, voir si les débits évoluent en changeant l'algo de cryptage utilisé.
Enfin voir aussi en désactivant, si ce n'est pas déjà le cas, tous les mécanismes d'offload de checksum (TSO and co).
-
Salut,
Merci de ta réponse !
Effectivement le problème est vraiment visible en TCP, un peu moins en UDP. Par contre c'est une machine hébergée :/ et du coup la capture wireshark est impossible.
Je pense aussi à un problème de MTU ou autre dans les tunables !J'ai déjà tenté de changer le cryptage, en vain.
Je vais voir pour désactiver les TSO et autres. -
Tu peux faire une capture dans Diagnostics/Packet Capture, puis la télécharger et l'analyser avec Wireshark.
-
Hello,
J'ai eu une amélioration incroyable en TCP. J'ai désactivé le tcp.inflight, maintenant j'ai un débit comparable à celui de l'UDP !
Cependant à la maison j'ai du 200 Mb/s en réception et sur le serveur j'ai du 1 Gb/s, en faisant un speedtest je ne dépasse pas les 80 Mb/s en TCP ou UDP.
Est-ce qu'il y aurait des system tunables qui pourraient me brider encore ?Merci !
-
Le débit doit être un peu inférieur à cause de l'overheead de l'encapsulation, mais pas autant.
Charge CPU de la VM du serveur quand tu es à 80Mbit/s ?
-
La VM se porte plutôt bien pendant le test :
Une idée ?
-
40% sur 4 CPU, il faudrait se connecter en SSH et regarder si le process openvpn n'est pas à 100 % sur un cpu
-
Un top durant le test :
