02.1 – Zielarchitektur

Zielarchitektur NetBird

Ziel

Die bestehenden einzeln administrierten WireGuard-Verbindungen werden durch eine zentral verwaltete, selbstgehostete NetBird-Infrastruktur ersetzt. NetBird übernimmt Overlay-Vernetzung, Peer-Verwaltung, Gruppen, Policies und die kontrollierte Veröffentlichung der Standortnetze.

Für neue Site-to-Site-Konfigurationen ist das aktuelle NetBird-Modell Networks / Network Resources / Routing Peers zu verwenden. Die älteren Routes gelten für neue Site-to-Site-Implementierungen nicht als bevorzugtes Modell.

Architekturprinzip

Die OPNsense bleibt an jedem Standort Internet-Gateway, lokale Firewall, VLAN-Router und gegebenenfalls DHCP-/Routinginstanz. NetBird ersetzt nicht die Standortfirewall.

Pro Standort wird mindestens ein dedizierter Linux-Routing-Peer vorgesehen. Dieser besitzt Zugriff auf die lokalen Netze, die über NetBird veröffentlicht werden sollen. Für produktionskritische Standorte soll geprüft werden, zwei Routing-Peers auf unterschiedlichen Virtualisierungs-/Hardware-Fehlerdomänen einzusetzen.

Die NetBird-Control-Plane wird selbst gehostet und über einen öffentlichen DNS-Namen mit TLS erreichbar gemacht. Relay-Funktionalität ist insbesondere für Roadwarrior und HomeOffice vorzusehen, wenn keine direkte Peer-to-Peer-Verbindung möglich ist.

Wesentliche Designentscheidung

Für normales Site-to-Site-Routing wird zunächst Masquerading auf den Linux-Routing-Peers vorgesehen. Dies entspricht dem aktuellen NetBird-Site-to-Site-Modell und vermeidet zusätzliche Rückrouten in allen Standortnetzen. Wo Quell-IP-Transparenz zwingend erforderlich ist, muss dies separat bewertet werden, da die Deaktivierung von Masquerading zusätzliche Rückrouten benötigt und Auswirkungen auf Hochverfügbarkeit hat.