ZTXGate vs NetBird
ZTXGate und NetBird überschneiden sich bei WireGuard-basierter Konnektivität, Self-Hosting und Einsatzmöglichkeiten ohne verpflichtende Anbieter-Control-Plane. Architektonisch sind sie jedoch verschieden: NetBird ist primär eine koordinierte WireGuard-Peer-Networking-Plattform mit Cloud- und Self-Hosted-Optionen; ZTXGate ist eine Gateway/Proxy-ZTNA-Plattform mit Ressourcenrichtlinien, verwaltetem WireGuard-Zugriff und clientlosem HTTP/HTTPS-Zugriff.
Überblick
| Bereich | ZTXGate | NetBird |
|---|---|---|
| Kernarchitektur | ZTNA Gateway/Proxy mit Ressourcenrichtlinien | WireGuard-Peer-Netzwerk mit zentralem Management/Policy |
| Hosted-Option | Optionales ZTXHub für Lifecycle-Funktionen, nicht Kernzugriff | NetBird Cloud für gehostetes Management/Control |
| Self-Hosting | Kunden-/MSP-betrieben | Unterstützte Self-Hosted-Edition |
| Air-Gap-Eignung | Standalone unterstützt | Air-gapped Netzwerke explizit als Self-Host-Use-Case genannt |
| Konnektivität | WireGuard durch ZTXGate | Direkt Peer-to-Peer, wenn möglich; Relay-Fallback |
| Browserzugriff | Lizenzierter HTTP/HTTPS-Clientless-Proxy | Browser Client dokumentiert SSH/RDP via WASM-NetBird-Peer |
| Identität | OIDC + SCIM; integriertes ZTXBAS optional | Lokale Benutzer in Self-Hosted plus optionale externe IdPs; Enterprise-Funktionen editionsabhängig |
| Resilienz | Backup/Restore; kein konventionelles HA | Cloud mit Managed HA; Self-Hosted-Verfügbarkeit liegt beim Betreiber |
| Open Source | Nein | Ja, mit kommerziellen Angeboten/Funktionen |
Unterschiedliche Kernarchitekturen
NetBird koordiniert WireGuard-Peers, die nach Möglichkeit direkt kommunizieren und sonst Relays verwenden. Die Management-Schicht verteilt Netzwerk- und Zugriffsregeln. ZTXGate verwendet WireGuard als sicheren Transport durch eine zentrale Enforcement-Umgebung, in der Benutzer-/Geräte- und Ressourcenrichtlinien ausgewertet werden; zusätzlich steht ein lizenzierter HTTP/HTTPS-Proxy zur Verfügung.
NetBird: Peer-Identität + WireGuard-Netz + zentrale Richtlinie
ZTXGate: Identitäts-/Geräterichtlinie + Gateway/Proxy + autorisierte Ressource
Keines der Modelle ist grundsätzlich besser; sie optimieren für unterschiedliche Zugriffsmuster.
Self-Hosting
NetBird bietet Cloud- und Self-Hosted-Betrieb. Die aktuelle Dokumentation beschreibt lokale Benutzerverwaltung in der Self-Hosted-Edition sowie optionale externe IdPs. Der Betreiber ist dort für die benötigten Management-, Signaling-, Relay-, Identity-, Backup- und Verfügbarkeitskomponenten verantwortlich.
ZTXGate ist von vornherein für Kunden- oder MSP-betriebene Infrastruktur konzipiert. Self-Hosting allein ist daher kein einzigartiges ZTXGate-Merkmal; relevant ist, welche Komponenten betrieben werden müssen und welches Zugriffsmodell daraus entsteht.
WireGuard-Nutzung
Beide Produkte verwenden WireGuard. Bei NetBird bildet Peer-Konnektivität das private Netz; bei ZTXGate ist WireGuard der Transport für verwalteten Zugriff, während Richtlinien festlegen, welcher Benutzer mit welchem Gerät welche Ressource erreicht.
Browser- und Clientless-Zugriff
NetBirds Browser Client führt einen NetBird-Peer als WebAssembly im Browser aus und dokumentiert aktuell SSH- und RDP-Zugriff. ZTXGate konzentriert seinen lizenzierten clientlosen Pfad auf HTTP/HTTPS und arbeitet als richtliniendurchsetzender Proxy, der die Webverbindung terminiert und die autorisierte Verbindung zur Anwendung neu aufbaut.
Identität sowie Gerät/Posture
NetBird Self-Hosted unterstützt lokale Benutzer und optionale OIDC-Provider; einige Enterprise-Funktionen wie SCIM hängen von Edition/Lizenz ab. ZTXGate unterstützt OIDC und SCIM sowie lizenziertes integriertes ZTXBAS. Beide Produkte besitzen Geräte-/Posture-Kontrollen; bei einer Evaluation sollten die konkret benötigten Signale statt nur der Feature-Name verglichen werden.
ZTXGate integriert Microsoft Intune, Microsoft Defender for Endpoint, SentinelOne, CrowdStrike und Jamf.
Air-gapped Betrieb
Beide Produkte können für getrennte Umgebungen relevant sein. NetBird nennt air-gapped Netzwerke ausdrücklich als Self-Hosted-Anwendungsfall. ZTXGate kann ebenfalls vollständig air-gapped Standalone arbeiten; Lizenzierung und Updates werden dann manuell durchgeführt, und lizenziertes ZTXBAS bleibt für phishing-resistente biometrische Authentifizierung innerhalb der Bereitstellung verfügbar.
ZTXGate sollte hier daher keine Einzigartigkeit beanspruchen. Praktisch zu vergleichen sind Komponentenanzahl, Identitätsmodell, Updateprozess, Betriebsaufwand, Zugriffsarchitektur und benötigte Protokolle.
Verfügbarkeit und Disaster Recovery
NetBird Cloud bietet vom Anbieter verwaltete HA. Bei Self-Hosted NetBird liegt die Verfügbarkeit von Management- und Relay-Komponenten beim Betreiber. ZTXGate bietet derzeit kein konventionelles HA-Clustering; periodische Backups können in eine neue Bereitstellung wiederhergestellt werden.
Architekturwahl
NetBird kann gut passen, wenn Open Source, direktes Peer-Networking, Wahl zwischen Cloud/Self-Hosted und browserbasiertes SSH/RDP wichtig sind. ZTXGate kann passen, wenn eine kommerziell unterstützte Gateway/Proxy-ZTNA-Umgebung, HTTP/HTTPS-Clientless Access, integriertes ZTXBAS oder ein optionaler Anbieter-Lifecycle-Service ohne Abhängigkeit des Kernzugriffs gewünscht wird. Dies ist keine Gesamtrangliste.
Verwendete offizielle Quellen
ZTXGate entdecken · Self-Hosted ZTNA · Kostenlose Testversion starten