Wireguard Hub

Ist das nicht fast dasselbe wie Tailscale / Headscale machen?

Wobei der WG Kram ja nur einen Bruchteil der Funktionalität ausmacht.

Das ist so oder so immer Default und müsstest du ja am Client immer explizit konfigurieren! Der Responder mit /32er Host IP fehlt in der o.a. Konfig. Thema Cryptokey Routing...
Wireguard Tutorial oder ein Hub and Spoke Tutorial lesen hilft! 😉

Habe das mit OPNsense realisiert und verwende für das Routing BGP. Dazu setze ich zusätzlich auf das loopback noch eine Peer Adresse die per statischer Route jeweils an den Endpunkten konfiguriert wird und auf das Tunnel-Interface verweist. Somit kann ich teilweise ein Mesh aufbauen über mehrere verschiedene Routen. Allerdings muss man aufpassen, da es ja in der Natur von BGP liegt das asynchron Routing betreiben will, kann es sein das Verbindungen nicht funktionieren. Weil die Firewall zwar im Prinzip die Pakete erlaubt, aber keine SYN-Pakete der Verbindung sieht, die nämlich eventuell einen anderen Weg genommen haben. Derzeit behelfe ich mir damit das ich jeweils die Pfade mit unterschiedlichen Gewichtungen verteile über Route Maps und nur bei Ausfall eines Pfades eine andere Route verwendet wird. Funktioniert ansonsten einwandfrei. Wesentlich performanter als IPsec oder OpenVPN.

<OT>Deshalb wäre OSPF bei Peer bezogenen VPNs wie z.B. WG immer die bessere Wahl. Da wäre das kein Thema.
Das es performanter sein soll als IPsec ist Unsinn. Die liegen annähernd gleich auf sofern man AES-NI verwendet. OpenVPN ist wegen seines Single Threadings und der daraus resultierenden mickrigen Skalierbarkeit da weit abgeschlagen, das ist richtig! Versteht man den Kollegen @Spirit-of-Eli richtig will er aber ja gerade kein Mesh und kein Client Any zu Any!

Dieser Artikel sagt in Bezug auf die Performance was anderes:

zenarmor.com/docs/de/netzwerksicherheitstutorials/ipsec-vs-wireg ...

Bei AES mag das vielleicht sein, aber wie du weißt verwendet das Wireguard nicht. Du kannst ja mal bei IPsec Poly1305 oder ChaCha20 verwenden. Das wäre vergleichbar und prophezeie ich dir jetzt schon das Wireguard jedes IPsec ganz alt aussehen lässt. Intel Quick Assist kann vielleicht noch einen Performance-Schub bei IPsec bringen. Aber find erstmal einen Firewall-Hersteller der diesen Treiber oder diese Technologie verwendet. BSD und Linux haben zumindest mal die Treiber an Board.

Auch noch interessanter Artikel:
geekbundle.org/wireguard-ipsec-vpn-performance/

Dort wird im Fazit zwar darauf hingewiesen das Wireguard schneller ist, aber die Performance vernachlässigbar. Spürbarer Unterschied im Retry Count und das ist eben der Unterschied was das "Erlebnis" spürbar flüssiger macht.

Warum nicht?

Tailscale ist die kommerzielle Variante mit einem guten Anteil kostenloser Funktionen,
Headscale das OpenSource gegenstück zum selber hosten.

Ist ganz interessant mehrere Geräte über WG zu verbinden bzw. bestimmte Services für die Clients freizugeben.

Kannst ja mal durchlesen

Es ist da wohl deutlich sinnvoller die offizielle Stellungnahme zu lesen:
wireguard.com/performance/
Der Unterschied ist dort nur marginal.
Desweiteren darf man nicht außer Acht lassen das WG keine Authentisierungsoptionen supportet wie eine Zertifikats Absicherung der Responder, Radius usw. Eine großes Manko für eine Enterprise Lösung, denn so kann jedem Client ein x-beliebiger Fake Server untergeschoben werden. Dazu kommen noch andere Nachteile was Skalierung usw. anbetrifft. Aber wer weiss...das Protokoll ist ja noch sehr jung...

Nein, das brauchst du nur dann wenn du eine Any zu Any Connectivity der Clients willst. Das hast du aber oben ja als Vorgabe kategorisch ausgeschlossen und dann hat jeder Client lediglich nur den Peer auf den Hub (Responder, Server)
Man muss lediglich NUR am Hub den Peer eintragen, niemals aber am Client. Die Client Konfig bleibt unter den o.a. Voraussetzungen für jeden Client immer gleich. Von der individuellen Client IP und Private Key einmal abgesehen.
Dort muss niemals etwas geändert werden wenn Clients dazukommen

Und auch wenn, dann müsste man niemals bei jedem Client etwas ändern sofern man eine geschickte und vorausschauende IP Adressierung des internen IP Netzes benutzt.
Gesetzt den Fall man nutzt dafür ein /24er Netz (10.10.10.0) dann erhält der Server z.B. die .1 und die Client Adressierung startet bei der .129.
Den Clients gibt man dann unter "Allowed IPs" außer der obligatorischen /32 des Resonders (Hub) zusätzlich die 10.10.10.128/25 mit so das auch aller Client Traffic in den Tunnel geroutet wird. Hat man Clients die niemals erreicht werden sollen wie Router usw. kommen die halt in das "untere" /25er Teilnetz. Die Magic vom Cryptokey Routing...
Am Client muss man niemals was fummeln wenn mehr oder weniger Clients hinzukommen.

Hi,

Ich werfe hier mal Netbird in den Raum. : github.com/netbirdio/netbird
Du kannst es auf deiner Hardware oder in einer VM(Docker) installieren und alles über eine Web-UI managen.
Acl, Ports, Routung ...

Ich nutze es seit einem Jahr und bin sehr zufrieden.

Hat der TO oben mit der Tailscale Thematik in sehr weiser Voraussicht schon ausgeschlossen. Eine Enterprise VPN Lösung mit einem Cloud Dienstleister zu realisieren erfordert einem immensen Vertrauensvorschuss in dessen Verwaltung und Infrastruktur. Normalerweise immer ein absolutes NoGo in einer Enterprise Umgebung mit schützenswerten Daten. Allein schon aus DSGVO Sicht in der EU.