Isolierte TAP-Bridge zwischen zwei Boards über OpenVPN

Zwei Entwicklungsboards sollen ein Ethernet-Segment teilen, während ihre Bänke in verschiedenen Gebäuden stehen. Der Tunnel existiert bereits und transportiert bereits Ethernet, also sieht die restliche Arbeit wie drei Befehle aus und ist es nicht. Was der Host mit einem gebridgten Frame macht, wohin die eigene Adresse des PCs gehört und welche Grenze die Bridge nicht erzeugt, sind drei getrennte Fakten, und den zweiten falsch zu machen ist der übliche Grund, warum ein Labor unregelmäßig läuft und sein Verwaltungszugang still schlechter wird. Keiner dieser drei Fakten ist in einem Topologiediagramm sichtbar.

Der folgende Weg setzt eine authentifizierte TAP-Verbindung zwischen zwei Linux-PCs voraus, einen dedizierten Kabelport pro Bank und eine Verwaltungsschnittstelle, die nicht Teil des Experiments ist. Die Reihenfolge zählt: erst Frames, dann Adressen, zuletzt die Grenze.

Was die Bridge tatsächlich bewegt

Eine Bridge ist ein in Software implementierter Switch. Sie lernt, welche MAC-Adresse hinter welchem Mitgliedsport erscheint, und leitet Frames zwischen Mitgliedern weiter, ohne eine IP-Routingtabelle zu konsultieren. Nichts in dieser Beschreibung enthält ein Subnetz, ein Gateway oder eine Standardroute, weshalb das Aktivieren von IP-Weiterleitung diese Anbindung nicht erzeugt und weshalb ein Ping gelingen kann, während anderer Verkehr weiter scheitert. Ein Board kann seinen Partner ganz ohne konfigurierte Standardroute erreichen, was Leute überrascht, die erwarten, dass sich Layer zwei wie Layer drei verhält.

Jeder PC steuert einen Kabelport zur Bridge und das TAP-Gerät derselben Bridge bei, sodass ein Frame von einem Board in den lokalen Port eintritt, an das TAP-Gerät weitergeleitet wird, den Tunnel überquert, am TAP-Gerät des Partners ankommt und zum Board des Partners hinausgeleitet wird. Der Tunnel ist ein Mitgliedsport wie jeder andere, und die Bridge weiß nicht und kümmert sich nicht darum, dass dahinter ein VPN liegt. Diese Symmetrie macht das Beispiel leicht nachvollziehbar: Jede Seite hat einen laborseitigen Port und einen Tunnelport, und keine Seite ist besonders.

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

Die identischen Namen auf beiden PCs sind lokale Namen, keine gemeinsamen Objekte. Zwischen den Bänken gibt es einen Ethernet-Pfad, ohne zweites Kabel und ohne zweiten Tunnel, der eine Schleife schließt; eine Bridge, die dieselbe MAC auf zwei Ports ankommen sieht, leitet fröhlich im Kreis weiter.

Adressieren Sie die Bridge, nicht ihre Mitgliedsports

Die Identität des PCs im Laborsegment gehört zum Bridge-Gerät. Mitgliedsports bleiben unnummeriert, denn ein Port ist ein weiterleitendes Mitglied, und eine Adresse darauf würde einen zweiten, konkurrierenden Eigentümer desselben Segments schaffen. Das ist die Korrektur, die die meisten selbstgebauten Rezepte falsch machen: Sie adressieren das TAP-Gerät und die Bridge und wundern sich dann, welches der Partner tatsächlich erreicht.

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

Der Partner verwendet dieselbe Form mit einer anderen Host-Adresse, und die Boards nehmen Adressen im selben Bereich mit der Bridge-Adresse des PCs als nächstem Hop, wenn sie einen brauchen. Verwenden Sie Dokumentationsbereiche, bis der Plan vereinbart ist, und reservieren Sie den Bereich, damit er nicht mit etwas kollidiert, das das Büro bereits routet. Bevor Sie irgendetwas davon ausführen, bestätigen Sie, dass die Mitgliedsports keine Restadresse, keinen DHCP-Client und keine Mitgliedschaft in einer anderen Bridge tragen, und gleichen Sie die Adressierung des TAP-Geräts über das ab, was die Tunnelkonfiguration besitzt, damit es später keine Adresse wiederherstellt.

Warum ein dedizierter Port pro Bank

Ein dedizierter Kabelport ist das, was verhindert, dass das Experiment zu einer büroweiten Änderung wird. Die Verwaltungsschnittstelle trägt SSH, die Standardroute und die äußere VPN-Verbindung, und nichts davon gehört auf eine Bridge, deren Zweck es ist, Laborframes zu bewegen.

Einen Verwaltungsadapter anzubinden bringt das Büro-LAN eine Weiterleitungsentscheidung weit von einem Entwicklungsboard entfernt, und ein Board, das sich auf Layer zwei schlecht benimmt, ist genau die Art Gerät, das Sie in diesem Segment nicht wollen. Ein Wi-Fi-Adapter ist schlimmer: eine Funkschnittstelle im Infrastrukturmodus zu bridgen verhält sich nicht wie Ethernet zu bridgen, und der Fehler ist verwirrend statt sauber.

Halten Sie den Laborbereich aus jedem Produktions-DHCP-Bereich heraus. Wenn die Boards später dynamische Adressierung brauchen, ist ein autorisierter Zuteiler mit einem Pool die einzige Anordnung, die vorhersehbar bleibt; die gewöhnlichen Router zweier Standorte, die im selben Segment antworten, erzeugen Adressen, die niemand erklären kann.

Die Grenze, die die Bridge nicht erzeugt

Bridging ist kein Routing und auch keine Isolierung. Frames, die die Bridge überqueren, können immer noch die Filter-Hooks des Hosts erreichen, abhängig vom installierten Bridge-Netfilter-Pfad, also muss die effektive Richtlinie geprüft statt angenommen werden. Die Firewall zu deaktivieren, weil ein Frame verloren ging, tauscht einen konkreten Fehler gegen einen allgemeinen.

IP-Weiterleitung zwischen der Bridge und jeder Verwaltungs- oder Uplink-Schnittstelle sollte aus bleiben oder ausdrücklich verweigert werden, und das ist eine von der Bridge-Mitgliedschaft getrennte Kontrolle. Ein Board, das die Laboradresse des PCs als Gateway wählt, testet genau das: Wenn der Verwaltungsverkehr durchkommt, war die beabsichtigte Grenze nie da.

Zwei weitere Familien verdienen eine ausdrückliche Entscheidung. Der Adressplan macht die Bridge nicht IPv4-only, also brauchen IPv6 und andere EtherTypes ihren eigenen Plan oder Filter. Und ein erfolgreicher Ping sagt nichts darüber, ob die Discovery-Broadcasts, Multicast-Gruppen oder Jumbo-Frames des Boards den Pfad passieren, denn das sind verschiedene Verkehrsklassen mit verschiedenen Vorgaben.

Schließlich sind Transport und Vertraulichkeit zwei verschiedene Käufe. TAP trägt Ethernet; der OpenVPN-Dienst liefert den Schutz drumherum. Ein VXLAN-Overlay trägt ebenfalls Ethernet und liefert für sich genommen keine Vertraulichkeit, sodass das Ersetzen des einen durch das andere die Sicherheitseigenschaften ändert, selbst wenn das Topologiediagramm identisch aussieht.

Dauerhaftigkeit und die Tests, die sie belegen

Ein einmal nach dem Verbinden getippter Befehl ist keine Konfiguration. Machen Sie die Bridge, die Port-Mitgliedschaft und die eine Host-Adresse über den vorhandenen Netzwerkmanager des PCs dauerhaft und binden Sie die Anbindung an das Erscheinen des TAP-Geräts, damit ein Wiederverbinden keine Bridge mit verschwundenem Mitglied hinterlässt.

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

Testen Sie dann, was die Boards in beide Richtungen tatsächlich brauchen, verbinden Sie den Tunnel neu und starten Sie einen PC nach dem genehmigten Wiederherstellungsplan neu. Bestätigen Sie danach drei Dinge: Der Verwaltungszugang funktioniert weiterhin unabhängig, keine doppelte Laboradresse erscheint, und keine unerwartete Produktionsschnittstelle ist der Bridge beigetreten. Diese Kombination ist der Beweis, dass das Experiment in seiner Bank geblieben ist.