Zwei LANs auf NetBird: Welche Peers routen und wer sprechen darf

Eine Workstation im westlichen LAN öffnet einen Browser, tippt die Adresse einer Anwendung im östlichen LAN ein und wartet, bis die Zeitüberschreitung greift. Jeder NetBird-Bildschirm sagt, die Peers seien verbunden, was stimmt und nicht zur Sache gehört: in einem Overlay-Netz zu sein ist nicht dasselbe, wie die beiden lokalen Subnetze in einem Netz zu haben. Der Rundgang unten beginnt an dieser Workstation und endet mit einer Anfrage, die das Design absichtlich ablehnt, und jede Station ist etwas, das man von einem Gerät abliest, statt es zu vermuten. Erwarten Sie, dass das fehlende Stück eine Route oder eine Policy ist, nicht das Overlay.

Lesen Sie den Fehler zuerst an der Workstation

Bevor Sie die Verwaltungskonsole öffnen, stellen Sie fest, was die Workstation tatsächlich sendet. Ihre eigene Routing-Tabelle entscheidet, ob das Paket zum Gateway des Standorts, zu einer lokalen Schnittstelle oder nirgendwohin geht, und diese Entscheidung ist ohne jedes Overlay-Werkzeug sichtbar. Eine Maschine ohne Route für das entfernte Präfix scheitert, so gesund die Peer-Liste auch aussieht. Overlay-Bereich und das eigene Präfix des Standorts sind verschiedene Adressräume, und die Registrierung hat nur einen davon konfiguriert.

Trennen Sie als Nächstes Namensauflösung von Erreichbarkeit, denn ein Browser meldet beides als dieselbe Zeitüberschreitung. Wiederholen Sie die Anfrage per Adresse von einer Maschine mit NetBird-Client und dann von einer gewöhnlichen Workstation ohne. Gelingt die registrierte Maschine und scheitert die einfache, sitzt die Lücke im lokalen Routing; scheitern beide, lesen Sie weiter, bevor Sie eine Route ändern.

Wählen Sie einen Routing-Peer pro Standort

Ein Routing-Peer ist ein Host, der sein LAN im Overlay vertritt, wählen Sie also eine Linux-Maschine mit stabiler Erreichbarkeit des Subnetzes statt jemandes Schreibtisch-Workstation. Registrieren Sie sie im normalen Verfahren und stecken Sie sie in eine nach der Rolle benannte Gruppe, denn Netzwerkressource und Policy verweisen beide auf diese Gruppe. Ein Vertreter pro Standort bleibt lesbar; eine Schar Freiwilliger, die dasselbe Präfix ankündigen, macht jede spätere Frage zur Debugging-Sitzung. Die Adresse des Peers im lokalen Segment zählt so viel wie seine Identität im Overlay, denn diese Adresse wird der nächste Hop, den jedes gewöhnliche Gerät genannt bekommt.

Schreiben Sie den Plan auf, bevor Sie die Konsole berühren, denn Namen und Präfixe sind der Ort, an dem diese Entwürfe abdriften: Präfix, Gateway, Peer-Adresse und Gruppe, pro Standort. West ist 10.52.0.0/24, bedient von 10.52.0.5, und Ost ist 10.63.0.0/24, bedient von 10.63.0.5; die beiden Gruppen sind west-routers und east-routers, und kein Präfix darf das andere, den Overlay-Bereich oder ein anderes geroutetes Ziel überlappen.

Legen Sie die Ressource an, lassen Sie das Masquerading an

Im bereitgestellten Dashboard legen Sie eine Netzwerkressource pro Standort an und hängen die Routing-Peer-Gruppe dieses Standorts daran. Die Ressource ist das Präfix und die Gruppe ist der Host, der dafür antwortet, und beide müssen existieren, bevor etwas angekündigt wird. Prüfen Sie, ob die bereitgestellte selbst gehostete Version den Netzwerke-Workflow überhaupt hat, denn eine ältere Oberfläche mit einem ähnlich benannten Routenobjekt ist eine andere Funktion.

Lassen Sie das Masquerading aktiviert. Der NetBird-Leitfaden für Standort-zu-Standort verlangt es in dieser Anordnung, und es abzuschalten, damit jede Originaladresse sichtbar bleibt, ist nicht dasselbe Design mit einem Hop weniger; es ändert, was die Quellprüfungen und Policies des Overlays sehen. Die Konsequenz sollte man klar sagen: der empfangende Dienst protokolliert den Routing-Peer als Quelle, nicht die einzelne Workstation. Wenn die Allow-List oder das Audit dieses Dienstes Workstation-Adressen erwartet, ändert sich entweder die Erwartung, oder die Identität muss an der Standortgrenze vor der Übersetzung durchgesetzt werden.

Berechtigen Sie die Initiatoren, nicht die Präfixe

Eine Route macht eine Adresse erreichbar, und eine Policy entscheidet, wer sie nutzen darf; das sind zwei getrennte Objekte mit getrennten Eigentümern. Schreiben Sie die Policy von der Arbeitslast rückwärts: welche Gruppe initiiert, welche Ressource sie anspricht und welchen TCP-Dienst sie braucht. Ein Netz, das beide Präfixe jedem registrierten Peer ankündigt, hat Erreichbarkeit geschaffen und nichts geklärt.

Lesen Sie dann, was sonst schon erlaubt ist, denn eine enge neue Regel hebt keine breite alte auf, die darüber steht. Wenn Ost auch Verbindungen nach West beginnen muss, schreiben Sie diese Richtung als eigene Policy; Rückverkehr für eine von West geöffnete Sitzung ist eine andere Frage als neue Sitzungen nach Osten zu erlauben. Wenn nur einige westliche Workstations die östliche Anwendung erreichen sollen, wählen Sie sie an der Standortgrenze vor der Übersetzung aus und lassen Sie die eigene Authentifizierung der Anwendung bestehen. Der Routing-Peer trägt LAN-Verkehr als ganzen Standort und nicht als Overlay-Identität pro Benutzer, also muss die Abrechnung pro Benutzer von woanders kommen.

Lehren Sie jedes Gateway den nächsten Hop, dann testen Sie eine Ablehnung

Die gewöhnlichen Geräte sehen das Overlay nie, also braucht ihr eigenes Gateway eine statische Route, die das entfernte Präfix auf die LAN-Adresse des Routing-Peers zeigt. Diesen Schritt überspringen die Leute, weil alles Sichtbare in NetBird bereits funktioniert, während einfache Workstations noch in die Zeitüberschreitung laufen. Das Gateway behält seine Standardroute wie sie war; dieses Präfix ist eine Ergänzung, kein Ersatz.

Die beiden Routenbeschreibungen gehören in die Gateway-Konfiguration des jeweiligen Standorts, nicht in eine Überschreibung am Host. Beide sind einfache statische Routen, und keine berührt die Standardroute:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Testen Sie mit der Anwendung, die das Projekt wirklich braucht, von einer gewöhnlichen Workstation, und halten Sie drei Dinge fest: den auf der Sendeseite gewählten nächsten Hop, die passende Policy und die Quelladresse, die der Dienst protokolliert hat. Testen Sie auch eine Ablehnung, denn ein Design, das nie etwas abgelehnt hat, hat unbekannte Ränder, und die Ablehnung ist der einzige Beweis, dass die Policy und nicht das Routing die Arbeit tut. Wenn Ost ebenfalls initiieren muss, starten Sie eine neue Verbindung von dieser Seite, statt anzunehmen, die zweite Richtung folge. Planen Sie auch Neustart, Upgrade und Ersatz des Routing-Peers, denn ein Host ist zur Standortabhängigkeit geworden.

Private Namen brauchen ihr eigenes Resolver-Design, denn Erreichbarkeit erzeugt keine DNS-Einträge, und ein funktionierender IP-Pfad mit kaputtem Namen liest sich genau wie ein kaputter Pfad. Läuft ein Routing-Peer in einem Cloud-Netz, prüfen Sie auch die Weiterleitungs- und Firewall-Regeln des Anbieters, denn die Registrierung hebt sie nicht auf. Bewahren Sie die Beobachtungen aus dem Test neben dem Plan auf, denn wer das als Nächstes debuggt, will die passende Policy und die protokollierte Quelladresse, nicht eine Beschreibung der Topologie.