NetMaker: Alles mit WireGuard VPN verbinden

 (netmaker.io)
2 Punkte von GN⁺ 2023-08-18 | 1 Kommentare | Auf WhatsApp teilen
  • Netmaker ist eine Plattform, die Geräte, Cloud, Büros und Edge-Umgebungen mit WireGuard-basierten Tunneln verbindet und mit fein granularer Zugriffskontrolle Zero-Trust-Network-Access bereitstellt
  • Es betont, mit Kernel-WireGuard und Co-located Relays 10- bis 20-mal schneller als Alternativen zu sein, und ermöglicht mit On-Premises-Bereitstellung und dedizierten Relays den Schutz der Datenprivatsphäre
  • Zu den wichtigsten Anwendungsfällen zählen sicherer Zugriff für Remote-Teams, die Zusammenführung von Büronetzwerken, Edge-Device-Management, der Ersatz von Legacy-VPNs, das Hosting auf eigener Infrastruktur und die Verbindung verteilter AI-Workloads
  • Mit Mesh VPN, Node-Management, Traffic-Routing, ACLs und Benutzerverwaltung lassen sich mehrere virtuelle Netzwerke getrennt betreiben und OIDC, 2FA sowie Regeln für den Sitzungsablauf anwenden
  • Über Dashboard, CLI, API und den Netclient-Agenten werden WireGuard- und Routing-Regeln konfiguriert, sodass sich verteilte Overlay-Netzwerke im gewünschten Zustand verwalten lassen

Netmakers Ansatz für sicheres Networking

  • Netmaker ist eine Zero-Trust-Networking-Plattform, die komplexe VPN-Konfigurationen reduziert und es Teams ermöglicht, sich von überall innerhalb weniger Minuten zu verbinden
  • Im Fokus steht, auf Basis der Einfachheit und Geschwindigkeit von WireGuard Geräte, Cloud und Standorte sicher zu verbinden
  • Nach eigenen Angaben wird es von mehr als 500 Unternehmen weltweit genutzt
  • Es nennt drei zentrale Vorteile
    • Geschwindigkeit: Mit Kernel-WireGuard und Co-located Relays sei es 10- bis 20-mal schneller als Alternativen
    • Privatsphäre: Mit On-Premises- und dedizierten Relay-Optionen können Daten in der eigenen Umgebung bleiben
    • Kontrolle: Es bietet eine flexible Plattform zur Bereitstellung, Konfiguration und Automatisierung von Netzwerken und Endpunkten

Wichtige Anwendungsfälle

  • Sicherer Zugriff für Remote-Teams

    • Unterstützt verteilte Teams dabei, zuverlässig auf Unternehmensressourcen zuzugreifen
    • Der Schwerpunkt liegt darauf, die Komplexität klassischer VPN-Betriebsmodelle zu verringern

  • Zusammenführung von Büronetzwerken

    • Verbindet mehrere Standorte mit sicherem und leistungsfähigem Networking
    • Lässt sich passend zum Unternehmenswachstum skalieren

  • Verwaltung von Flotten und Edge-Devices

    • Tausende Edge-Devices an verteilten Standorten lassen sich zentral bereitstellen, überwachen und absichern
    • Unterstützt die Automatisierung von Verbindungen und die Durchsetzung konsistenter Sicherheitsrichtlinien über ein einziges Dashboard

  • Ersatz für Legacy-VPNs

    • Bietet Mesh-Networking, das über die Grenzen bestehender VPNs hinausgeht
    • Stellt bessere Performance, einfachere Verwaltung und starke Sicherheit in den Vordergrund

  • Hosting von Netmaker auf eigener Infrastruktur

    • Mit einer On-Premises-Bereitstellung lässt sich die Netzwerkinfrastruktur vollständig kontrollieren
    • Sensible Daten können in der eigenen Umgebung verbleiben, während strenge Compliance-Anforderungen auf eigener Hardware erfüllt werden

  • Netzwerksicherheit für AI-Infrastruktur

    • Verbindet über Cloud und On-Premises-GPUs verteilte AI-Workloads mit Zero-Trust-Sicherheit
    • Geeignet für ML-Teams, die Trainingsjobs über mehrere Cloud-Anbieter oder in hybriden Umgebungen ausführen
    • Umfasst Anwendungsfälle wie Modellübertragung, verteiltes Training und den Schutz großskaliger Inferenz

Mesh VPN und Netzwerksegmentierung

  • Netmakers Multi-Network-Design ermöglicht es, mehrere getrennte virtuelle Netzwerke zu erstellen und zentral zu verwalten
  • B2B-Unternehmen können mehrere Kunden in einem einzigen Account verwalten und dabei den Traffic trennen und absichern
  • Auch eine Trennung nach Anwendungsfall ist möglich
    • Sicherer Internetzugang
    • Verwaltung von Edge-Devices
    • Aufbau eines Cloud-Server-Meshs
    • Remote-Zugriff auf Büros

Nodes, Routing und Zugriffskontrolle

  • Es gibt drei Optionen für VPN-Clients, um Endpunkte dem Netzwerk hinzuzufügen
    • netclient wird unter Linux, Docker, Windows und Mac als Headless-Agent installiert, um Peer-to-Peer-Nodes zu konfigurieren
    • Mit einfachen WireGuard-Konfigurationsdateien lassen sich WireGuard-kompatible Geräte einschließlich Routern in das Netzwerk integrieren
    • Der Remote Access Client läuft auf Desktop oder Mobilgeräten und bietet eine Remote-Zugriffsanwendung für Benutzer mit Authentifizierung und Sitzungsablauf
  • Traffic-Routing und ACLs steuern Netzwerkpfade und Berechtigungen
    • Nodes können als Hub konfiguriert werden, um Verbindungen weiterzuleiten
    • Nodes können als Forwarder konfiguriert werden, um Remote-Zugriff auf externe Netzwerke wie Büro, Cloud oder Internet bereitzustellen
    • ACLs im Netzwerk definieren Berechtigungen zwischen Geräten und setzen eine Zero-Trust-Architektur um
  • Die Benutzerverwaltung umfasst das Onboarding von Endbenutzern, die Zuweisung von Rollen und Berechtigungen sowie die Vergabe von Netzwerkzugriff
    • Integration mit OIDC-kompatiblen Authentifizierungsanbietern ist möglich
    • 2FA kann aktiviert werden
    • Regeln für den Sitzungsablauf lassen sich festlegen

Betriebsablauf und Skalierung

  • Administratoren melden sich im Dashboard oder in der CLI an, erstellen Netzwerke und fügen Hosts mit Netclient hinzu
  • Mit Funktionen wie Egress, Ingress, Relays und ACLs wird der gewünschte Netzwerkzustand definiert
  • Dieser definierte Zustand wird an die Netclient-Agenten auf Geräten und Servern übermittelt
  • Netclient konfiguriert WireGuard und Routing-Regeln entsprechend dem gewünschten Zielzustand
  • Nach Abschluss der Konfiguration ist das verteilte Overlay-Netzwerk betriebsbereit
  • Über die API lässt sich der Plattform Enterprise-Grade-Networking hinzufügen
  • Die Open-Source-Option richtet sich an Einzelpersonen und kleine Teams und umfasst unbegrenzte private Nutzung sowie zentrale Sicherheitsfunktionen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-18
Meinungen auf Hacker News

  • Ein verwandter Beitrag von Anfang des Jahres: https://news.ycombinator.com/item?id=35584533
    Der Autor verglich Yggdrasil, tinc, Tailscale, Zerotier, Netmaker und Nebula und bevorzugte am Ende Yggdrasil. Gerade dieser Vergleich brachte mich dazu, mir Netmaker anzusehen; ich habe es testweise ohne Probleme betrieben und es inzwischen noch mehr schätzen gelernt. Es wäre schön, wenn Netmaker erneut behandelt würde.
    Das Projekt bewegt sich schnell, sodass man bei jedem Release Konfigurationsänderungen nachvollziehen muss, aber da es noch ein 0.xx-Release ist, ist das erwartbar.
    Netmaker ist im Grunde normales WireGuard mit zusätzlicher Routenanpassung und STUN/TURN, daher lässt sich die Architektur gut nachvollziehen. Auch die Dokumentation ist mit Blick auf Self-Hosting-Nutzer geschrieben, was ich als gutes Zeichen sehe.

    • Es ist gut, dass die Dokumentation auf Self-Hosting-Nutzer ausgerichtet ist, aber zum Zeitpunkt des Schreibens war Netmaker keine FOSS-Software: https://github.com/gravitl/netmaker/blob/16d5b5807/LICENSE.txt
    • Ich würde dieser Liste auch Netbird hinzufügen. Nachdem ich alle oben genannten Produkte ausprobiert hatte, bin ich letztlich bei Netbird gelandet.
      https://netbird.io/
    • In Umgebungen, in denen wie in Unternehmensnetzwerken nach außen nur 80/443 erlaubt ist, ist bei VPN-Verbindungen die Nutzung von Relays üblich. Selbst wenn nicht immer ein Relay verwendet wird, kann es bei manchen Verbindungen im Laufe des Tages zum Einsatz kommen; falls es eine Schwachstelle gibt, kann schon eine einzige Verbindung ausreichen, um die Sicherheit zu kompromittieren.
    • Auch nach dem Lesen des GitHub-README ist weiterhin unklar, ob die Routenanpassung den gesamten Traffic über eigene Server proxyt.

  • Die Funktionsliste erinnerte mich an Tailscale, also habe ich nachgesehen und auf der Website diesen Vergleich gefunden: https://www.netmaker.io/resources/tailscale-vs-zerotier
    In der Vergleichstabelle unten werden als Unterschiede zu Tailscale genannt, dass Self-Hosting nicht möglich sei (die Existenz von headscale wird ignoriert) und dass die WireGuard-Unterstützung eingeschränkt sei. Letzteres scheint sich auf die Tailscale-Standardeinstellung zu beziehen, bei der alle Nodes miteinander verbunden sind, und soll wohl bedeuten, dass NetMaker andere Netzwerkkonfigurationen ermöglicht.
    Allerdings lässt sich auch mit den ACLs von Tailscale das Netzwerk in die gewünschte Form bringen, daher weiß ich nicht, ob diese Kritik noch zutrifft. Auch die Behauptung, „Daten liefen ziemlich häufig über DERP-Relay-Server“, erscheint mir zweifelhaft. Das gilt nur für Netzwerke, in denen trotz STUN/TURN kein UDP-Traffic zwischen Clients fließt, was in der Praxis sehr selten ist.
    Als Vorteile finde ich eigentlich nur, dass NetMakers Free Plan großzügiger ist und nach Möglichkeit das WireGuard-Kernelmodul nutzt. Warum sie das nicht in den Vordergrund stellen, weiß ich nicht.

    • Dem Vergleich nach ist WireGuard inzwischen die Basis, und die Behauptung, Netmaker sei schneller, weil es Kernel-WireGuard nutzt, gilt nicht für jede Systemkonfiguration und insbesondere nicht unter macOS.
      Die Flexibilität wirkt ähnlich wie bei Tailscale; es fühlt sich an, als würden gängige Use Cases wie Egress-/Ingress-Gateways nur anders vermarktet. Auch bei Tailscale kann man mit ACLs Netzwerkformen abbilden.
      Beim Preis ist das Angebot von Tailscale für die meisten Nutzer ebenfalls ausreichend, und die Limits sind eher „weich“. Ich zahle 45 Dollar pro Jahr, nicht weil es nicht kostenlos ginge, sondern weil ich Nachhaltigkeit möchte. Ich suche nach einem Grund zum Wechseln, habe aber noch keinen gefunden.
    • Soweit ich weiß, bietet Tailscale keinen offiziellen selbst gehosteten Control Server an. Das wirkt wie ein Vorteil von NetMaker.
      Allerdings sehe ich dort keine Funktion, die tailnet lock entspricht.
    • Ich frage mich, ob Netmakers Behauptung von 5-facher Performance gegenüber Tailscale auf dem Kernelmodul beruht. Ich habe die Performance von Tailscale nicht sauber gemessen, aber wenn es nicht an Unterschieden in der Infrastruktur liegt, sehe ich kaum eine andere Möglichkeit, so eine Behauptung aufzustellen.
    • Netmaker hat Client Gateways, mit denen sich rohe WireGuard-Konfigurationsdateien erzeugen und bearbeiten lassen. Das ist sehr nützlich, wenn man eigene WireGuard-Konfigurationen integrieren will.
      Man kann zum Beispiel eine Konfigurationsdatei erstellen, anpassen und dann auf einen Router legen, und schon hat man eine Site-to-Site-Verbindung: https://www.netmaker.io/features/ingress
    • Es lohnt sich, selbst zu untersuchen, wie oft Traffic bei Tailscale über Relays läuft. Ich habe keine Zahlen, aber es gab einmal einen Nutzer mit sehr hoher Latenz bei Tailscale, der nach einer Traffic-Analyse feststellte, dass sein Traffic bis ans andere Ende des Landes relayed wurde.
      Tailscales NAT-Traversal ist hervorragend, aber es bleibt trotzdem ein Faktor, den man berücksichtigen sollte.

  • Das ist vielleicht eine dumme Frage, aber ich frage mich, welchen Vorteil solche Produkte gegenüber dem direkten Einrichten eines normalen WireGuard-Servers etwa auf OpenBSD haben. Ich bin kein Netzwerkexperte, aber die manuelle Einrichtung war ziemlich einfach. Falls diese Produkte mehr Funktionen bieten, wüsste ich gern, welche das sind.

    • Wenn man nur mit WireGuard ein Mesh-Netzwerk aufbaut, stößt man schnell auf eine kombinatorische Explosion.
      Wenn man 10 Nodes hat und eine 11. Node hinzufügt, muss man alle bestehenden 10 Nodes aktualisieren.
      Solche Projekte automatisieren die Node-Konfiguration. Man konfiguriert nur die neue Node, und die übrigen Nodes erfahren von deren Existenz.
    • Kurz gesagt: Man muss WireGuard nicht selbst konfigurieren, und es hilft außerdem dabei, diverse Compliance-Abkürzungen zu erfüllen.

  • Wäre es für Unternehmen nicht besser, mehr in die Verbesserung von WireGuard und anderen Open-Source-Lösungen zu investieren?
    Ich verstehe nicht, wie man einen so wichtigen Sicherheitsdienst wie ein VPN einem anderen Unternehmen anvertrauen kann. Was, wenn jemand aus dessen Belegschaft dich an den Meistbietenden verkauft?
    Bei der Entscheidung „selbst bauen oder kaufen“ scheint man oft zu vergessen, dass man Gefahr läuft, ausgesperrt zu werden, wenn man den Schlüssel zur eigenen Haustür nicht besitzt.

    • Die Person, die WireGuard entwickelt hat, hat klar gesagt, dass Management-Funktionen wie Benutzerauthentifizierung, automatische Einrichtung und Abstimmung sowie ACLs außerhalb des Projektumfangs von WireGuard liegen.
      Es soll so einfach wie möglich bleiben; VPN-Plattformen auf Basis von WireGuard wurden bewusst Drittanbietern überlassen.
    • Auf die Frage, wie man einen wichtigen VPN-Sicherheitsdienst einem anderen Unternehmen anvertrauen kann, wird manchmal nach dem Motto vorgegangen: Schau in den Gartner Magic Quadrant und nimm das, was rechts oben steht.
      Jede VPN-Lösung kann Schwachstellen haben, und beim selben Anbieter wird sie vermutlich aktuell gehalten. Viele Hardware-Firewalls haben ASICs zur Beschleunigung von VPN-Traffic, und je nach Umfang des Unternehmens-Traffics kann man so etwas brauchen.
    • WireGuard ist ein Protokoll, das Bits direkt auf Layer 3 verschlüsselt überträgt. Es ist richtig, es einfache Dinge gut machen zu lassen.

  • Es gibt eine Unbequemlichkeit, die ich mit WireGuard noch nicht gelöst habe. Auf dem Smartphone möchte ich über den WireGuard-Server zu Hause auf mein Homelab zugreifen und den restlichen Traffic über ein externes WireGuard-VPN schicken.
    Der IP-Bereich des Homelabs ist etwa 10.10.0.0/24, das externe VPN hat einen anderen Bereich, aber WireGuard scheint solche Konfigurationen nicht zu mögen.
    Die Alternative wäre, den gesamten Traffic des Smartphones nach Hause zu schicken und ihn dort vom Heimrouter über das externe VPN hinausleiten zu lassen, aber meine Internetverbindung zu Hause ist nicht gut, und ich möchte keinen Flaschenhals daraus machen.
    Beim groben Durchsehen der NetMaker-Dokumentation habe ich keine Stelle gefunden, die klar zeigt, wie man das VPN einrichtet oder wie diese Konfiguration zum Bridging mehrerer WireGuard-Netzwerke überhaupt genannt wird.

    • Mich würde interessieren, wie die aktuelle Konfiguration aussieht.
      Gibt es auf dem Smartphone ein WireGuard-Interface/eine Konfiguration mit zwei Peers? Also etwa beim Heim-WireGuard-Peer AllowedIPs = 10.10.0.0/24 und beim Remote-VPN-Peer 0.0.0.0/24?
      Mich würde auch interessieren, ob du versucht hast, das CIDR des Heim-WireGuard aus den AllowedIPs des Remote-VPN auszuschließen. Also nicht ein einzelnes 0.0.0.0/24, sondern mehrere Einträge, die das lokale CIDR ausnehmen.
    • Mit zwei Peers sollte das möglich sein. Allerdings muss man das Routing unter Umständen explizit definieren.
      Für den ersten Peer ist es einfach, AllowedIPs auf 10.10.0.0/8 zu setzen; beim zweiten Peer, der den ganzen restlichen Traffic routen soll, braucht es mehr Konfiguration.
      Ein Beispiel, das alle nicht zu RFC1918 gehörenden Bereiche auflistet, findet sich in dieser Antwort: https://serverfault.com/a/304791
      Ich würde erwarten, dass diese Bereiche in die AllowedIPs des Peers gehören, über den ins öffentliche Internet geroutet werden soll.
    • Netmaker könnte dabei helfen. Innerhalb des Netmaker-Netzwerks 10.10.0.0/24 kann man ein Egress Gateway für 0.0.0.0/0 zum Internet-VPN konfigurieren.
      Netmaker behandelt Routing-Regeln anders und ist so gebaut, dass es mit solchen Konfigurationen kompatibel ist. Allerdings sind solche Setups meiner Erfahrung nach auch mit normalem WireGuard ziemlich stabil, daher überrascht mich etwas, dass es hier ein Problem gibt.
    • Wenn der WireGuard-Server zu Hause unter Linux läuft, lässt sich das mit einer zweiten Routing-Tabelle und Routing-Policies umsetzen.
    • Könnte man nicht eine permanente WireGuard-Verbindung zwischen dem Zuhause und dem externen WireGuard-Server einrichten und das Smartphone nur mit dem externen Server verbinden?
      Dann könnte Traffic nach Hause über die WireGuard-Verbindung nach Hause geroutet werden, und der übrige Traffic direkt vom externen Server ins Internet gehen.

  • Ich nutze Netmaker seit einigen Monaten, und es ist großartig. Ich verwende es für Bastion-VPN-Management für alle Umgebungen.
    Was mir noch nicht gelungen ist, ist vollständiges 0.0.0.0-Forwarding. Laut Dokumentation soll es möglich sein, aber es scheint kein typischer Use Case zu sein, und bei meinen Versuchen kommt es immer zu Hängern. Meist musste ich sshuttle verwenden.
    Abgesehen davon ist es wirklich gut.

    • Mich würde interessieren, wie dein Server-Hosting aufgebaut ist. Setzt du für alle VPCs eine Netmaker-Bastion ins öffentliche Internet und platzierst die Bastion außerhalb der VPC?
      Als ich meine Umgebung eingerichtet habe, wurde mir das so empfohlen, aber ich habe auch geprüft, die Bastion in die VPC zu setzen und sie ins Internet zu exponieren.
    • Mich würde interessieren, ob du bei 0.0.0.0 über external clients zugreifst oder den normalen netclient verwendest.
    • Mich würde interessieren, ob es für ein Büronetzwerk oder für Server-Infrastruktur gedacht ist.
      Außerdem, ob du es mit anderen Produkten verglichen hast und warum du dich für Netmaker entschieden hast.
    • Du könntest MSS-Clamping ausprobieren.

  • Netmaker ist ein ordentliches Produkt und wird auch von Y Combinator unterstützt. Es basiert wie Tailscale auf WireGuard und scheint hauptsächlich auf den Einsatz mit Kubernetes ausgerichtet zu sein.
    Meiner Meinung nach ist es besser als andere Zero-Trust-Networking-Lösungen, weil es eingebaute ACLs, klassische WireGuard/VPN-Funktionen und ein P2P-verschlüsseltes Mesh-Overlay zusammen anbietet.
    Zerotier oder Tailscale sind vielleicht einfacher zu handhaben, aber NetMaker sollte man weiter im Blick behalten. Ich habe den Gründer letztes Jahr auf der KubeCon getroffen; er war zugänglich und ein netter Mensch. Wenn es konkrete Fragen oder Bedenken gibt, kann man ihn direkt kontaktieren.

    • Tailscale ist ziemlich gut.
      Ich frage mich, wie man zwei Netzwerke, tailnet und netmaker-net, miteinander verbinden sollte.

  • Beim Durchstöbern des GitHub-Repositories war ich ziemlich enttäuscht, weil es an _test.go-Dateien mangelt. Bei einem Sicherheitsprodukt habe ich Sorge, dass etwas Schlimmes passieren könnte.

    • Der Großteil der Tests wird als Integrationstests in einem anderen Repository durchgeführt.

  • Ich habe mich bei mehreren solchen Tools angemeldet, und Netmaker gefällt mir besser. Ich bin möglicherweise voreingenommen, aber ich habe den Eindruck, dass die Konfiguration verständlicher dargestellt wird.

    • Mich würde interessieren, welche du ausprobiert hast und wie du sie jeweils einschätzt.
      Ich habe nur ein Produkt ausprobiert, das von Leuten, denen ich auf HN und anderswo vertraue, mehrfach erwähnt wurde, aber mich interessieren die Erfahrungen von HN-Nutzern mit anderen Diensten.

  • Innerhalb eines Kubernetes-Clusters nutze ich Netmaker und netclient, um über sichere WireGuard-Tunnel auf alle k8s-Pods zuzugreifen.
    Bei Admin-Dashboards wie Longhorn, Pihole, Portainer und Linkerd muss ich mir keine Gedanken über SSL-Zertifikate machen. Auch k8s-Port-Forwarding ist nicht jedes Mal nötig, wenn ich auf bestimmte Services im Cluster-Netzwerk zugreifen will.
    Für einen sicheren und verwaltbaren Zugriff auf das Cluster-Netzwerk ist die Kombination aus Netmaker und Kubernetes meiner Meinung nach schwer zu schlagen.