WireGuard, protocole de communication chiffré sur UDP et logiciel libre

• # Intégré dans systemd-networkd

  Posté par Marmotte le 22 août 2022 à 08:37. Évalué à 10.

  

  Merci pour cette présentation :)

  Je trouve que le paragraphe "Tutoriel : Installer Wireguard côté serveur sur Debian/Ubuntu" est mal nommé, ça pourrait être "Tutoriel : Installer Wireguard sur Debian/Ubuntu" tout court, puisqu'il n'y a aucune notion de client ou serveur avec Wireguard, juste des peers qui se connectent entre eux.

  Pour donner une autre idée/vision, je l'utilise sur des machines Debian dont le réseau est géré par systemd-networkd, et ça tombe bien, puisqu'il y est géré nativement depuis un bon moment.

  Je n'installe aucun paquet sur les serveurs, uniquement le paquet wireguard-tools sur ma station de travail pour générer les clés avec la commande wg genkey | tee /dev/stderr | wg pubkey, ça affiche les deux dans la console sans écrire de fichier (la clé privée en premier, et la clé publique en dessous).
  Pour les clés preshared, j'utilise juste wg genpsk sans rediriger dans un fichier, puisque je vais juste copier/coller les clés dans la conf.

  Ensuite, je crée juste deux fichiers de conf par serveur :
  /etc/systemd/network/50-wg0.netdev (avec des droits en root:systemd-network 0640 puisqu'il contient des secrets)

  [NetDev]
  Name=wg0
  Kind=wireguard
  
  [WireGuard]
  PrivateKey=<server1_private_key>
  # Port d'écoute, si la machine est joignable directement par d'autres
  ListenPort=<port>
  
  [WireGuardPeer]
  PublicKey=<server2_public_key>
  PresharedKey=<preshared_key>
  # Adresse de la machine distante, si elle est joignable directement
  Endpoint=<remote_peer_public_ip>:<port>
  AllowedIPs=<remote_peer_vpn_ip>/32
  AllowedIPs=<remote_subnet1>/<mask>
  AllowedIPs=<remote_subnet2>/<mask>
  

  /etc/systemd/network/50-wg0.network

  [Match]
  Name=wg0
  
  [Network]
  Address=<server1_peer_vpn_ip>/<mask>
  
  [Route]
  Destination=<remote_subnet1>/<mask>
  Scope=link
  
  [Route]
  Destination=<remote_subnet2>/<mask>
  Scope=link
  

  Un restart du service systemd-networkd et… tadaaa !

  Bonus : Si le réseau de la machine n'est pas géré par systemd-networkd, on peut quand même l'utiliser pour Wireguard en lui demandant d'ignorer les autres interfaces avec quelque chose comme :

  [Match]
  Name=!en* wl*
  

• # Commentaire supprimé

  Posté par Anonyme le 22 août 2022 à 09:22. Évalué à 3.

  

  Ce commentaire a été supprimé par l’équipe de modération.

  • [^] # Re: Corrections

    Posté par Benoît Sibaud (site web personnel) le 22 août 2022 à 11:52. Évalué à 4.

    

    Corrigé, merci.

• # Freebox

  Posté par glops le 22 août 2022 à 09:47. Évalué à 8.

  

  Article très intéressant !
  Je pense qu'il serait intéressant de mentionner qu'il est possible d'activer un serveur WireGuard très simplement sur les Freebox (je ne sais pas pour les autres box). De plus, WireGuard permet d'accéder à son réseau local depuis l'extérieur, sur un appareil Android, alors que ça ne fonctionne pas (ou c'est très compliqué) via OpenVPN (tjrs sur Freebox).

  La Freebox permet aussi de se connecter à un VPN WireGuard en mode client, mais ça n'est utilisé que pour le gestionnaire de téléchargement.

  • [^] # Re: Freebox

    Posté par ploppor le 22 août 2022 à 14:41. Évalué à 1.

    

    Petite question.
    Je viens d'activer Wireguard sur ma Freebox et installé le client Android.
    Connexion Ok, mais pas moyen d'accéder au réseau local (A part la Freebox).
    Tu as fais une manip particulière pour l'accès aux machines du réseau local depuis le VPN ?

    • [^] # Re: Freebox

      Posté par glops le 23 août 2022 à 12:16. Évalué à 2.

      

      Non, je n'ai rien fait de particulier.
      Maïs dans ma configuration, tout en bas, j'ai adresse IP autorisées : 0.0.0.0/0, 192.168.27.64/27, 192.168.0.0/24
      La deuxième est la plage attribuée aux client wireguard, et la troisième c'est ma plage d'ip locale.
      Et "exclure les ip locales" est décoché

      • [^] # Re: Freebox

        Posté par ploppor le 23 août 2022 à 16:14. Évalué à 0.

        

        Bon, je suis bon pour le forum :-(
        Moi, rien à faire:
        ping 192.168.0.xxx (la Freebox) -> OK
        ping 192.168.0.yyy (le NAS) -> Rien
        http://192.168.0.zzz (Le serveur astro) -> Rien aussi
        J'ai essayé d'activer le VPN routé en plus (pour l'ip forward) -> Pas mieux :-(

        • [^] # Re: Freebox

          Posté par Ecran Plat (site web personnel, Mastodon) le 24 août 2022 à 15:10. Évalué à 2.

          

          tu as peut être une adresse en 192.168.0.0/24 depuis l'accès distant dans ce cas ça ne marchera pas

          c'est pour ça sur son réseau local il faut éviter 192.168.0.0/24 et 192.168.1.0/24 qui sont souvent les réseaux par défaut dans les routeurs fournit par les opérateurs.
          Mettre par exemple 192.168.37.0/24 et on aura certainement jamais ce problème

      • [^] # Re: Freebox

        Posté par ploppor le 24 août 2022 à 17:08. Évalué à 2.

        

        Trouvé !
        C'est l'agrégation 4G+ADSL qui fait foirer l'accès au réseau local.
        Agrégation désactivée: Accès au réseau local OK
        Agrégation activée: Accès à la Freebox seulement.

• # Une seule suite crypto ?

  Posté par flan (site web personnel) le 22 août 2022 à 09:51. Évalué à 4.

  

  Je tique un peu sur cette remarque.
  Est-ce ce que cela signifie qu'une seule seule crypto est actuellement proposée mais que le protocole offre un mécanisme de négociation comme en TLS, ou n'y a-t-il pas de négociation du tout ?

  • [^] # Re: Une seule suite crypto ?

    Posté par xryl669 le 22 août 2022 à 10:22. Évalué à 6.

    

    Je pense que tu confuses. Wireguard c'est un outil qui utilise de nombreuse primitives cryptographiques: (ChaCha20 pour le chiffrage symétrique, Curve25519 pour DH, BLAKE2S pour le hashing, HKDF pour la dérivation des mot de passe/clés, …). Tu remarquera qu'il s'agit des primitives "à la mode", c'est à dire celle qui sont le plus efficace et sécurisées pour le moment.

    Mais, contrairement à TLS, il n'y a pas de négociation d'algorithmes et de capacités (ce qui est plus source de problème plus que d'intercompatibilité, AMHA), vu que le protocole défini les primitives utilisées.

    Si, à l'avenir, une primitive s'avère problématique, je suppose qu'ils feront avancer la version du protocole pour échanger une primitive avec une autre, en rendant obsolète la primitive à problème.

    • [^] # Re: Une seule suite crypto ?

      Posté par flan (site web personnel) le 22 août 2022 à 11:58. Évalué à 6.

      

      Ce qui veut dire faire évoluer en même temps client et serveur. Ça risque d'être compliqué sur le long terme, surtout si un même client peut utiliser deux serveurs différents.

      • [^] # Re: Une seule suite crypto ?

        Posté par Glandos le 22 août 2022 à 12:08. Évalué à 1.

        

        J'ai pas réussi à retrouver le message de Jason Donenfeld lors de la conception initiale de Wireguard.

        Mais en gros, sur la crypto, il partait de l'expérience de OpenSSL : quand tu veux créer un socket TLS, c'est extrêmement compliqué, à cause du choix des algorithmes cryptographiques.
        Sur Wireguard, l'utilisateur n'a pas le choix. C'est un ensemble d'algorithmes, point. Mais il me semble que l'agilité cryptographique n'a pas été oubliée.

        Quant à mettre à jour les logiciels, c'est la même chose lors du déploiement de nouveaux algorithmes, y compris pour OpenSSH, TLS, etc.

        • [^] # Re: Une seule suite crypto ?

          Posté par gouttegd (site web personnel) le 22 août 2022 à 12:26. Évalué à 10.

          

          Mais il me semble que l'agilité cryptographique n'a pas été oubliée.

          Si, si. C’est écrit noir-sur-blanc dans le papier blanc de WireGuard :

          WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update.

          Sachant qu’on compte déjà 8 implémentations indépendantes du protocole (d’après Wikipedia, j’avoue n’avoir pas vérifié), si un jour il faut « demander à tous les nœuds de mettre à jour [en même temps] », ça promet d’être amusant…

          • [^] # Re: Une seule suite crypto ?

            Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) le 22 août 2022 à 18:51. Évalué à 6. Dernière modification le 22 août 2022 à 18:55.

            

            Cette absence d'agilité cryptographique est en effet une sérieuse erreur de conception de Wireguard (voir le RFC 7696 pour une explication). Un bon exemple est l'arrivée des algorithmes post-quantiques. Comment Wireguard va-t-il gérer cela ?

            • [^] # Re: Une seule suite crypto ?

              Posté par Matthieu Duchemin (site web personnel) le 22 août 2022 à 21:53. Évalué à 4. Dernière modification le 22 août 2022 à 21:53.

              

              La solution choisie par Wireguard est de créer une nouvelle version qui sera incompatible avec la précédente.

              Dans l'article Cryptographic Agility and Superior Alternatives l'auteur explique pourquoi l'agilité est une mauvaise chose du point de vu de la sécurité en prenant l'exemple de JWT et qu'elles sont les alternatives possibles. Le cas de Wireguard est évoqué.

              Je ne suis pas assez compétant en sécu pour discuter son point de vue, Bruce Shneier a quant à lui évoqué sa préférence pour l'agilité récemment (https://www.schneier.com/blog/archives/2022/08/nists-post-quantum-cryptography-standards.html).

              Ce que j'en comprend, c'est que la question est : à qui revient la responsabilité de l'algo à utiliser ? A ceux qui conçoivent le protocole, aux développeurs qui vont utiliser une lib (JWT, openSSL) voir même à l'utilisateur (configuration SSL/TSL dans apache par exemple).

              J'aurais tendance à accorder ma confiance aux premiers, et donc n'avoir qu'un seul algo possible. Je comprend que cela permet de garder une base de code plus réduite ce qui est un bon point, le problème d'incompatibilité est de toute manière existant avec l'agilité. Quand il a fallu désactiver les vieux algos sur SSL/TLS sur les serveurs web, on s'est rendu incompatible avec certains clients. A l'inverse quand on avait des vieux OS sur les serveurs et que les navigateurs coupaient les vieux algos, cela entrainait aussi des compatibilités.

              Mais je vois mal utiliser la méthode choisie par Wireguard pour le web, mais laisser la responsabilité aux administrateurs systèmes n'est pas toujours la bonne solution (j'en suis un). Mais pour le cas d'usage de Wireguard, qui est dans un réseau maîtrisé, ça me semble être une très bonne approche. En tant qu'admin je sais que je dois tenir à jour les versions du logiciel mais pas en plus à connaître les arcanes de la configuration des algos de crypto pour avoir une installation sécurisée.

              • [^] # Re: Une seule suite crypto ?

                Posté par flan (site web personnel) le 22 août 2022 à 22:04. Évalué à 6.

                

                Mais à nouveau, comment fais-tu pour tout mettre à jour en même temps ?

                Les dates de disponibilité dépendent d'une plate-forme à l'autre, et si tu mets à jour ton serveur en premier, tes clients n'auront plus accès au VPN et ne pourront donc plus faire la mise à jour.

                • [^] # Re: Une seule suite crypto ?

                  Posté par YannickP le 22 août 2022 à 23:04. Évalué à 3.

                  

                  Je suppose qu'il suffit de faire écouter la nouvelle version sur un port différent et ne couper l'ancienne version que lorsqu'elle n'est plus utilisée. Cela ne me paraît pas totalement insurmontable.

                  • [^] # Re: Une seule suite crypto ?

                    Posté par flan (site web personnel) le 22 août 2022 à 23:25. Évalué à 8.

                    

                    • Ça t'empêche d'utiliser la version fournie par ta distribution (par définition, tu n'auras qu'une seule version d'installée sur ton système),
                    • Ça t'oblige à garder une vieille version en production,
                    • Ça t'empêche d'utiliser des ports standards.

                    • [^] # Re: Une seule suite crypto ?

                      Posté par Moonz le 23 août 2022 à 08:41. Évalué à 0.

                      

                      J’ai bien python2 et python3 intallés en parallère sur ma machine. Ainsi que gtk2, gtk3 et gtk4.

                      • [^] # Re: Une seule suite crypto ?

                        Posté par freem le 24 août 2022 à 13:10. Évalué à 3.

                        

                        WireGuard est disponible nativement dans le noyau Linux depuis la version 5.6 et est disponible comme un module externe pour les noyaux 3.10 et ultérieur (en utilisant le support dynamique de chargements de modules DKMS).

                        Je ne sais pas a quel point le noyau supporte d'avoir 2 implémentations du même module chargés?

                • [^] # Re: Une seule suite crypto ?

                  Posté par gouttegd (site web personnel) le 22 août 2022 à 23:10. Évalué à 4.

                  

                  Mais à nouveau, comment fais-tu pour tout mettre à jour en même temps ?

                  Bah c’est pourtant facile, il suffit d’être organisationellement agile qu’on te dit !

                  « Organisationnellement agile » étant un mot de code pour dire que l’on parle d’une organisation centralisée où toutes les décisions sont prises par un acteur unique. C’est le seul cas de figure où l’approche mono-algorithme est viable, en fait.

                  Des organisations comme Signal peuvent se permettre de choisir cette approche et de dire merde à l’agilité cryptographique. Mais la présenter comme LA solution universelle applicable partout, c’est stupide.

              • [^] # Re: Une seule suite crypto ?

                Posté par gouttegd (site web personnel) le 22 août 2022 à 23:04. Évalué à 10.

                

                Supporter l’agilité cryptographique n’implique aucunement de laisser les administrateurs et/ou les utilisateurs décider de l’algorithme à utiliser.

                Ce n’est pas parce que c’est comme ça qu’on a fait avec TLS que c’est inhérent au principe de l’agilité cryptographique. (Tous les arguments que j’ai lu contre l’agilité cryptographique sont du même tonneau : on a magistralement foiré l’agilité cryptographique dans (TLS|JWT|SSH|…), du coup il ne faut plus d’agilité du tout…)

                Disons que le protocole autorise trois algorithmes différents A, B, et C, et recommande l’algorithme A.

                Alice utilise un logiciel supportant les trois algorithmes. Bob utilise un autre logiciel supportant aussi les trois algorithmes. Quand ils se parlent, leurs logiciels s’échangent la liste des algorithmes supportés et, constatant la présence de l’algorithme A des deux côtés, utilisent obligatoirement A, sans que jamais Alice et Bob n’aient leur mot à dire.

                On découvre une faille dans l’algorithme A, les auteurs du protocole recommandent désormais l’algorithme B. Alice met à jour son logiciel pour une nouvelle version dans laquelle l’algorithme A est désactivé. Bob n’a pas encore mis à jour (l’éditeur de son logiciel n’a pas encore publié de nouvelle version). Quand ils se parlent, le logiciel d’Alice annonce supporter les algos B et C, le logiciel de Bob annonce toujours supporter les algos A, B, C — les deux se mettent d’accord pour utiliser B, toujours sans que ni Alice ni Bob n’aient leur mot à dire.

                Plus tard, Bob met à jour, sa nouvelle version ne supporte plus que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.

                Plus tard encore, les auteurs du protocole rajoutent un algo D, et décident qu’il est tellement mieux que les autres qu’il devrait désormais être utilisé partout où c’est possible.

                Cette fois l’éditeur du logiciel de Bob est plus rapide et publie une nouvelle version avec le support de D. Alice, elle, reste temporairement avec une version qui ne supporte toujours que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.

                Alice met à jour, son logiciel supporte désormais B, C, et D. Alice et Bob utilisent désormais automatiquement D chaque fois qu’ils se parlent.

                Et ainsi de suite. À aucun moment Alice et Bob ne peuvent configurer leurs logiciels pour décider eux-mêmes de l’algorithme à utiliser. Le choix est imposé par les logiciels, en fonction des recommandations des auteurs du protocole et de ce que supporte le logiciel d’en face.

                • [^] # Re: Une seule suite crypto ?

                  Posté par claudex le 23 août 2022 à 16:22. Évalué à 2.

                  

                  Perso, je suis pour l'agilité. Mais je pense si c'est introduit, il y aura des demandes incessantes pour ajouter des algos foireux et pour demander que ce soit configurable.

                  Quand ils se parlent, le logiciel d’Alice annonce supporter les algos B et C, le logiciel de Bob annonce toujours supporter les algos A, B, C — les deux se mettent d’accord pour utiliser B, toujours sans que ni Alice ni Bob n’aient leur mot à dire.

                  Ce n'est pas aussi magique que ça, il y a un risque de downgrade attack, qu'il faut aussi gérer sans bug.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Une seule suite crypto ?

                    Posté par 🚲 Tanguy Ortolo (site web personnel) le 23 août 2022 à 17:31. Évalué à 6.

                    

                    Perso, je suis pour l'agilité. Mais je pense si c'est introduit, il y aura des demandes incessantes pour ajouter des algos foireux et pour demander que ce soit configurable.

                    Les demandes, ça se gère sans problème, il suffit de les refuser. C'est très facile à automatiser d'ailleurs.

                    Sérieusement, si le projet est clair sur le fait que ce sont les développeurs principaux qui choisissent les algos et que toute demande sur ce sujet sera refusée, ça ne pose pas plus de problème que le choix actuel.

                    D'ailleurs, je ne serais pas surpris que même actuellement, ils reçoivent justement de telles demandes. Ou des demandes d'introduction d'agilité, comme on dit visiblement.

                    Ce n'est pas aussi magique que ça, il y a un risque de downgrade attack, qu'il faut aussi gérer sans bug.

                    Bof. Ce n'est pas compliqué, si je comprends bien le problème principal, c'est celui de la mise à jour d'un serveur VPN et de ses clients, qui, avec la conception actuelle, quand le cas se présentera, devra se faire de façon simultanée. Donc, comme je disais, pas besoin de maintenir un ensemble délirant de protocoles, pour que les évolutions ne nécessitent plus une telle parfaite synchronisation : il suffit que le serveur prenne en charge la version actuelle du jeu d'algos crypto et, sur configuration explicite, la précédente.

                    Scénario :

                    • le serveur est mis à jour, et configuré pour accepter l'ancien jeu d'algos ;
                    • les clients sont avertis qu'ils doivent mettre à jour avant telle date ;
                    • à la date dite, le serveur est configuré pour ne plus accepter l'ancien jeu d'algos.

                    Sans ça, le scénario serait plutôt :

                    • le serveur n'est pas mis à jour, pour ne pas péter l'intégralité des connexions ;
                    • les clients sont avertis qu'ils doivent mettre à jour exactement à telle date, telle heure ;
                    • (les clients qui mettent à jour trop tôt sont pétés) ;
                    • à la date dite, le serveur est mis à jour ;
                    • (les clients qui n'ont pas mis à jour à temps sont pétés).

                    Ce scénario, qui est celui choisi par la conception de WireGuard, est juste moins bien que l'autre, pour le service évidemment, mais également pour la sécurité. Parce que si vous observez bien, l'utilisation d'algos obsolètes n'y nécessite même pas d'attaque par dégradation, elle est carrément maintenue par conception, le temps que tout le monde soit prêt à faire une mise à jour synchronisée !

                    • [^] # Re: Une seule suite crypto ?

                      Posté par claudex le 23 août 2022 à 19:47. Évalué à 3.

                      

                      Les demandes, ça se gère sans problème, il suffit de les refuser. C'est très facile à automatiser d'ailleurs.

                      C'est d'ailleurs le rêve de tout développeur, de passer son temps à faire le tri dans le bugs pour en refuser les trois quarts.

                      Bof. Ce n'est pas compliqué

                      Ben oui, il suffit de coder sans bug. Ce n'est pas comme si c'était anecdotique, il y a POODLE, FREAK, DROWN, Logjam… Ce n'est pas le genre d'attaque qui manque.

                      Donc, comme je disais, pas besoin de maintenir un ensemble délirant de protocoles

                      Mais il ne faut pas un ensemble délirant de protocole, il en faut juste 2 dont 1 cassé.

                      (les clients qui mettent à jour trop tôt sont pétés) ;

                      Comme dit dans un autre commentaire, tu peux faire tourner les deux versions en même temps.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Une seule suite crypto ?

                  Posté par barmic 🦦 le 23 août 2022 à 22:19. Évalué à 5.

                  

                  Il me semble que tu disais que les développeurs de GPG n'arrivaient pas à supprimer des algos pourtant considérés comme plutôt fragiles à cause de leur communauté qui réclamait de les garder.

                  Ça ne semble pas être si simple de désactiver un algo (probablement tant qu'il n'est pas complètement percé).

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Une seule suite crypto ?

                    Posté par gouttegd (site web personnel) le 23 août 2022 à 23:16. Évalué à 10.

                    

                    Pas grand’chose à voir. OpenPGP est très utilisé pour chiffrer/signer des « données au repos » (data at rest), potentiellement sur de longues durées. Ceux qui réclamaient le maintien du support pour de vieux algorithmes sont tous ceux qui voulaient conserver la possibilité de déchiffrer leurs vieilles archives de messagerie ou leurs vieilles sauvegardes datant des années 1990¹.

                    Des protocoles utilisés pour le chiffrement de données en transit, comme TLS ou WireGuard, n’ont nul besoin de supporter des algorithmes obsolètes.² C’était justement ça l’erreur de TLS : pas l’agilité cryptographique en soi, mais l’agilité cryptographique avec une liste de trouze mille algorithmes, dont certains complètement dépassés et, pire encore, certains délibérément affaiblis pour suivre les législations des années 1990 (les suites TLS_EXPORT) — et même, encore vraiment pire, des pseudo-algorithmes qui en réalité ne chiffrent pas du tout (les suites TLS_NULL).

                    Ajoute à ça que de toutes les implémentations d’OpenPGP, GnuPG est celle qui a à la marge de manœuvre la plus étroite quand il s’agit des vieux algos, parce que c’est la seule à les supporter — toutes les autres implémentations sont nées beaucoup plus tard et ont choisi de ne supporter d’emblée que les algos modernes ; elles pouvaient se le permettre précisément parce que GnuPG était là pourceux qui avaient besoin des vieux algos !

                    Bref, la difficulté de retirer un algo pour les développeurs de GnuPG n’indique pas grand’chose de la difficulté qu’il y aurait à retirer un algo dans WireGuard, si ce dernier avait fait le choix d’en supporter plusieurs.

                    Par ailleurs, les auteurs de WireGuard semblent confiant dans leur capacité à imposer à tout le monde de passer à un hypothétique WireGuard-v2 le jour où il faudra changer d’algo, donc pourquoi croire qu’ils ne seraient pas capable d’imposer le retrait d’un algo ?

                    (À moins bien sûr que cette capacité ne soit que du flanc, et qu’en réalité ils n’aient pas la moindre idée de la procédure qu’il faudra mettre en œuvre le jour où il faudra basculer…)

                    ---

                    ¹ Et qui auraient mieux fait de re-chiffrer leurs vieilles archives avec des algos plus modernes plutôt que de les conserver chiffrées avec les vieux algos de l’époque, mais bon…

                    ² Sauf pour ceux qui veulent faire du WireGuard-over-IPoT depuis 1999, mais bon, je m’autorise à penser que ça doit être une niche encore plus réduite que celle des utilisateurs d’OpenPGP. :D

                    • [^] # Re: Une seule suite crypto ?

                      Posté par barmic 🦦 le 23 août 2022 à 23:54. Évalué à 2.

                      

                      OK OK je comprends

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Une seule suite crypto ?

          Posté par flan (site web personnel) le 22 août 2022 à 14:45. Évalué à 3.

          

          Quant à mettre à jour les logiciels, c'est la même chose lors du déploiement de nouveaux algorithmes, y compris pour OpenSSH, TLS, etc.

          Si, justement : le client et le serveur se mettent d'accord pour utiliser le meilleur choix disponible chez les deux parties.

          Imaginons que mon serveur Wireguard a été mis à jour et mon client en fonctionne donc plus. Comment suis-je censé mettre à jour mon client sans VPN ? Que dois-je faire si le client n'est pas encore disponible pour une raison X ou Y (les deux ne sont pas sous le même OS) ?

          • [^] # Re: Une seule suite crypto ?

            Posté par xryl669 le 24 août 2022 à 10:12. Évalué à 0.

            

            Par internet ? Comme n'importe quel autre logiciel en fait. Wireguard c'est un tunnel crypté, fourni soit avec le noyau ou à côté, comme module, ou en user space, bref, t'as l'embarras du choix.

            • [^] # Re: Une seule suite crypto ?

              Posté par flan (site web personnel) le 25 août 2022 à 20:23. Évalué à 1.

              

              Quand je pars à l’étranger, je ne veux avoir accès à internet qu’à travers un VPN. Si je n’ai plus de VPN, je n’ai plus accès à internet non plus.

• # Une petite erreur ?

  Posté par Tonton Th (site web personnel, Mastodon) le 22 août 2022 à 11:02. Évalué à 6.

  

  On a d'abord :

  Pour l’exemple, nous utiliserons ici les plages d’adresses privées suivantes : 10.26.174.0/24, fd42:42:42::/64

  Et plus loin, dans la configuration de unbound :

  access-control: 10.26.174.0/16 allow
  access-control: fd42:42:42::/48 allow

  Ce genre d'erreur, ça peut prendre des heures à retrouver…

  • [^] # Re: Une petite erreur ?

    Posté par Benoît Sibaud (site web personnel) le 22 août 2022 à 11:54. Évalué à 4.

    

    Corrigé, merci.

• # Extension d'IP pour par exemple un serveur de license

  Posté par Graveen le 22 août 2022 à 11:10. Évalué à 6.

  

  Salut,

  Je me demandais si WG pouvait faire comme OpenVPN, à savoir une interface prolongeant le plan d'adressage local (via TAP avec une IP v4 en 192.168.1.x distribuée par OpenVPN).

  L'idée c'est d'attaquer un service bien particulier qui nécessite le même plan d'adressage plutôt que d'implémenter du routage sur le serveur.

  Ou est ce que WG nécessite systématique un routage (statique ou dynamique) de par son fonctionnement en mode peer ?

  Merci !

  • [^] # Re: Extension d'IP pour par exemple un serveur de license

    Posté par dr191 le 22 août 2022 à 17:28. Évalué à 2.

    

    Bonjour,

    Si vous pensez au mode bridge ethernet de Openvpn, non ce n'est pas possible:

    WireGuard is a secure network tunnel, operating at layer 3 …

    • [^] # Re: Extension d'IP pour par exemple un serveur de license

      Posté par Graveen le 24 août 2022 à 23:05. Évalué à 2.

      

      Merci je pensais exactement à ca :)

• # Simple comme...

  Posté par Argon le 22 août 2022 à 16:07. Évalué à 2.

  

  WireGuard se veut plus simple qu’IPSec à la fois pour les développeurs et pour les utilisateurs.

  Côté admin/utilisateur la simplicité est complètement loupé alors. Je l'ai utilisé un peu sur un Routeur OPNSense/Poste Windows je vois pas où est la simplicité. Pour la partie Windows si il n'y a pas d'option "vpn before login" c'est presque mort en entreprise.

  Pour rester positif c'est encore jeune, à voir dans les années comment va évoluer le projet.

  de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité

  • [^] # Re: Simple comme...

    Posté par Astaoth le 22 août 2022 à 19:37. Évalué à 6. Dernière modification le 22 août 2022 à 19:40.

    

    En entreprise c'est mort à tout les niveaux pour l'utiliser :
    - pas d'adressage IP dynamique, tout les clients doivent avoir un adressage statique
    - pas d'intégrations d'annuaires
    - pas de MFA
    - pas de traversée de double-NAT

    Wireguard, dans son état actuel est juste un jouet. C'est dommage parce qu'à côté il comble les faiblesses de ses 2 concurrents :
    - OpenVPN fonctionne en user-space et est donc très consommateur de ressources
    - IPSec Ikev2 ne génère pas d'interface réseau par défaut, le routage des flux se fait avec des règles XFRM.

    Mais bon, pour la consommation de ressources d'OpenVPN, il "suffit" de fournir suffisement de ressources pour avoir suffisement de débit pour tout le monde. Pour Ikev2, un bon firewall fera un routage correct des flux si on a des besoin complexes, et avec StrongSwan sous Linux il est également possible de lier un tunnel à une interface réseau pour pouvoir faire du routage de flux classiques.

    Du coup pour le moment, Wireguard n'a que peu d'intérêts.

    Emacs le fait depuis 30 ans.

    • [^] # Re: Simple comme...

      Posté par GG (site web personnel) le 22 août 2022 à 21:44. Évalué à -6.

      

      C'est bien, tu n'as plus qu'à faire des PR.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Simple comme...

      Posté par xryl669 le 23 août 2022 à 12:53. Évalué à 3. Dernière modification le 23 août 2022 à 12:54.

      

      Vu que c'est level 3, aucune des fonctions que tu listes n'entre dans le champ technique de WG. Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.

      Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.

      Donc oui, tu peux avoir un DHCP sur WG, ce serveur DHCP peut consulter un annuaire pour assigner les IP, tu peux utiliser TURN pour passer le double NAT et ensuite démarrer WG à travers le trou (et c'est même assez simple avec systemd d'ailleurs)

      Ce n'est pas le rôle de WG de faire ça (à la Unix-style: WG fait un seul truc et bien). D'ailleurs, je ne pense pas que OpenVPN ne le fasse aussi.

      • [^] # Re: Simple comme...

        Posté par 🚲 Tanguy Ortolo (site web personnel) le 23 août 2022 à 14:19. Évalué à 5.

        

        Vu que c'est level 3, aucune des fonctions que tu listes n'entre dans le champ technique de WG. Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.

        Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.

        Je ne pense pas non. Sans avoir essayé, il me semble qu'un interface de niveau 3, ça n'est justement pas un adaptateur virtuel semblable à une carte Ethernet, Wifi ou Bluetooth, mais un lien IP, comme peut l'être une interface PPP par exemple.

        Ça n'empêche pas en théorie de faire des choses comme de l'adressage dynamique, même si j'ai du mal à voir l'intérêt de la chose. En revanche, ça empêche certainement certains usages, par exemple la mise en place d'un proxy ARP ou NDP pour connecter plusieurs hôtes derrière un seul sans coopération de routage au niveau du serveur de VPN.

        • [^] # Re: Simple comme...

          Posté par xryl669 le 24 août 2022 à 10:23. Évalué à 1.

          

          Ça n'empêche pas en théorie de faire des choses comme de l'adressage dynamique, même si j'ai du mal à voir l'intérêt de la chose.

          Moi aussi, et c'est aussi l'avis de l'auteur. Mais malgré tout, il existe wg-dynamic pour la gestion des IP dynamiques.

          WG c'est plutôt comme un bridge à l'usage. Tu as ta carte Ethernet/Wifi connecté à l'internet et WG crée une interface virtuelle (wg0) avec une IP privée (type 10.x.x.x) et une règle de routage entre les réseaux de telle façon à ce que tu puisses parler, via ce réseau privé (10.x.x.x) aux autres membres du réseau (10.x.x.y et 10.x.x.z etc…).

          J'ai du mal à voir l'intérêt d'un proxy ARP ou NDP qui sont au niveau 2 (MAC) sur ce genre de montage, vu que ce genre de proxy sert justement lorsque tu n'as pas de table de routage (c'est quand même hachement plus simple de faire un ip route add via que d'avoir à mettre en place un proxy ARP). D'autant plus que l'ARP c'est du broadcast, donc pas top pour du VPN un peu étendu. Après si tu y tiens absolument, il y a OpenDaylight.

          • [^] # Re: Simple comme...

            Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 août 2022 à 11:50. Évalué à 3.

            

            La mise en place d'un proxy ARP ou NDP sert sur un réseau physique Ethernet ou Wifi dont tu n'es pas administrateur, lorsque :

            • tu ne peux pas connecter une autre adresse MAC que celle de ton ordinateur ;
            • tu as plusieurs interfaces réseau ;
            • tu veux connecter un ou plusieurs hôtes supplémentaire derrière ton poste ;
            • tu ne veux pas faire de NAT.

            Le principe est de faire croire au réseau que c'est ton interface réseau qui a plusieurs adresses IP. Mais en réalité, tu routes tout le trafic qui leur est destiné vers les hôtes qui sont connecté sur un ou plusieurs de tes autres interfaces réseaux.

            C'est infaisable avec une interface qui n'a pas de niveau 2.

      • [^] # Re: Simple comme...

        Posté par Astaoth le 24 août 2022 à 22:34. Évalué à 2. Dernière modification le 24 août 2022 à 22:36.

        

        Tout dépend de quoi on parle. Si tu parles du protocole, oui ca n'a aucun rapport. Mais ici, je réponds à un commentaire qui parle de son utilisation en entreprise, ce qui sous-entend qu'on parle de l'implémentation officielle (qui est systématiquement reprise lorsque wireguard est intégré dans un équipement réseau).

        Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.

        Bah le fait que ca ne soit pas géré dans l'implémentation en fait, soit le sujet du commentaire.

        Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.

        Bah du coup non, vu que de base il gère une authentification. Et les adresses IP sont bien fixées dans la configuration logicielle, il n'y a pas de possibilité de faire d'adressage dynamique. Ca a d'ailleurs été un gros sujet pour les sociétés de VPN comme Nord ou Proton, qui ont dû faire leurs propres implémentations pour compenser ca, tout en restant compatible avec l'implémentation officielle.
        Encore une fois, je ne parle pas du protocole, mais de l'implémentation.
        Ah, et si je ne m'abuse, une interface ethernet ou wifi ne serait pas une interface de niveau 2 ? Il ne me semble pas qu'un tun ait une adresse MAC.

        Donc oui, tu peux avoir un DHCP sur WG, ce serveur DHCP peut consulter un annuaire pour assigner les IP

        Tu as manqué le point ici. Le but d'intégrer un annuaire dans un premier temps, c'est de gérer l'authentification de façon centralisée.

        Ce n'est pas le rôle de WG de faire ça

        C'est le rôle de l'implémentation.

        D'ailleurs, je ne pense pas que OpenVPN ne le fasse aussi.

        OpenVPN, tout comme IPSec Ikev2, intègre l'assignation d'adresses IP fixes ou dynamiques aux clients, la gestion de l'authentification des utilisateurs depuis un annuaire centrale, et supporte plutôt pas mal la traversée de NAT multiple.

        Petit point qui est passé à la trappe, Wireguard supporte mal les traversées multiples de NAT. Après plusieurs tests, quand il y en a plus qu'un, ca devient délicat.

        Emacs le fait depuis 30 ans.

    • [^] # Re: Simple comme...

      Posté par Buf (Mastodon) le 23 août 2022 à 12:57. Évalué à 6.

      

      Dire que c'est juste un jouet, c'est se méprendre complètement sur les buts du projet.

      Wireguard ne cherche pas à être une solution clé en main pour du VPN d'entreprise. Le but est de fournir un protocole robuste et efficace, ainsi qu'une API pour permettre à des outils externes de fournir les fonctionnalités avancées. On trouve par exemple Tailscale, qui propose une solution complète avec toutes les fonctionnalités que tu mentionnes. Il y aussi pas mal de projets libres, avec différents niveaux d'avancement.

      • [^] # Re: Simple comme...

        Posté par Astaoth le 24 août 2022 à 22:20. Évalué à 3.

        

        Marrant cette levée de boucliers. Je réponds bien à un commentaire qui parle de son utilisation en entreprise, pas au journal. Donc le propos ici est bien son utilisation en entreprise (et du coup de son implémentation en fait), pas du protocole.

        J'entends bien que le but de l'implémentation n'est pas d'être un VPN d'entreprise, mais elle manque d'énormément de choses pour faire autre chose que des setup des plus basiques, d'où sa qualification de jouet, notamment par rapport à un OpenVPN ou un IPSec. En l'état, je lui préfère un bon vieux tunnel SSH, bien plus agréable à gérer et plus robuste sur les traversées de NAT.

        Emacs le fait depuis 30 ans.

        • [^] # Re: Simple comme...

          Posté par jidea le 25 août 2022 à 09:25. Évalué à 1.

          

          En l'état, je lui préfère un bon vieux tunnel SSH, bien plus agréable à gérer et plus robuste sur les traversées de NAT.

          Je ne vois pas en quoi c'est plus simple, puisque l'utilité n'est absolument pas la même. la consommation de ressources non plus d'ailleurs.
          Tu n'en as pas l'utilité, ça n'en fait pas pour autant un jouet, au contraire.

• # Aucun besoin de bricoler la liste des serveurs DNS de la racine

  Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) le 22 août 2022 à 18:55. Évalué à 8.

  

  Téléchargement de la liste des serveurs DNS racines 
  

  C'est inutile, Unbound (comme BIND et les autres) a tout ce qu'il faut (faites un strings sur /usr/bin/unbound si vous ne me croyez pas) et, de toute façon, utilise le "priming" (RFC 8109). Intervenir sur cette liste n'est utile que si on veut utiliser une racine alternative.

  On peut utiliser ce script pour mettre à jours les serveurs DNS racines
  

  Même remarque ici.

  • [^] # Re: Aucun besoin de bricoler la liste des serveurs DNS de la racine

    Posté par Benoît Sibaud (site web personnel) le 23 août 2022 à 08:11. Évalué à 5.

    

    Parties retirées car elle téléchargeait depuis un site suspect. On retrouve la récupération des serveurs racine dans https://craighuther.com/2019/05/14/wireguard-setup-and-installation/ par exemple, mais je n'ai pas trouvé root-hints sur le site de wireguard, donc ça ne dit vraiment pas être indispensable.

• # Mauvais lien DKMS

  Posté par ff9097 le 23 août 2022 à 11:06. Évalué à 3.

  

  Le lien DKMS pointe vers une mauvaise page, voici la bonne : https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

  • [^] # Re: Mauvais lien DKMS

    Posté par Benoît Sibaud (site web personnel) le 23 août 2022 à 11:22. Évalué à 3.

    

    Corrigé, merci.

• # Documentation annexe

  Posté par ppnsph le 28 août 2022 à 07:17. Évalué à 3. Dernière modification le 28 août 2022 à 07:17.

  

  Pour compléter l'article, voici une base de documentation qui reprend de manière très claire (schémas + commandes) différentes possibilités d'implémentation :
  https://www.procustodibus.com/blog/

• # Reload

  Posté par jpmenil le 17 septembre 2022 à 16:47. Évalué à 1. Dernière modification le 17 septembre 2022 à 19:25.

  

  Petite commande utilse pour reloader la conf sans interruption (tire du manpage)

  The strip command is useful for reloading configuration files without disrupting active sessions:

  # wg syncconf wgnet0 <(wg-quick strip wgnet0)
  

• # Yunohost

  Posté par anubis le 21 septembre 2022 à 21:07. Évalué à 2.

  

  À noter que wireguard peut-être mis en oeuvre simplement via une app disponible dans Yunohost : https://github.com/YunoHost-Apps/wireguard_ynh

  aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.