NetBird vs. traditionelles VPN
Traditionelles VPN:
Laptop -> [Internet] -> VPN-Server -> internes Netz
Single Point of Failure. Bandbreite durch Server-Kapazität begrenzt.
NetBird (Mesh, Zero-Trust):
Laptop <-> [WireGuard, wo möglich direkt P2P] <-> Peer
Kein zentraler Daten-Server. Management-Server koordiniert nur die Verbindung.
Wichtig zur Einordnung: NetBird ist ein Mesh-Overlay-Netzwerk auf WireGuard-Basis, kein klassisches Hub-and-Spoke-VPN. Jeder Peer kann direkt mit jedem anderen Peer verbunden sein (NAT-Traversal via STUN/TURN), statt dass aller Traffic zwingend durch einen zentralen Server muss. Das reduziert Bandbreiten-Engpässe und einen einzelnen Ausfallpunkt — bei ungünstigen NAT-Konstellationen fällt NetBird auf Relay-Server zurück, dann verhält es sich traffic-technisch wie ein klassisches VPN.
NetBird Cloud (kostenlos bis 5 Peers)
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --setup-key SETUP_KEY_AUS_DASHBOARD
netbird status
Dashboard: app.netbird.io — dort sehen sich verbundene Peers gegenseitig, jeder bekommt eine feste Overlay-IP im 100.64.x.x-Bereich (CGNAT-Adressraum, kollidiert praktisch nie mit regulären privaten Netzen).
NetBird Self-Hosted
Für mehr als 5 Peers oder wenn Daten das eigene Netz nicht verlassen sollen, lässt sich der komplette Management-Stack selbst hosten:
# netbird-compose.yml
services:
netbird-management:
image: netbirdio/management:latest
restart: unless-stopped
volumes:
- ./management:/var/lib/netbird
ports:
- "443:443"
- "33073:33073"
command: --port 443 --log-level info
netbird-signal:
image: netbirdio/signal:latest
restart: unless-stopped
volumes:
- ./signal:/var/lib/netbird
ports:
- "10000:10000"
docker compose -f netbird-compose.yml up -d
netbird up \
--management-url https://netbird.firma.de:443 \
--setup-key SETUP_KEY
Wichtig: Der Management- und Signal-Server koordinieren nur den Verbindungsaufbau (Schlüsselaustausch, wer darf mit wem) — sie sehen den eigentlichen VPN-Traffic zu keinem Zeitpunkt, da dieser Ende-zu-Ende über WireGuard läuft. Ein kompromittierter Management-Server erlaubt daher keinen Zugriff auf die übertragenen Daten selbst, nur auf die Netzwerk-Topologie-Informationen.
Access Control Policies
NetBird Dashboard -> Policies:
Policy: Entwickler duerfen auf Dev-Server
Source: Entwickler-Laptops (Gruppe)
Destination: Dev-Server-Gruppe
Ports: 22, 5432, 8080
Action: Allow
Policy: Alle -> Management blockiert (Standard-Deny)
Source: Alle
Destination: Management-Gruppe
Action: Deny
Der praktische Vorteil gegenüber einem klassischen VPN mit einer einzigen "alle im VPN sehen alle"-Regel: Zero-Trust bedeutet hier wörtlich, dass ohne explizite Policy standardmäßig nichts erlaubt ist — auch nicht zwischen zwei Geräten, die beide im selben NetBird-Netzwerk hängen.
Netzwerk-Routes (Subnet Router)
# Auf einem Peer im internen Netz:
netbird up --setup-key KEY
sysctl -w net.ipv4.ip_forward=1
# NetBird Dashboard -> Peer -> Routes
# Network: 192.168.1.0/24
# Router: dieser Peer
Ein einzelner NetBird-Peer kann so als Gateway für ein ganzes physisches Subnetz fungieren — alle anderen Peers erreichen darüber Geräte im 192.168.1.0/24-Netz, ohne dass jedes einzelne Gerät dort NetBird installiert haben muss. Praktisch für Legacy-Geräte (Drucker, IoT, alte Server), die selbst keinen VPN-Client unterstützen.
FAQ
Wie sicher ist NetBird?
NetBird nutzt WireGuard als Transport (kleiner, auditierter Code, moderne Kryptographie). Peers authentifizieren sich gegenseitig über Public-Key-Kryptographie. Der Management-Server steuert nur, wer eine Verbindung aufbauen darf — er sieht den eigentlichen Datenverkehr nicht.
Unterschied zu Tailscale?
NetBird ist vollständig quelloffen und komplett self-hostbar ohne Vendor-Lock-in. Tailscale hat einen proprietären Koordinationsserver (auch wenn der Client-Teil quelloffen ist) und ein etwas ausgereifteres Ökosystem an Integrationen.
Fazit
NetBird bietet modernes Mesh-basiertes Zero-Trust-Networking ohne den klassischen VPN-Server als Flaschenhals — besonders für verteilte Teams mit direktem Peer-zu-Peer-Bedarf (nicht nur "alle ins Firmennetz") ein echter Architekturvorteil gegenüber klassischem Hub-and-Spoke-VPN.
Ich baue Zero-Trust-Netzwerke und klassische VPN-Lösungen für Unternehmen in Heidelberg und der Rhein-Neckar-Region auf — je nachdem, was zum tatsächlichen Bedarf passt. Anfragen.