Des lenteurs qui ne collent pas avec votre abonnement, des services qui tournent au ralenti sans raison apparente… Et si ce n’était pas juste un problème de Wi-Fi ?
Ou sinon il existe plusieurs FAI associatifs qui militent pour la neutralité du net et garantissent une connexion sans les bridages évoqués… mais bon … vu que c’est un « article » sponsorisé … on ne peut pas trop espéré d’objectivité dans ces lignes …
2 « J'aime »
Les articles sponsos me saoulent à un point. Le Clubic d’antan me manque un peu plus chaque jour.
5 « J'aime »
Je suis tellement d’accord. Et en plus ils sont de plus en plus ridicules ces articles. C’est mensonger et ça frise avec le complotisme parfois.
2 « J'aime »
Ah …
Au milieu de l’article on découvre le produit miracle , un VPN …
Déjà, ajouter une couche de cryptage à celles déjà existantes ne peut en aucun cas améliorer le débit ou la latence, dans la réalité c’est le contraire .
Et pour valider, moi qui défend le vpn auto hébergé, j’ai choisi wireguard depuis quelques années, car plus performant que le vieillissant openVPN et pourtant je constate que mon opérateur 5G ( pas de pblm de débit anormalement bas avec fibre/fibre ou Adsl) au cours des 6 derniers mois a du faire quelque chose sur les vpn, ou tout au moins wireguard( ?) .
Je considerais que WG me faisait perdre 25% là où openVPN m’en faisait perdre 60% … Mais depuis peu je constate une baisse de 80 à 90% là où je suis, j’en déduis une forme de Qos opérateur.
Ce n’est donc pas un VPN qui va arranger les choses , ni 3 eyes ni 6 eyes !!!
Bonté infernale !!!
1 « J'aime »
Fondamentalement, oui, la couche de chiffrement ne peut pas améliorer le débit ou la latence sur un même lien.
Par contre le passage par le VPN (ou un proxy, puisque c’est en fait essentiellement comme proxy que sont utilisés les VPN commerciaux grand public…) peut avoir quand même un impact positif dans les cas où l’opérateur fait du bridage sélectif où si certains liens de peering sont saturés. Parce que le fait de passer par le VPN va modifier le chemin que prennent les données, et donc potentiellement peut permettre d’éviter les routes encombrées/limitées.
C’était assez flagrant du temps où Free était en conflit avec Google sur le financement de la capacité de leur interconnexion : en soirée YouTube était quasi inutilisable en direct chez Free, alors qu’en passant par un VPN ou un proxy ça passait nickel (et c’est du vécu, j’étais chez Free à l’époque, et j’utilisais mon serveur OVH comme proxy SOCKS pour aller sur YouTube…).
Pour faire l’analogie, prendre un vélo, c’est théoriquement pas plus rapide que prendre une voiture pour aller d’un point à un autre. Mais s’il y a des bouchons ou si le vélo peut prendre des raccourcis, le vélo peut en pratique être plus rapide…
3 « J'aime »
Ca me rappelle avec effroi le bridage de youtube par Free, il y a genre 10ans. C’était infame.
J’ai constaté les mêmes chutes de performance. Mais je continue d’utiliser OpenVPN pour sa capacité a passer a travers pas mal de filtrages.
1 « J'aime »
le meilleur moyen de passer un filtrage est d’utiliser une clef dont l’algo de cryptage est semblable au SHA utilisé pour https et donc, router son port de VPN sur 443, ça marche pas trop mal, mais comme j’en ai besoin du 443 pour autre chose, ben j’utilise le port par defaut, faudrait que je teste sur un autre port utilisé en gestion type 8080, on verra si j’ai la motivation.
Regarde du côté de SSLH, ça permet de multiplexer plusieurs protocoles sur le même port : GitHub - yrutschle/sslh: Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port)
2 « J'aime »
Merci beaucoup, voilà une ressource intéressante et utile.
Je vais regarder .
Edit va falloir bosser un peu … en plus il y a une declaration openVPN, mais là je vais devoir tester avec wireguard, donc voir si le script accepte
" openvpn:
image: openvpn:latest
…
ports:
- 1194:1194 # bind to docker host on port 1194"
et remplacer openvpn par wireguard
Ca va demander de la reflexion, mon vpn est sur une machine, mes dockers sur une autre, ma boxe bridge, mon routeur en DHCP (quid le la transparence de ce proxy, idéalement un proxy transparent devrait fournir le dhcp …) , donc bien réfléchir aux déclarations des interfaces.
Ça ne va pas être aussi simple, je verrai ça ce week-end, si j’ai la motivation.
En tout cas c’est une solution que je ne connaissais pas, donc merci encore.
Je fais tourner mon OpenVPN sur le port 443 de mon serveur. Apache tourne aussi sur le même port. Le serveur fait lui même la différence entre les deux protocoles et route le traffic vers le bon service. Il faut juste ouvrir le port sur le routeur a la fois en udp et TCP.
Est ce que ça passe a travers les filtrages?
Je sais pas, j’ai jamais eu besoin de l’utiliser, je sais juste que ça existe 
J’ai mis mon VPN sur le port 1194 en TCP et en UDP, comme ça pas de conflit avec mon HTTPS, et j’ai encore jamais eu de situation où j’avais besoin du VPN et le port 1194 bloqué.
Au pire si ça arrive j’ai un Guacamole en HTTPS avec lequel je peux ouvrir une session sur mon serveur.
Oui, merci de l’idée, j’ajouterai que c’est dommage de mettre wireguard ou openvpn en udp, on perd de la correction d’erreur et de la coherence qu’apporte TCP, ce qui peut aboutir à un tunnel qui gonfle inutilement en mémoire.
Et un serveur https en udp n’est pas idéal non plus pour les même raisons, donc oui ton serveur https en tcp port 443 et ton openvpn en udp, ça fonctionne …
J’ai deja testé les vpn en udp, et même si ça marche, ce n’est pas l’idéal pour moi, après peut-être que je tergiverse ^^
Euh, Wireguard ne fonctionne que en UDP, pour des questions de performances (parce que tuneler du TCP dans du TCP, c’est problématique, l’augmentation progressive de la taille de la fenêtre pour la connection « emballage » et la connexion « emballée » ne se fait pas forcément de la même manière, et on se retrouve avec des paquets intérieurs qui sont découpés sur deux paquets extérieurs, ce qui augmente l’overhead et la latence).
Et OpenVPN est plus performant en UDP qu’en TCP.
La raison pour laquelle OpenVPN supporte le TCP, c’est pour passer à travers certains filtres qui bloquent l’UDP (d’où aussi le port 443 par défaut pour le TCP, pour se faire passer pour du HTTPS).
Ah oui tu as raison, je ne me souvenais plus de mon NAT, oui en effet, je l’ai mis en UDP, je ne m’en souvenais plus, mais mon explication, je l’ai retenue à l’époque pour openvpn.
Openvpn peut fonctionner en TCP et en UDP, meilleur debit en UDP, mais pas la correction d’erreur de TCP et un tunnel qui gonfle.
Donc mon openvpn tournait en tcp, ca marchait bien mieux sur la LTE que UDP, ça a bien 10 ans, c’était peut-être aussi pour pas être trop questionné par l’admin reseau d’où je bossais en régie, donc 443.
C’est un truc de fou, on la le meme serveur! 
Openvpn fonctionne mal en TCP.
ben à l’époque sur ma 4G LTE, le TCP me donnait une qualité de service superieure, et en plus je le passais en 443 pour pas être embêté par la surveillance réseau d’une régie.
Je faisais pareil dans une grosse boite d’aéronautique. Mais je ne sais plus su c’était en TCP ou en UDP.