Depuis quelque temps, le protocole Wireguard fait parler de lui dans le domaine des VPN. Plus moderne et efficace, il est aussi plus léger et désormais intégré au noyau Linux. L'équipe officialise aujourd'hui son projet d'adaptation au noyau de Windows avec WireguardNT.
Après plusieurs années à créer un nouveau protocole VPN et à l'intégrer au noyau Linux et FreeBSD, l'équipe de Wireguard se penche sur le cas de Windows. Elle veut en effet créer une version native de son application destinée au système d'exploitation de Microsoft, avec une intégration là encore aussi profonde que possible.
Adapter Wireguard à Windows, en profondeur
Dans son message d'annonce, elle indique que ce travail avait initialement été celui d'un portage du code Linux, qui a ensuite évolué pour exploiter la couche réseau spécifique de Windows. Il en résulte une solution présentée comme « intégrée profondément et très performante » pour les noyaux NT : WireguardNT.
L'enjeu est de taille. Car si l'intégration à Linux permet une exploitation chez les hébergeurs, dans des serveurs maison ou des NAS récents, être accessible avec du code natif sous Windows permet de toucher un nombre bien plus important d'utilisateurs, sans dépendre d'implémentations de plus haut niveau, utilisant des pilotes créés pour l'occasion (fonctionnant dans l'espace utilisateur) comme wireguard-go.
Cela permet de réduire la latence et d'obtenir de meilleures performances, même si l'implémentation actuelle permet d'atteindre 7,5 Gb/s selon les tests de l'équipe. Elle posait néanmoins quelques soucis parfois, notamment dans le cas des solutions Wi-Fi, avec des performances qui pouvaient chuter.
Une mise en place progressive
Pour le moment, WireguardNT en est au stade de test, le projet étant encore considéré comme expérimental. Il peut néanmoins être utilisé via la branche 0.4 du client officiel, qui vient d'être mise en ligne. Il faut l'activer manuellement en modifiant le registre avec la commande suivante :
reg add HKLM\Software\WireGuard /v ExperimentalKernelDriver /t REG_DWORD /d 1 /f
Il sera par la suite activé par défaut dès que l'équipe le trouvera assez stabilisé, avec la possibilité de rester sur l'ancienne implémentation si on le souhaite. Une dernière phase signera la disparition de l'implémentation précédente du code de l'application Windows. Aucun calendrier précis n'a pour le moment été évoqué.
Commentaires (23)
#1
Quelle bonne nouvelle. Ce VPN est simplement fou de performances et de fiabilité.
#2
Et une phase de beta est aussi lancée sur la Freebox
#3
on a beaucoup de soucis avec VPN + WiFi et c’est logique puisque double encodage. Déjà le VPN seul, ça ne doit pas être la joie. Du coup, toute solution qui améliore la situation est bonne à prendre.
#3.1
Que veux-tu dire par “double encodage” ?
#3.2
je pense qu’il veut dire un fois par le vpn et une fois par le protocole wifi
#3.3
Alors ça fait 3 si tu fais du https ou du ssh, mais très franchement, c’est le VPN, en fonction du protocole et de l’algo de chiffrement qui pèse.
#3.5
“encodage” ? Double chiffrement, peut-etre, mais en effet, il peut y en avoir 3 si on rajoute tu TLS.
Mais le chiffrement n’a pas de lien avec la stabilité du VPN. (Si la connexion Wifi est merdeuse, on ne peut pas accuser le VPN, si ?)
J’avais constaté qu’Orange droppait des packets UDP à un moment (mon boulot utilise OpenVPN) , ce qui conduisait à des perfs merdiques. (on est plusieurs en fibre chez Orange, le probleme nous affectait tous). Passer en TCP nous a permis d’avoir une connexion plus stable en attendant le fix chez Orange.
#3.6
pas encodage, chiffrement
chiffré avec le Wifi (vu la technologie, difficile de faire autrement) et chiffré avec le VPN (et parfois encore avec l’application ou l’https)
des communications téléphoniques qui coupent ou avec du son qui ne passe pas, ordi très près du modem. Quand on passe sur du filaire, les problèmes disparaissent. Cela est probablement lié à une connexion internet pas assez performante mais au final, l’important est qu’avec wifi = problème et sans wifi = très bien
intuitivement, j’aurais tendance à accuser en premier la connexion internet mais comme c’est là où on a le moins de prises, on a décidé d’encourager le filaire pour les travailleurs qui font du téléphone
#3.7
Ca peut aussi être un drivers Wi-Fi moisi sur les machines du coup, vu que même connexion, Wi-FI foireux, filaire OK.
#3.4
C’est quoi tes soucis en question?
J’utilise en continu le vpn en wifi pour le TT, jamais eu de soucis…
Et idem en déplacement je passe par opnvpn en continu et jamais eu de problème non plus.
#3.8
Si tu as un VPN UDP, sur un wifi moisi tu n’as pas plus de dégradation que ton wifi. Aussi si ta/tes applications sont robustes avec les mécanismes adéquats (TCP replay & compagnie), ta connexion est pareille.
Si tu as un VPN TCP, ton wifi moisi rends la connexion inutilisable puisqu’elle passe son temps à se rétablir après perte de paquets….
#4
J’ai reçu un mail de ProtonVPN au sujet de Wireguard aujourd’hui (en beta) … un lien direct?
#4.1
Vu le mot de sortie aussi, et je peux dire que pour le moment ça marche plutôt bien, seul l’avenir nous dira si ça tient bien quelque soit les circonstances.
Par le passé j’ai eu des tas de problèmes avec le client IPVanish, une lenteur incroyable pour se connecter, et une tenue aléatoire suivant le sens du vent….
Mais là c’est pas mal, ça se connecte rapidement, et la connexion semble stable.
Pour tous ceux qui tenteraient l’aventure VPN, quelque soit votre fournisseur n’oubliez surtout pas d’activer deux (trois dans la Beta) réglages :
1°) Le “Kill Switch” (en ce qui me concerne, c’est juste une case à cocher dans l’onglet de connexion)
2°) “IPv6 leak protection” (dans IPVanish, il faut aller dans “Settings” -> cliquer sur l’onglet “Connection” -> cocher la case “IPV6 Leak Protection” (+ “DNS Leak Protection” dans la Beta)
Pour avoir la Beta d’IPVanish c’est très simple: il faut d’abord être sûr d’avoir la dernière version “officielle” (retéléchargez-là si l’update génère une erreur) ensuite aller dans “Settings” -> “General” -> 1 click sur “Opt-in to ipvanish beta”.
Ensuite tu relances le tout, et là il va te proposer de télécharger la Bertha. Euh… Cunégonde ? Aglaë ? Sidonie ?
C’est la première fois, en x années, que je le vois démarrer la connexion (après avoir choisi Wireguard dans les Settings) ) au quart de tour, je peux vous dire que ça change!… :oui2:
#5
C’est pulse secure le VPN, j’ignore comment il est configuré.
Le gros problème, c’est sur la téléphonie et la vidéo conférence
On remarque clairement que chaque couche de cryptage a une incidence
Par exemple, entre SfB qui fonctionne hors VPN, et Teams qui fonctionne dans le VPN, on peut passer d’une communication pourrie (plusieurs secondes de décalage) à une communication fluide (sans le VPN)
#5.1
Le problème c’est que tu confonds deux choses:
Dans ton cas, tu as un VPN SSL, 99% du temps c’est du TCP. Dans le cas d’un mauvais wifi, ça achève ta connexion….
#5.2
Si tu compares hors VPN et dans le VPN, tu va surtout voir l’effet de tas d’autres choses que ton wifi.
Teams via VPN ça implique potentiellement que tu accèdes au réseau de ton entreprise pour y rejoindre la passerelle VPN (qui est peut-être saturée par tous les télétravailleurs), puis tu passes probablement par un proxy (saturé par tous les Teams lancés en parallèle) avant de ressortir par la connexion internet de ton employeur (qui est par personne probablement beaucoup moins large que ta connexion perso).
Le Wifi à côté c’est peanuts
Bon j’ai pris un scénario défavorable, peut-être que l’archi de ton entreprise est plus performante que ça, mais ce que je décris n’est pas impossible
#6
Dans ma boite on utilise également Pule Secure et aucun problème en wifi sur les fonctions visio et VoIP (skype).
#7
Non: étant donné qu’avec une connexion filaire, il n’y a pas de problème, c’est la connexion Wifi qui est pourrie.
#8
même quand la personne est juste à côté du Wifi (c’est le cas qui m’a le plus interpellé), ça me parait quand même fort d’imaginer que le Wifi soit “pourri” même si le prestataire nous a clairement déconseillé du Wifi pour de la téléphonie
mais si ton VPN est bien configuré, conformément aux consignes MS, ton SfB est censé ne pas passer par le VPN. Chez nous, on constate que la VOIP d’un agent à un autre agent est de bonne qualité générale (ne passe pas par le VPN) mais que les appels vers ou provenant fixe ou mobile sont d’une qualité moyenne inférieure (MOS de 4 pour la très grosse majorité dans le premier cas, MOS de 3 pour la très grosse majorité dans le deuxième cas)
on passe par une infra mutualisée avec d’autres entreprises qui devrait “normalement” être plutôt robuste mais qui se foire quand même de temps en temps donc ça reste une possibilité en effet, mais on préfère travailler sur tout ce sur quoi on a la main pour améliorer la qualité
le pire, c’est qu’on avait Checkpoint VPN avant qui fonctionnait très bien, beaucoup moins de problèmes, possibilité de se connecter avant l’ouverture de la session Windows et je pense UDP mais on a changé pour suivre d’autre organisations dans la solution partagée Pulse Secure (méthode parapluie, tout ce qu’on ne gère pas nous même est pas forcément mieux géré, mais quand ça déconne, on peut dire que c’est pas de notre faute)
on va bientôt mener une “expérience” avec des travailleurs qui ont eu des problèmes dans le passé + Wifi. Certains vont aller sur une solution filaire, d’autres un CPL et on va regarder si leur MOS calculé par MS va s’améliorer
j’ai l’impression que passer sur un VPN UDP nous ferait du bien mais … ça parait presque utopique pour le moment
#9
Si carte Wifi Intel: beaucoup de problèmes avec le Wifi en 802.11n (pings énormes de 300ms à 3000ms), si conjugué avec l’utilisation du bluetooth (casque, clavier, souris). En désactivant le bluetooth, tout redevient normal. C’est le cas avec des Intel 7260⁄7265, 3165, 8265, AX200. On peut aussi désactiver les canaux 40MHz ou carrément passer en 802.11g - ultra stable.
#10
+1, parfois le VPN est configurer pour que TOUT passe par le VPN, parfois les admins font passer le flux HTTP hors VPN pour tout ou pour les grands (Microsoft, Google, AWS…)
#11
pour le bluetooth, un informaticien de chez nous avait aussi dit que c’était une gamme de fréquence proche du wifi donc effectivement, on essaye d’éviter que ce genre de matériels soient utilisés pour éviter les interférences et la baisse de qualité
avec le Covid, le service ICT est passé à un système où ils remboursent le matériel et ne l’achètent plus. Erreur selon moi car du coup, on a plus du matériel homogène (plus facile à gérer au niveau des drivers) et il y a un plus grand risque d’utilisation de matériel de mauvaise qualité ou mal supporté
effectivement, c’est un problème
aussi, je sais que chez nous, mais ça ne concerne logiquement pas la téléphonie, ils font du “man in the middle” pour le traffic HTTPS (excepté certains domaines où ce serait illégal comme les webmails et les sites bancaires) afin de contrôler ce qui entre. Ca peut sans doute jouer aussi dans le ralentissement du traffic.
#12
Oui, c’est utile pour du DPI (deep packet inspection) notamment. Mais effectivement, le VPN doit être une machine bien costaude pour déchiffrer/rechiffrer tous les flux…