NetMaker : tout connecter avec un VPN WireGuard

 (netmaker.io)
2 points par GN⁺ 2023-08-18 | 1 commentaires | Partager sur WhatsApp
  • Netmaker est une plateforme qui relie appareils, cloud, bureaux et environnements edge via des tunnels basés sur WireGuard, avec un contrôle d’accès granulaire pour fournir un accès réseau zero trust
  • L’éditeur met en avant des performances 10 à 20 fois supérieures aux alternatives grâce à WireGuard dans le kernel et à des relais co-localisés, tout en permettant de préserver la confidentialité des données via un déploiement on-premise et des relais dédiés
  • Parmi les principaux cas d’usage : accès des équipes à distance, interconnexion de réseaux de bureaux, gestion des appareils edge, remplacement des VPN legacy, hébergement sur sa propre infrastructure et connexion de workloads IA distribués
  • Avec Mesh VPN, la gestion des nœuds, le routage du trafic, les ACL et la gestion des utilisateurs, il est possible d’exploiter plusieurs réseaux virtuels séparés et d’appliquer OIDC, la 2FA et des politiques d’expiration de session
  • La configuration de WireGuard et des règles de routage s’effectue via le tableau de bord, la CLI, l’API et l’agent Netclient, ce qui permet de piloter un réseau overlay distribué dans l’état souhaité

L’approche de Netmaker pour le réseau sécurisé

  • Netmaker est une plateforme de réseau zero trust conçue pour réduire la complexité de configuration des VPN et permettre aux équipes de se connecter depuis n’importe où en quelques minutes
  • La solution s’appuie sur la simplicité et la rapidité de WireGuard pour connecter en toute sécurité appareils, clouds et sites
  • L’entreprise indique être utilisée par plus de 500 sociétés dans le monde
  • Trois avantages clés sont mis en avant
    • Vitesse : grâce à WireGuard dans le kernel et à des relais co-localisés, la solution serait 10 à 20 fois plus rapide que les alternatives
    • Confidentialité : les options on-premise et les relais dédiés permettent de conserver les données dans son propre environnement
    • Contrôle : la plateforme offre une grande flexibilité pour déployer, configurer et automatiser les réseaux et les endpoints

Principaux cas d’usage

  • Accès sécurisé pour les équipes à distance

    • Permet à des équipes distribuées d’accéder de manière fiable aux ressources de l’entreprise
    • Met l’accent sur la réduction de la complexité liée à l’exploitation des VPN traditionnels

  • Interconnexion de réseaux de bureaux

    • Relie plusieurs sites avec un réseau sécurisé et performant
    • Peut évoluer avec la croissance de l’activité

  • Gestion de flottes et d’appareils edge

    • Permet de déployer, superviser et protéger centralement des milliers d’appareils edge répartis sur plusieurs sites
    • Prend en charge l’automatisation de la connectivité et le maintien de politiques de sécurité cohérentes depuis un tableau de bord unique

  • Remplacement des VPN legacy

    • Propose un réseau mesh allant au-delà des limites des VPN existants
    • Met en avant de meilleures performances, une gestion simplifiée et une sécurité renforcée

  • Héberger Netmaker sur sa propre infrastructure

    • Un déploiement on-premise permet de garder un contrôle total sur l’infrastructure réseau
    • Les données sensibles restent dans votre environnement, sur votre propre matériel, afin de répondre à des exigences strictes de conformité

  • Sécurisation réseau de l’infrastructure IA

    • Relie des workloads IA distribués entre cloud et GPU on-premise avec une sécurité zero trust
    • Convient aux équipes ML qui exécutent des tâches d’entraînement sur plusieurs fournisseurs cloud ou dans des environnements hybrides
    • Les usages incluent le transfert de modèles, l’apprentissage distribué et la protection de l’inférence à grande échelle

Mesh VPN et segmentation réseau

  • L’architecture multi-réseaux de Netmaker permet de créer plusieurs réseaux virtuels isolés et de les administrer depuis un point central
  • Les entreprises B2B peuvent gérer plusieurs clients depuis un seul compte tout en isolant et sécurisant le trafic
  • La séparation est aussi possible selon les cas d’usage
    • accès Internet sécurisé
    • gestion des appareils edge
    • configuration d’un mesh de serveurs cloud
    • accès distant aux bureaux

Nœuds, routage et contrôle d’accès

  • Trois options de client VPN permettent d’ajouter des endpoints au réseau
    • Installer netclient sur Linux, Docker, Windows et Mac comme agent headless pour configurer des nœuds pair à pair
    • Intégrer au réseau des appareils compatibles WireGuard, y compris des routeurs, à l’aide de simples fichiers de configuration WireGuard
    • Exécuter le Remote Access Client sur desktop ou mobile pour fournir une application d’accès distant destinée aux utilisateurs, avec authentification et expiration de session
  • Le routage du trafic et les ACL contrôlent les chemins réseau et les autorisations
    • Un nœud peut être configuré en Hub pour relayer les connexions
    • Un nœud peut être configuré en Forwarder pour fournir un accès distant à des réseaux externes comme un bureau, un cloud ou Internet
    • Des ACL peuvent être définies au niveau du réseau pour gérer les permissions entre appareils et mettre en œuvre une architecture zero trust
  • La gestion des utilisateurs couvre l’onboarding des utilisateurs finaux, l’attribution des rôles et permissions, ainsi que l’octroi de l’accès réseau
    • Intégration possible avec des fournisseurs d’authentification compatibles OIDC
    • La 2FA peut être activée
    • Des règles d’expiration de session peuvent être définies

Flux d’exploitation et montée en charge

  • Les opérateurs se connectent au tableau de bord ou à la CLI pour créer un réseau, puis ajoutent des hôtes avec Netclient
  • Ils définissent l’état réseau souhaité à l’aide de fonctionnalités comme Egress, Ingress, Relays et ACL
  • Cet état cible est transmis aux agents Netclient exécutés sur les appareils et les serveurs
  • Netclient configure alors WireGuard et les règles de routage afin d’atteindre l’état final souhaité
  • Une fois la configuration terminée, le réseau overlay distribué entre en fonctionnement
  • La plateforme peut être enrichie d’un networking de niveau enterprise via l’API
  • L’option open source s’adresse aux particuliers et aux petites équipes, avec un usage personnel illimité et les fonctions de sécurité essentielles

À lire aussi

1 commentaires

 
GN⁺ 2023-08-18
Avis sur Hacker News

  • Article lié publié au début de l’année : https://news.ycombinator.com/item?id=35584533
    L’auteur comparait Yggdrasil, tinc, Tailscale, Zerotier, Netmaker et Nebula, et finissait par préférer Yggdrasil. C’est justement cette comparaison qui m’a fait regarder Netmaker, et après l’avoir fait tourner sans problème pour des essais, j’ai fini par le préférer davantage. J’aimerais bien que Netmaker soit de nouveau couvert.
    Le projet évolue vite, donc il faut suivre les changements de configuration à chaque release, mais comme il s’agit encore de releases 0.xx, c’est assez prévisible.
    Netmaker est, en gros, du WireGuard standard avec de l’ajustement de routes et du STUN/TURN par-dessus, ce qui rend son architecture assez compréhensible ; la documentation est aussi rédigée en pensant aux utilisateurs qui font du self-hosting, ce qui me semble être un bon signe.

    • C’est bien que la documentation vise les utilisateurs en self-hosting, mais au moment de la rédaction, Netmaker n’est pas FOSS : https://github.com/gravitl/netmaker/blob/16d5b5807/LICENSE.txt
    • J’aimerais aussi ajouter Netbird à cette liste. Après avoir essayé tous les produits ci-dessus, c’est finalement Netbird que j’ai fini par utiliser.
      https://netbird.io/
    • Quand on se connecte à un VPN depuis un environnement où seules les sorties 80/443 sont autorisées, comme dans un réseau d’entreprise, l’utilisation d’un relais est courante. Même si l’on n’utilise pas toujours un relais, on peut y avoir recours pour certaines connexions au cours de la journée, et s’il existe une vulnérabilité, une seule connexion peut suffire à compromettre la sécurité.
    • Même en lisant le README sur GitHub, il n’est toujours pas clair si l’ajustement de routes proxifie tout le trafic via ses propres serveurs.

  • La liste des fonctionnalités m’a fait penser à Tailscale, donc j’ai cherché et je suis tombé sur cette comparaison sur leur site : https://www.netmaker.io/resources/tailscale-vs-zerotier
    Dans le tableau comparatif en bas, les éléments mis en avant pour se différencier de Tailscale sont l’impossibilité de l’auto-héberger (en ignorant l’existence de headscale) et la prise en charge limitée de WireGuard. Ce dernier point semble faire référence à la configuration par défaut de Tailscale où tous les nœuds se connectent entre eux, alors que NetMaker permettrait d’autres topologies réseau.
    Mais avec les ACL de Tailscale, on peut aussi restructurer le réseau comme on le souhaite, donc je ne sais pas si cette critique est encore valable. L’affirmation selon laquelle « les données passent assez souvent par les serveurs relais DERP » me paraît aussi douteuse. Cela ne concerne que les réseaux où, malgré STUN/TURN, le trafic UDP ne peut pas circuler entre clients, ce qui est en pratique assez rare.
    Les seuls avantages que je vois sont que le plan gratuit de NetMaker est plus généreux, et qu’il utilise le module noyau WireGuard quand c’est possible. Je ne comprends pas pourquoi ils ne mettent pas plutôt cela en avant.

    • À la lecture de la comparaison, WireGuard est désormais le minimum attendu, et l’affirmation selon laquelle Netmaker serait plus rapide parce qu’il utilise WireGuard dans le noyau ne tient pas dans toutes les configurations système, et certainement pas sur macOS.
      La flexibilité semble similaire à celle de Tailscale, avec l’impression qu’ils marketent différemment les cas d’usage courants que sont les passerelles d’entrée et de sortie. Avec Tailscale aussi, on peut créer une topologie réseau via les ACL.
      Côté prix, l’offre de Tailscale est également suffisante pour la plupart des utilisateurs, et les limites sont plutôt « souples ». Je paie 45 dollars par an non pas parce que c’est gratuit, mais parce que je veux quelque chose de durable. Je cherche une raison de changer, mais je ne l’ai pas encore trouvée.
    • À ma connaissance, Tailscale ne fournit pas de serveur de contrôle auto-hébergé officiel. Cela me semble être un avantage de NetMaker.
      En revanche, je ne vois pas de fonctionnalité équivalente à tailnet lock.
    • Je me demande si l’argument de Netmaker affirmant une performance 5 fois supérieure à Tailscale repose sur le module noyau. Je n’ai pas vraiment mesuré les performances de Tailscale, mais si ce n’est pas une différence de performance d’infrastructure, je vois mal comment ils pourraient avancer une telle affirmation autrement.
    • Netmaker propose des Client Gateways, qui permettent de générer et modifier des fichiers de configuration WireGuard bruts. C’est très utile pour l’intégration avec des configurations WireGuard personnalisées.
      Par exemple, on peut créer un fichier de configuration, le modifier, puis le mettre dans un routeur pour obtenir immédiatement une connexion site à site : https://www.netmaker.io/features/ingress
    • Il vaut la peine d’examiner soi-même à quelle fréquence le trafic est relayé avec Tailscale. Je n’ai pas de chiffres, mais il est déjà arrivé qu’un utilisateur ayant une latence très élevée avec Tailscale analyse son trafic et découvre qu’il était relayé jusqu’à l’autre bout du pays.
      La traversée NAT de Tailscale est excellente, mais cela reste un facteur à prendre en compte.

  • C’est peut-être une question naïve, mais je me demande quels sont les avantages de ces produits par rapport à la configuration directe d’un serveur WireGuard standard sur quelque chose comme OpenBSD. Je ne suis pas spécialiste réseau, mais la configuration manuelle m’a semblé assez simple. Si ces produits offrent plus de fonctionnalités, j’aimerais savoir lesquelles.

    • Si vous essayez de créer un réseau maillé avec WireGuard seul, vous vous heurtez vite à une explosion combinatoire.
      Si vous avez 10 nœuds et que vous ajoutez un 11e nœud, il faut mettre à jour les 10 nœuds existants.
      Ces projets automatisent la configuration des nœuds. Il suffit de configurer le nouveau nœud, et les autres nœuds apprennent son existence.
    • En résumé, ils évitent d’avoir à configurer WireGuard soi-même, et aident aussi à satisfaire diverses abréviations de conformité réglementaire.

  • Les entreprises ne feraient-elles pas mieux d’investir davantage dans l’amélioration de WireGuard et d’autres solutions open source ?
    Je ne comprends pas comment on peut confier à une autre entreprise un service de sécurité aussi important qu’un VPN. Et si l’un de ses employés vous vendait au plus offrant ?
    Quand on décide de faire soi-même ou d’acheter, on oublie souvent que si l’on ne possède pas les clés de sa propre porte, on risque de se retrouver enfermé par quelqu’un d’autre.

    • Le créateur de WireGuard a déjà clairement dit que les fonctionnalités d’administration comme l’authentification des utilisateurs, la configuration et l’ajustement automatiques, ou les ACL, sortaient du périmètre du projet WireGuard.
      L’idée était de le garder aussi simple que possible, et de laisser à des tiers le soin de créer des plateformes VPN utilisant WireGuard.
    • À la question de savoir comment faire confiance à une autre entreprise pour un service de sécurité VPN critique, certains répondent en gros qu’il suffit de regarder le Magic Quadrant de Gartner et de choisir ce qui se trouve en haut à droite.
      N’importe quelle solution VPN peut avoir des vulnérabilités, et si c’est la même entreprise, elle la maintiendra à jour. Beaucoup de pare-feu matériels disposent d’ASIC pour accélérer le trafic VPN, et cela peut être nécessaire pour gérer le volume de trafic d’une entreprise.
    • WireGuard est un protocole qui chiffre et transmet directement des bits au niveau L3. Il est logique de le faire bien faire une chose simple.

  • Il y a encore un désagrément que je n’ai pas réussi à résoudre avec WireGuard. Sur mon téléphone, je veux accéder à mon homelab via le serveur WireGuard de la maison, et envoyer le reste du trafic vers un VPN WireGuard externe.
    La plage IP de l’homelab est du genre 10.10.0.0/24, et le VPN externe utilise une autre plage, mais WireGuard ne semble pas apprécier ce type de configuration.
    L’alternative serait d’envoyer tout le trafic du téléphone vers la maison, puis que le routeur domestique le fasse sortir via le VPN externe, mais ma connexion Internet à la maison n’est pas bonne et je ne veux pas qu’elle devienne un goulot d’étranglement.
    En parcourant rapidement la documentation de NetMaker, je n’ai pas trouvé de section qui montre clairement comment configurer le VPN, ni comment s’appelle la configuration consistant à faire le pont entre plusieurs réseaux WireGuard.

    • Je serais curieux de savoir à quoi ressemble la configuration actuelle.
      Est-ce qu’il y a une seule interface/configuration WireGuard sur le téléphone, avec deux pairs ? Par exemple, le pair WireGuard de la maison aurait AllowedIPs à 10.10.0.0/24, et le pair VPN distant à 0.0.0.0/24 ?
      Je me demande aussi si tu as essayé d’exclure le CIDR du WireGuard domestique des AllowedIPs du VPN distant. Pas avec une seule entrée 0.0.0.0/24, mais avec plusieurs entrées excluant le CIDR local.
    • Cela devrait être possible avec deux pairs. Il faudra toutefois peut-être définir explicitement le routage.
      Pour le premier pair, c’est simple si l’on met AllowedIPs à 10.10.0.0/8 ; pour le second, comme il doit router tout le reste du trafic, il faut davantage de configuration.
      Pour un exemple listant toutes les plages non RFC1918, voir cette réponse : https://serverfault.com/a/304791
      Je m’attendrais à devoir mettre ces plages dans les AllowedIPs du pair qui doit router vers l’Internet public.
    • Netmaker peut aider. Dans le réseau Netmaker 10.10.0.0/24, il suffit de configurer une Egress Gateway vers 0.0.0.0/0 en tant que VPN Internet.
      Netmaker gère les règles de routage différemment et a été conçu pour être compatible avec ce type de configuration. Cela dit, avec WireGuard classique, ce genre de configuration est aussi assez stable d’après mon expérience, donc je suis un peu surpris que ce problème existe.
    • Si le serveur WireGuard de la maison tourne sous Linux, on peut l’implémenter en ajoutant une deuxième table de routage et une règle de routage.
    • Pourquoi ne pas garder une connexion WireGuard permanente entre la maison et le serveur WireGuard externe, et faire en sorte que le téléphone ne se connecte qu’au serveur externe ?
      Ainsi, le trafic destiné à la maison serait routé via la connexion WireGuard vers la maison, et le reste du trafic sortirait directement depuis le serveur externe.

  • J’utilise Netmaker depuis quelques mois et c’est excellent. Je m’en sers comme outil de gestion de VPN bastion pour tous mes environnements.
    La seule chose que je n’ai pas encore réussi à faire, c’est le forwarding complet de 0.0.0.0. D’après la documentation, c’est possible, mais ce ne semble pas être un cas d’usage courant, et à chaque tentative j’ai des blocages. En général, j’ai dû utiliser sshuttle.
    À part ça, c’est vraiment très bien.

    • Je suis curieux de connaître la configuration d’hébergement du serveur. Est-ce que tu exposes le bastion Netmaker à l’Internet public pour tous les VPC, avec le bastion placé hors des VPC ?
      Quand je l’ai configuré, c’est ce qu’on m’a recommandé, mais j’ai aussi envisagé de placer le bastion dans le VPC et de l’exposer à Internet.
    • Quand tu utilises 0.0.0.0, est-ce que tu y accèdes via des external clients, ou avec le netclient standard ?
    • Je me demande si c’est pour un réseau de bureaux ou pour une infrastructure serveur.
      Je serais aussi curieux de savoir si tu l’as comparé à d’autres produits, et pourquoi tu as choisi Netmaker.
    • Tu pourrais essayer le clamping MSS.

  • Netmaker est un bon produit et bénéficie aussi du soutien de Y Combinator. Comme Tailscale, il est basé sur WireGuard, et semble surtout axé sur les usages avec Kubernetes.
    À mon avis, il est meilleur que d’autres solutions de réseau zero trust parce qu’il propose à la fois des ACL intégrées, des fonctionnalités WireGuard/VPN traditionnelles, et un overlay maillé P2P chiffré.
    Zerotier ou Tailscale sont peut-être plus faciles à prendre en main, mais NetMaker vaut la peine d’être suivi. J’ai rencontré le fondateur à la KubeCon l’an dernier ; il était accessible et sympathique. Si vous avez des questions ou des inquiétudes précises, vous pouvez le contacter directement.

    • Tailscale est plutôt bon.
      Je me demande comment il faudrait faire pour relier les deux réseaux, tailnet et netmaker-net.

  • En fouillant le dépôt GitHub, j’ai été assez déçu par le manque de fichiers _test.go. Pour un produit de sécurité, j’ai peur que de mauvaises choses arrivent.

    • La plupart des tests sont effectués sous forme de tests d’intégration dans un autre dépôt.

  • Je me suis inscrit à quelques outils de ce genre, et je préfère Netmaker. Je suis peut-être biaisé, mais j’ai l’impression que sa façon de présenter la configuration est facile à comprendre.

    • Je serais curieux de savoir lesquels tu as essayés et ce que tu en as pensé pour chacun.
      Je n’ai essayé qu’un seul produit, mentionné plusieurs fois par des gens en qui j’ai confiance sur HN et ailleurs, mais les retours des utilisateurs de HN sur d’autres services m’intéressent.

  • J’utilise Netmaker et netclient dans un cluster Kubernetes pour accéder à tous les pods k8s via des tunnels WireGuard sécurisés
    Plus besoin de se soucier des certificats SSL pour les tableaux de bord d’administration comme Longhorn, Pihole, Portainer ou Linkerd. Plus besoin non plus de faire du port-forwarding k8s à chaque fois que l’on veut accéder à un service précis dans le réseau du cluster
    Pour un accès réseau au cluster à la fois sûr et gérable, je pense que la combinaison Netmaker et Kubernetes est difficile à battre