Warum ich von Tailscale zu NetBird wechsle

Ich mag Tailscale. Ich nutze es seit Jahren, es ist absurd schnell eingerichtet und dieser Artikel wäre Quatsch, wenn ich etwas anderes behaupten würde. Tailscale hat für mich aber ein Problem, das ich nicht länger wegwinken kann: Ein US-Dienst sitzt im Kontrollpfad von Infrastruktur, die ich womöglich in einem deutschen NIS2- oder KRITIS-Audit verteidigen muss.

Ja, der eigentliche Datenverkehr ist Ende-zu-Ende verschlüsselt. Nein, Tailscale kann nicht einfach den Traffic zwischen meinen Peers mitlesen. Das beantwortet aber nicht die ganze Auditfrage. Die mandantenfähige Control Plane verteilt öffentliche Schlüssel und Netzwerkrichtlinien und speichert Geräte-, Benutzer-, Routing- und Verbindungsmetadaten. Laut eigener Sicherheitsseite läuft Tailscales Control Plane in AWS, Backups liegen in S3 und Analytics-Daten in Snowflake. Lieferant, Rechtsraum, Unterauftragnehmer, Ausfallmodell und Exit-Strategie landen damit in meiner Risikobewertung.

Das macht Tailscale nicht unsicher, und in NIS2 steht kein Satz wie „Du sollst keine amerikanische Software kaufen“. Gefordert werden aber Risikomanagement, Lieferkettensicherheit, Resilienz und Verantwortlichkeit. In einem normalen Start-up können Tailscales Antworten völlig ausreichen. Rund um Stromnetze, Großspeicher, Wasser, Verkehr oder andere KRITIS-Umgebungen erzeugen sie Arbeit – und am Ende bleibt der Betreiber verantwortlich.

Deshalb hat NetBird meine Aufmerksamkeit bekommen. Die NetBird GmbH ist in Berlin eingetragen. Noch wichtiger: Alle Komponenten, die zum Betrieb des Netzes nötig sind, sind Open Source und selbst hostbar – Client, Management Service, Dashboard, Signal Server und Relay. Der aktuelle Code steht unter der BSD-3-Clause-Lizenz. Ich kann NetBird Cloud für die Bequemlichkeit nutzen oder die offizielle NetBird-Control-Plane selbst betreiben, ohne sie durch die Nachimplementierung eines Dritten zu ersetzen.

Das ist eigentlich der Kern dieses Artikels. Mit NetBird kann ich Control-Plane-Datenbank, Peer-Metadaten, Policies, Audit-Logs, Signalling und Relay-Traffic in meiner eigenen Infrastruktur in Deutschland halten – samt eigenem Identity Provider. Ich muss keine kunstvolle Datentransfer-Folgenabschätzung verfassen, um zu erklären, warum ein ausländischer SaaS-Dienst unbedingt zwischen Operatoren und Batteriespeicher sitzen muss. Ich kann diese Abhängigkeit entfernen.

Dann habe ich Reverse Proxy, Networks, Posture Checks und DNS-Routing entdeckt. NetBird ist nicht nur die souveränere Wahl, sondern ein ernsthaft gutes Produkt.

Was NetBird eigentlich ist

NetBird baut ein privates Overlay-Netz zwischen Maschinen auf, die es Peers nennt. Jeder Peer bekommt eine Adresse aus dem CGNAT-Bereich 100.64.0.0/10, einen privaten DNS-Namen und eine WireGuard-Identität. Der Client erzeugt seine WireGuard-Schlüssel lokal; der private Schlüssel verlässt das Gerät nie.

Die Control Plane sagt berechtigten Peers, wie sie einander finden, verteilt öffentliche Schlüssel und Policies und hilft beim Verbindungsaufbau. Finden zwei Peers einen direkten Weg, läuft ihr Traffic durch einen verschlüsselten WireGuard-Tunnel direkt zwischen ihnen. Der Management Server koordiniert, liegt aber normalerweise nicht im Datenpfad.

Vier Teile sind entscheidend:

1. Der Client läuft auf jedem Peer, setzt DNS- und Firewall-Regeln um und baut WireGuard-Tunnel auf.
2. Der Management Service hält Accounts, Peers, öffentliche Schlüssel, Gruppen, Policies und den Netzwerkzustand.
3. Der Signal Service vermittelt verschlüsselte Verbindungskandidaten; Nutzdaten laufen nicht durch ihn.
4. Das Relay springt ein, wenn NAT-Traversal keine direkte Verbindung schafft. Auch dort bleibt WireGuard Ende-zu-Ende verschlüsselt.

Das aktuelle Relay lässt QUIC über UDP und WebSocket über TCP gegeneinander antreten. In Hotels, Firmennetzen und Mobilfunknetzen mit gesperrtem UDP rettet der HTTPS-ähnliche WebSocket-Pfad häufig die Verbindung. Direkt ist schneller; beim Relay werden dessen Standort und Bandbreite Teil der Planung. Die Details stehen verständlich in How NetBird Works und Understanding NAT and Connectivity.

Nicht nur „open genug“: Die ganze Control Plane ist da

Hier überzeugt mich NetBird. Genug Infrastrukturprodukte stellen den Agent auf GitHub und nennen sich Open Source, während der wichtige Server eine Blackbox bleibt. NetBird veröffentlicht die Teile, die das Netz tatsächlich betreiben. Management, Signalling, Relay, Dashboard und Client können auf meinen Maschinen laufen. Hinter dem hübschen Diagramm versteckt sich kein obligatorischer Phone-Home-Pfad.

Neue Installationen verwenden einen kombinierten netbird-server-Container für Management, Signal und Relay, statt der früheren Sammlung einzelner Container. Das Quickstart-Skript erzeugt eine Konfiguration rund um die eigene Domain und den Reverse Proxy. Für Identitäten gibt es einen eingebauten Provider oder generisches OpenID Connect, etwa mit Keycloak, Authentik oder Zitadel. Siehe Self-Hosting-Anleitung und IdP-Dokumentation.

Ich entscheide damit, wo Accountdaten, Peer-Metadaten, Policies, Audit-Events, Signalling und weitergeleiteter Traffic liegen. Vor allem gehören mir auch die Server, die festlegen, welche öffentlichen Schlüssel und Regeln meine Peers erhalten. „Das betreiben wir in diesem deutschen Rechenzentrum“ ist eine wunderbar kurze Antwort im Audit. Kurze Antworten werden unterschätzt.

Natürlich kommt Souveränität mit einem Pager. Updates, Backups, Zertifikate, Monitoring, Datenbankintegrität, IdP-Verfügbarkeit und genügend Relay-Kapazität werden mein Problem. Eine self-hosted Sicherheitskomponente, die niemand patcht, ist nicht souveräner, sondern nur die eigene Schwachstelle.

Tailscale-Nutzer sind nicht völlig festgelegt. Die Clients akzeptieren eine eigene Control-Server-URL, und das Community-Projekt Headscale implementiert einen solchen Server. Tailscale dokumentiert sogar die Client-Konfiguration für Headscale. Ich mag Headscale, aber es bleibt eine Nachimplementierung. Es bildet nicht jedes SaaS-Feature ab und ist nicht der Server, den Tailscale verkauft und unterstützt. Im Homelab egal; in einer KRITIS-Lieferantenprüfung ist „Vendor-Client plus inoffizieller kompatibler Server“ nicht der saubere Ausweg, als der es manchmal dargestellt wird. NetBirds self-hosted Server ist NetBird.

Maschinen ins Netz bekommen

Von Menschen bediente Geräte melden sich über einen Identity Provider an. Server, Container und Automatisierung verwenden Setup Keys. Sie können einmalig oder wiederverwendbar sein, ablaufen, ein Nutzungslimit haben und neue Peers automatisch Gruppen zuordnen.

So steckt die Policy bereits im Provisioning: Produktionsserver landen in prod-servers, CI Runner in ci-runners und Standort-Gateways in routing-peers, ohne anschließendes Aufräumen im Dashboard. Ephemere Peers verschwinden automatisch, wenn sie länger offline sind – praktisch für CI und Autoscaling. Die Setup-Key-Dokumentation beschreibt auch Terraform-, Ansible- und unattended Deployments.

Zugriffskontrolle ohne Policy-Datei-Archäologie

Ein neuer Account beginnt mit einer großzügigen Default Policy. Das ist gut für den ersten Test und schlecht als Dauerzustand. Policies verbinden Quellgruppen mit Zielgruppen oder Ressourcen und begrenzen Protokoll, Ports und Richtung.

• operators erreichen site-gateways über HTTPS und SSH;
• grafana erreicht prometheus auf TCP 9090, aber nicht das ganze Monitoring-Subnetz;
• developers kommen nach Staging, nur on-call nach Produktion;
• Externe erreichen eine veröffentlichte Anwendung statt gleich ein ganzes Netz.

NetBird verteilt nur die relevanten Network Maps und Firewall-Regeln. Die Durchsetzung passiert am Rand, nicht in einer zentralen Firewall, durch die jedes Paket muss. Gruppen können Benutzer, Maschinen und Netzwerkressourcen enthalten.

Posture Checks bringen Gerätekontext in die Policy: Client-Version, OS oder Kernel, Land und Region, lokale oder öffentliche Netzbereiche und laufende Prozesse. Damit wird etwa „Produktion nur mit aktuellem Client“ oder „Remote Route nur außerhalb des Büros“ möglich. Mobile Betriebssysteme liefern nicht jedes Signal, das Desktop-Agenten sehen; die Details stehen in NetBirds Posture-Check-Übersicht.

Networks für Geräte ohne Agent

Auf Laptop und Server installiere ich gern einen Client. Bei SPS, Drucker, Appliance, altem VM-Image oder verwaltetem Cloud-Dienst geht das oft nicht. Dafür gibt es Networks und Routing Peers.

Ein Routing Peer steht im Ziel-LAN, VPC oder Rechenzentrum und leitet berechtigten Mesh-Traffic zu deklarierten Ressourcen weiter. Eine Ressource kann eine einzelne IP, ein Subnetz oder ein Domainname einschließlich unterstützter Wildcards sein. Mehrere Routing Peers können dasselbe Network redundant bedienen.

Standardmäßig vereinfacht Masquerading die Einrichtung: Das Ziel sieht die lokale Adresse des Routers, eine Rückroute ist unnötig. Ohne Masquerading bleibt die ursprüngliche NetBird-IP sichtbar, dafür braucht das LAN eine Rückroute. NAT ist einfacher; echte Quelladressen sind für nachgelagerte Audit-Logs besser.

Das ältere Modell Network Routes taucht noch auf, weil Exit Nodes es derzeit verwenden. Für normale Subnetz- und Domain-Routen ist es deprecated. Neue Setups sollten Networks nutzen, wo Ressourcen erst durch eine explizite Policy sichtbar werden. NetBird erklärt die Unterschiede in How Routing Peers Work.

Genau das will ich in OT: Ein kleiner, gepflegter Linux-Gateway steht im Managementsegment neben BMS, Historian oder SPS-Netz. Auf dem Controller selbst landet keine VPN-Software. Operatoren sehen nur die freigegebenen Managementschnittstellen und Ports.

DNS, weil es immer DNS ist

Jeder Peer erhält einen stabilen privaten Namen. Der lokale Resolver kann außerdem Nameserver an ausgewählte Gruppen verteilen und Split DNS für interne Zonen bereitstellen. Peers mit Konflikten können Managed DNS abschalten, ohne das Mesh zu verlassen.

Domain-Ressourcen helfen, wenn Adressen wechseln oder Namen nur am Standort auflösbar sind. Der Routing Peer löst erp.corp.internal über das Standort-DNS auf und routet den Client dorthin. Das ist kein Application Proxy, gibt Policies aber eine sinnvollere Sprache als gepflegte IP-Listen.

Split DNS, zweiter VPN-Client, systemd-resolved, DNS-over-HTTPS und überlappende private Zonen können sich trotzdem streiten. Dafür gibt es pro Peer --disable-dns und eine brauchbare DNS-Fehlersuche.

Exit Nodes und der fehlende Mullvad-Knopf

Eine Exit Node leitet allgemeinen Internet-Traffic durch eine andere NetBird-Maschine. Das kann ein VPS mit fester öffentlicher IP, das Büro für SaaS-Allowlisting oder der Heimanschluss auf Reisen sein. Policies begrenzen, welche Gruppen die Exit Node verwenden dürfen.

Der Mullvad-Workaround ist eine NetBird Exit Node, die selbst Mullvad als Upstream nutzt:

Laptop -> verschlüsselter NetBird-Tunnel -> eigene Exit Node -> Mullvad-Tunnel -> Internet

Das funktioniert, aber Forwarding, NAT, DNS und Kill Switch gehören dann mir. Ein Mullvad-Reconnect darf Traffic nicht plötzlich über das normale Serverinterface schicken. Außerdem kommen ein Hop und eine zu wartende Maschine hinzu.

Tailscales natives Mullvad-Exit-Node-Add-on ist für diesen Fall klar angenehmer: Mullvad-Standorte erscheinen direkt im Client, die Abrechnung ist integriert. Es kostet extra und hat Einschränkungen, aber NetBird bietet derzeit nichts Gleichwertiges. Wer primär Consumer-VPN-Egress will, ist mit Tailscale besser bedient.

Das Feature, das mich verkauft hat: Reverse Proxy

NetBird Reverse Proxy veröffentlicht einen internen Dienst im Internet, ohne am Zielnetz einen eingehenden Port zu öffnen. Traffic erreicht einen Proxy-Cluster und läuft durch das NetBird-Mesh zu einem Peer oder zu einer Ressource hinter einem Routing Peer.

Im HTTP-Modus terminiert er TLS, verteilt auf mehrere Ziele, routet nach Pfad, schreibt Redirects um und schützt Zugriffe per SSO, Passwort oder PIN. Einschränkungen nach IP, Land und CrowdSec-Reputation sind möglich. Layer-4-Modi decken TCP, UDP und TLS ab; TLS Passthrough routet anhand von SNI, sodass das Backend selbst TLS terminieren kann.

Das Dashboard provisioniert Domain und Zertifikat, eigene Domains werden per DNS angebunden. Genau das wollte ich für Grafana und Managementoberflächen: internes Ziel definieren, Authentifizierung wählen, Domain darauf zeigen lassen – statt an jedem Standort noch Tunnel-Daemon und Caddy- oder Nginx-Konfiguration zu pflegen.

Das ist nicht auf NetBird Cloud beschränkt. Self-hosted Installationen betreiben einen eigenen Proxy-Cluster; Cloud-Accounts können mit Bring Your Own Proxy ebenfalls in einer bestimmten Region oder eigener Infrastruktur terminieren. Self-hosted wird derzeit Traefik benötigt, weil NetBird dessen TLS-Passthrough-Verhalten voraussetzt. Vor Produktion gehören die Reverse-Proxy-Dokumentation und der BYOP-Guide auf den Tisch.

Der große Stern: Reverse Proxy ist Beta. Für Lab, Dashboards und überwachte interne Tools nutze ich ihn gern. Eine umsatzkritische öffentliche API würde ich nicht ohne Lasttest, Ausfallübung und Exit-Plan von einem bewährten Ingress migrieren. Rosenpass wird dort aktuell ebenfalls nicht unterstützt.

Tailscale hat mit Serve und Funnel eigene Antworten. Serve veröffentlicht lokal im Tailnet, Funnel öffentlich per HTTPS. NetBird reizt mich durch die zentral verwaltete Serviceschicht: HTTP und L4, mehrere Targets, Authentifizierung, Einschränkungen, eigene Domains und selbst betriebene Proxy-Cluster in einem Modell.

SSH: nützlich, aber kein NetBird-Alleinstellungsmerkmal

Tailscale hat ebenfalls eingebautes SSH. Das als NetBird-Vorteil zu verkaufen, wäre unfair. Tailscale SSH ist ausgereift: Tailnet-Policies autorisieren Verbindungen, Identitäten werden bestehenden lokalen Benutzern zugeordnet, Check Mode kann erneute IdP-Anmeldung verlangen und Session Recording ist möglich.

NetBird betreibt ebenfalls einen eingebauten SSH-Server und kennt zwei Authentifizierungsmodi:

• JWT ist Standard. Jede neue Session authentifiziert die Person über den konfigurierten OIDC-Provider und erhält ein JWT, sofern kein zeitlich begrenzter JWT-Cache aktiv ist. Policies ordnen NetBird-Benutzer oder -Gruppen gezielt lokalen OS-Accounts zu.
• Machine Identity wird mit --disable-ssh-auth aktiviert. Trotz des etwas beunruhigenden Namens ist SSH nicht offen: NetBird-ACLs entscheiden weiterhin, welcher Peer den SSH-Server erreicht. Nur die zusätzliche personenbezogene OIDC/JWT-Prüfung entfällt.

Aktuelle Releases unterstützen native OpenSSH-Clients, SFTP, Kommandos, lokales und entferntes Port Forwarding sowie Windows-Peers. Attraktiv ist vor allem, dass Identity-, Policy- und Coordination-Pfad in meiner self-hosted Control Plane bleiben.

Wichtig: NetBird fragt standardmäßig nicht nach dem echten Passwort des Zielaccounts. Die Person wird am IdP authentifiziert und für einen vorhandenen OS-Benutzer autorisiert. Tailscale arbeitet ähnlich und verlangt ebenfalls weder dessen normales Passwort noch seinen SSH-Key.

Will ich zwei getrennte Schranken – erst Mesh-Berechtigung, danach Passwort oder Key des Hosts – lasse ich normales OpenSSH über NetBird oder Tailscale laufen. Für KRITIS kann das sogar die konservativere Variante sein: Das Mesh entfernt den öffentlichen Port 22, sshd behält PAM und die vertraute lokale Authentifizierung.

Beide Produkte haben also SSH. NetBirds Vorteil ist für mich, dass auch dieser Identity-, Policy- und Steuerpfad vollständig selbst hostbar ist. Wegen jüngerer Breaking Changes und Versionsanforderungen sollte man vorher die NetBird-SSH-Dokumentation lesen.

Sehe ich, was das Ding tut?

Das Dashboard protokolliert Änderungen an Peers, Benutzern, Gruppen, Setup Keys, Policies und Einstellungen. Audit Events sind durchsuchbar und lassen sich an SIEM-Systeme streamen. Für self-hosted Komponenten gibt es Prometheus-Metriken, darunter Relay-Verbindungen, Authentifizierungszeit, Reconnects und übertragene Bytes. So wird aus „das VPN fühlt sich langsam an“ eine messbare Relay-Sättigung oder ein sichtbarer Fallback aller Direktverbindungen auf TCP.

API, CLI und Terraform Provider decken Configuration as Code ab; für Kubernetes gibt es einen Operator. Setup Keys machen Container und kurzlebige Workloads automatisierbar, ohne ein Ritual aus Dashboard-Klicks zu erfinden.

Wo NetBird mich noch nervt

NetBird liegt nicht überall vorn. Tailscale hatte mehr Jahre, um Kanten abzuschleifen und Unterstützung für jede seltsame Box hinter einem Fernseher zu sammeln.

1. Weniger Apps und Hardware

NetBird deckt Linux, Windows, macOS, iOS und Android ab und dokumentiert inzwischen tvOS, Synology, TrueNAS, pfSense und OPNsense. Für viele Firmenflotten reicht das.

Tailscale geht breiter und oft tiefer: Android TV, Apple TV, Amazon Fire TV, Chromebook, Synology, QNAP, TrueNAS, Unraid und viele Router- oder Appliance-Umgebungen. Die NAS-Dokumentation unterscheidet sauber zwischen offiziellen Paketen und Community Support. Gerade ohne brauchbare Shell zählt ein guter App-Store-Weg. Außerdem existieren jahrelang gewachsene Rezepte für Home Assistant, Serverless, Router und kleine Homelab-Kisten.

Routing Peers können nicht unterstützte Geräte anbinden, ersetzen aber keinen nativen Client. Der native Client behält beim Netzwechsel seine Identität und nimmt direkt an Policies teil. Vor einer Migration würde ich deshalb jedes Gerät prüfen.

2. Tailscales Client-Erlebnis ist reifer

Tailscale ist in den ersten fünf Minuten außergewöhnlich gut. Login, Peer Discovery, DNS und Auswahl der Exit Node wirken plattformübergreifend zusammenhängend. NetBird funktioniert, aber neue Funktionen landen teils zuerst in der CLI oder benötigen genau abgestimmte Versionen.

Beim Flottenmanagement zeigt sich der Abstand: NetBird dokumentiert native MDM-Policies für Windows und macOS; iOS und Android stehen noch auf der Roadmap. „Die App existiert“ ist nicht dasselbe wie „ihre Sicherheitseinstellungen lassen sich auf 500 Smartphones erzwingen“.

3. Kein natives Mullvad

Die eigene Exit Node funktioniert, ist aber nicht das Gleiche wie einen Mullvad-Standort im Client anzuklicken. Diesen Punkt gewinnt Tailscale klar.

4. Spannende Features sind noch jung

Reverse Proxy ist Beta. Networks haben Routes für fast alle Zwecke ersetzt, aber Exit Nodes hängen noch am alten Modell. NetBird SSH wurde stark umgebaut und bringt explizite Upgrade-Bedingungen mit. Das Entwicklungstempo ist schön, verlangt aber Release Notes und Tests mit gemischten Client-Versionen.

5. Self-Hosting verschiebt Arbeit zu mir

Den offiziellen Server betreiben zu können heißt nicht, dass es jeder tun sollte. Tailscales gehostete Control Plane und weltweites Relay-Netz nehmen Operationsarbeit ab; NetBird Cloud bietet denselben Komfort. Ich hoste selbst, wenn Souveränität, Compliance, eingeschränkte Konnektivität oder Anpassung es rechtfertigen – nicht weil Docker Compose die ersten zehn Minuten kostenlos aussehen lässt.

Das deutsche Unternehmen ist keine Fußnote

Dieser Punkt wird gern so lange weichgespült, bis nichts mehr übrig bleibt: Für deutsche kritische Infrastruktur ist es ein Vorteil, die Netzwerk-Control-Plane von einem deutschen Unternehmen zu beziehen.

Tailscale ist ein US-Unternehmen mit mandantenfähiger Control Plane. Auch ohne entschlüsselten Payload-Traffic bleibt es ein ausländischer Lieferant, der sensible Netzmetadaten verarbeitet und Zugriffe koordiniert. Verträge, Unterauftragnehmer, internationale Datentransfers, US-Rechtsraum, Lieferantenausfall und geopolitische Abhängigkeit gehören damit ins Bedrohungsmodell. Vielleicht akzeptiert die Bewertung all das. Dann muss sie trotzdem erstellt, dokumentiert und wiederholt werden.

NIS2 legt Risikomanagement, Resilienz und Lieferkettensicherheit ausdrücklich auf den Tisch des Betreibers; sie gehören zu den Maßnahmen in Artikel 21. Deutsche KRITIS-Aufsicht bringt zusätzliche Nachweis- und Prüfpflichten. „Die Pakete sind verschlüsselt“ beantwortet nicht, wer den Koordinator betreibt, wo Metadaten liegen, was beim Ende des Dienstes oder Vertrags passiert und wie der Betreiber in einer Krise die Kontrolle übernimmt.

NetBird gibt mir drei bessere Antworten:

1. Deutscher Anbieter: Die NetBird GmbH sitzt in Berlin. Beschaffung, Vertrag und Eskalation liegen im deutschen und europäischen Rechtsraum.
2. Prüfbare Software: Client und notwendige Serverinfrastruktur sind Open Source unter BSD-3-Clause. Das Security-Team kann prüfen, Versionen pinnen und selbst bauen.
3. Operative Unabhängigkeit: Management, Policy, Identity, Signalling, Relay und Proxy laufen auf Wunsch in meiner Umgebung. Dann ist der Hersteller keine aktive technische Voraussetzung für den Betrieb meines Netzes.

Der dritte Punkt entscheidet. Ein deutscher Anbieter allein reicht nicht; auch deutsches SaaS bleibt eine Abhängigkeit. Open Source allein reicht ebenfalls nicht, wenn nur der Client offen und der Koordinator proprietär ist. NetBird kombiniert beides und lässt mich den gesamten Stack nach Hause holen.

Kein Produkt macht eine Organisation durch Installation NIS2-, KRITIS-, GDPR- oder DORA-konform. Auch NetBirds ISO-27001-Zertifizierung überträgt sich nicht auf mein Deployment. Ich kann damit aber eine sauberere Systemgrenze entwerfen, die Lieferantenfläche reduzieren und Nachweise aus Infrastruktur erzeugen, die ich selbst betreibe. Das ist kein Compliance-Theater, sondern weniger Risiko, das ich erklären muss.

So würde ich es ausrollen

Ich würde klein anfangen: erst zwei normale Peers verbinden und prüfen, ob sie direkt oder per Relay kommunizieren. Danach die großzügige Default Policy entfernen, Gruppen nach Rollen und Ressourcen statt Standorten bauen und an einem unkritischen Standort genau eine Ressource über einen Routing Peer freigeben. Erst ein zweiter Routing Peer macht den Pfad wirklich redundant.

DNS käme zunächst nur auf eine Testgruppe. Einen Wegwerf-Dienst würde ich über Reverse Proxy veröffentlichen und SSO, Zertifikatserneuerung und Ausfallverhalten testen. Vor Produktion müssen Audit Events im SIEM, Komponentenmetriken im Monitoring und Backup- sowie Upgrade-Prozess in der Dokumentation stehen.

Im OT-Standort gehört der Routing Peer in ein Managementsegment, nicht mit uneingeschränktem Zugriff neben sicherheitskritische Controller. NetBird ersetzt weder Segmentierung und Asset-Inventar noch lokale Firewalls oder eine Safety-Prüfung.

Ersetze ich Tailscale?

Für Infrastruktur, die ich unter NIS2 oder KRITIS verteidigen muss: ja. Die Control Plane ist zu zentral, um ihre Eigentümerschaft als diffuses Zukunftsproblem zu behandeln. NetBird lässt mich den offiziellen Stack in Deutschland betreiben und Policy, Metadaten, Signalling, Relay und Ingress unter meiner Kontrolle halten. Das entscheidet die Sache.

Ich lösche Tailscale nicht morgen von jedem Privatgerät. Das App-Ökosystem ist besser, seltsame Hardware wird breiter unterstützt und Mullvad ist nativ integriert. Für das Familien-TV gewinnt Tailscale vermutlich, bevor der Kaffee fertig ist.

NetBird ist aber nicht mehr die prinzipientreue Self-Hosting-Alternative, deren Macken ich nur wegen der Souveränität ertrage. Networks, Posture Checks, DNS-Routing, SSH und Reverse Proxy sind gute Features. Die rauen Kanten existieren, wiegen für mich aber weniger schwer als die Kontrolle über die Infrastruktur, die entscheidet, wer einen kritischen Standort erreicht.

Tailscale hat Mesh-VPNs angenehm langweilig gemacht. NetBird macht die Control Plane zu meiner. Im Homelab ist das eine Präferenz. In kritischer Infrastruktur kann es die entscheidende Anforderung sein.