Netzwerkbrücke
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Eine Netzwerkbrücke (engl. bridge, im folgenden Text: Brücke) ist eine netzwerktechnische Funktion, welche mehrere Netzwerkschnittstellen mit derselben Übertragungstechnik auf Ebene 2 (Data-Link-Layer, L2) im Netzwerkschichtenmodell miteinander verbindet: Ethernet mit Ethernet (IEEE 802.3), Token-Ring mit Token-Ring (IEEE 803.5) usw., aber nicht z.B. Ethernet mit WiFi/WLAN (IEEE 802.11). Dagegen kann man auf Ebene 1 die unterschiedlichen Varianten der Ethernet-Familie in einer Brücke zusammen koppeln. Die einzelnen Schnittstellen der Brücke werden Ports genannt. Alles was man an einem Port hinein schickt, kommt an einem, einigen oder an allen anderen Ports wieder heraus. Auch Broadcast-, Arp- und sonstige L2-Pakete, die ein auf Ebene 3 (L3) arbeitender Router normalerweise blockiert, laufen frei über eine Brücke.
Eine solche Funktion kann sowohl als Hardware, aber auch in Software realisiert werden. Die ursprünglichen Geräte heißen Hub (engl. hub) und waren tatsächlich dumme Mehrfachsteckdosen für Netzwerkkabel. Jedes empfangene Netzwerkpaket wurde an allen anderen Ports wieder ausgesendet. Solche Geräte gibt es heutzutage nicht mehr, sondern es wird durchweg die Weiterentwicklung zum switching hub eingesetzt. Bei diesen Geräten wird jedes empfangene Paket nur an die statisch konfigurierten oder dynamisch gelernten relevanten Ports wieder ausgesendet, meistens sogar nur an einem einzigen Port. Entscheidendes Kriterium für die Filterung ist die L2-Zieladresse (MAC-Adresse) des Netzwerkpakets. Die in der Praxis als unerträglich lang empfundene Bezeichnung switching hub wird durchweg abgekürzt zu Switch (engl. switch).
In diesem Artikel geht es um die Realisierung einer Brücke bzw. eines Hub/Switch für Ethernet in Software. Dabei können neben realen Hardware-Schnittstellen auch Software-Schnittstellen als Ports verwendet werden.
Eine Brücke kümmert sich überhaupt nicht um IP-Pakete oder IP-Adressen oder sonstigen Kram ab Ebene 3 und benötigt für ihre Funktion auch keine IP-Adresse. Man kann einem als Brücke arbeitenden Rechner aber durchaus eine IP-Adresse geben und darf diese auch der Schnittstellengruppe einer Brücke zuweisen. Dies ist zweckmäßig, wenn der Rechner aus dem Internet Software-Updates beziehen soll oder wenn man die Brücke über das Netzwerk aus der Ferne verwalten möchte.
Eine praktische Anwendung für eine Brücke ist bei der Virtualisierung die Kommunikation zwischen Containern oder virtuellen Maschinen oder zwischen Gast- und Wirt-Maschine (host). Jede Maschine bekommt einen Port einer Brücke in der Wirt-Maschine.
Mit einer Brücke kann auch die Aufgabe der Internetverbindungsfreigabe eines Rechners realisiert werden.
Für weitere Anwendungen siehe Einsatzszenarien.
Schnittstellen mit unterschiedlicher Übertragungstechnik, insbesondere Ethernet und WiFi/WLAN, können nicht direkt in einer Brücke gekoppelt werden. Der Abschnitt „Brücken in drahtlose Netze“ beschreibt aber einen Weg, der diesem oft nachgefragtem Wunsch sehr nahe kommt.
Die Funktionalität „Netzwerkbrücke“ (bridging) wurde im Linux-Kernel beginnend mit Version 2.2 eingebaut und ist spätestens ab Version 2.6.18 voll funktionsfähig. Sie muss allerdings bei der Konfiguration des Kernels vor der Übersetzung aktiviert werden, was bei allen Ubuntu-Kerneln der Fall ist.
Die Funktionalität der nativen Linux-Implementierung ist eine Teilmenge der in der Norm ANSI/IEEE 802.1d (2000) beschriebenen Funktionalität für Brücken.
Eine Alternative zur Implementierung im Linux-Kernel bietet das Paket openvswitch, welches im weiteren hier aber unberücksichtigt bleibt.
Die Einrichtung und Konfiguration einer Brücke erfolgt mit den im bei Ubuntu immer installiertem Paket iproute2 enthaltenen Dienstprogrammen ip und bridge.
Installation (optional)¶
Im Widerspruch zu der im Internet vielfach vertretenen Meinung ist das Paket bridge-utils seit Kernel Version 3.0 nicht erforderlich. Lediglich wenn man das Netzwerk über ifupdown konfigurieren möchte, ist dieses Paket nützlich, weil es die Syntax der Datei /etc/network/interfaces um einige Vokabeln erweitert. Außerdem enthält es das Programm brctl zur Einstellung von Betriebsparametern der Brücke als Alternative zu den Programmen ip und bridge.
Folgendes Paket kann installiert [1] werden, seit Juni 2020 ist es aber nach Einschätzung seines Supporters veraltet und bleibt in diesem Artikel unberücksichtigt:
bridge-utils
Befehl zum Installieren der Pakete:
sudo apt-get install bridge-utils
Oder mit apturl installieren, Link: apt://bridge-utils
Einrichtung¶
Hinweis:
In den konkreten Beispielen werden beispielhaft diese Namen benutzt, welche durch zutreffende eigene Bezeichnungen ersetzt werden müssen:
HUBals Name der Brückeport0,eth0usw. als Namen für die Ports einer Brücke
Manuelle Einrichtung¶
Zur Grundeinrichtung benutzt man das Programm ip aus dem Paket iproute2. Alle Befehle müssen als root bzw. in einer root-Shell ausgeführt werden. [2][3]
Erschaffung einer Brücke HUB aus dem Nichts:
ip link add HUB type bridge
Eine vorhandene Schnittstelle port0 als Port einer vorhandenen Brücke hinzufügen bzw entfernen:
ip link set port0 master HUB ip link set port0 nomaster
Eigenschaften eines Ports ändern funktioniert genauso wie auch bei Schnittstellen außerhalb einer Brücke. Als Folge des Beitritts zur Brücke können sich aber Parameter der Schnittstelle ändern und es kommen weitere Eigenschaften hinzu:
ip link set port0 set mtu 1500 # Setzt max. benutzbare Länge im Ethernet-Paket. bridge link set dev port0 guard on # Schaltet die Auswertung von BPDU an diesem Port aus.
Eigenschaften der Brücke ändern. Hier wird beispielhaft das Spanning Tree Protokoll (STP) ein- und ausgeschaltet:
ip link set HUB stp_state 1 # STP einschalten ip link set HUB stp_state 0 # STP ausschalten
Eine für die jeweilig konkrete Situation unzweckmäßige Einstellung kann zur völligen Fehlfunktion und sogar zum Defekt der Hardware führen!
Es gibt noch etliche weitere Parameter für Brücken und deren Ports. Alle zeigt dieser Befehl:
ip --detail link show HUB ip -d link show port0
Die Option --detail kann mit -d abgekürzt werden. Erklärungen siehe die Manpage:
man ip-link
Zur Anzeige des Betriebszustandes und für weitere Einstellungen kann man auch das Programm bridge aus dem Paket iproute2 gebrauchen:
bridge link bridge -d link
Dieses Programm zeigt auch die Adresstabellen der Brücke an, und man kann die Einträge auch modifizieren. Die Manpage beschreibt die Details:
man bridge
Automatische Einrichtung beim Rechnerstart¶
Man kann zur Konfiguration einer Brücke auch die bei Ubuntu üblichen Konfigurationsprogramme ifupdown, NetworkManager oder systemd-networkd einsetzen. Der gleichzeitige Betrieb von mehr als einem dieser Programme kann Störungen verursachen. Zur Deaktivierung nicht verwendeter Konfiguratoren siehe Netplan/Deaktivieren.
per ifupdown¶
Eine Datei /etc/network/interfaces könnte so aussehen [4].
auto lo
iface lo inet loopback
up ip link add HUB type bridge || true
iface HUB inet manual
up ip link set $PHYSICAL stp_state 1
up ip link set $PHYSICAL forward_delay 2
auto HUB
iface HUB-Port inet manual
pre-up ip link set $PHYSICAL master HUB
post-down ip link set $PHYSICAL nomaster
auto port0 port1 port2 eth0Man missbraucht die Konfiguration für die Schnittstelle lo, um nebenbei die Brücke HUB als Schnittstelle anzulegen, die anschließend die bei iface HUB beschriebene Konfiguration erhält. Jedem als Port vorgesehenen Schnittstelle lt. der letzten Liste per auto wird über ein Mapping die Konfiguration HUB-Port zugewiesen.
per systemd-networkd¶
Zur Einrichtung einer Netzwerkbrücke mit systemd-networkd siehe hier.
mit NetworkManager¶
NetworkManager ordnet beim Start vorhandenen Schnittstellen ein passendes Verbindungsprofil zu und erzeugt auch für vorhandene Verbindungsprofile Software-Schnittstellen. Die benötigten Profile kann man mit dem GUI-Programm nm-connection-editor oder mit den im Artikel NetworkManager/NetworkManager ohne GUI beschriebenen Methoden oder auch im Terminal [2] erstellen.
Verbindungsprofil für die Brücke HUB erstellen:
nmcli connection add type bridge ifname HUB
Der Verbindungsname (z.B. bridge-HUB) wird angezeigt und das Verbindungsprofil wird mit der Methode DHCP für IPv4 bzw. Auto für IPv6 erstellt. Man kann beides ändern, z.B. deaktivieren:
nmcli connection modify bridge-HUB ipv4.method disabled nmcli connection modify bridge-HUB ipv6.method disabled
Für jede Schnittstelle, welche als Port arbeiten soll, muss man ein eigenes Verbindungsprofil erstellen, denn im Gegensatz zu ifupdown und systemd-networkd kann NetworkManager ein Profil immer nur für eine Schnittstelle verwenden. In der GUI bearbeitet man das Verbindungsprofil für die Brücke und fügt unter „Brücke/Verbindungen über Brücke“ die Ports hinzu. Auf der Kommandozeile erledigt das dieser Befehl:
nmcli connection add type bridge-slave ifname port0 master HUB
Beim Neustart der Rechners wird die Brücke angelegt und nach dem Einstecken des Ethernet-Kabels wird auch der Port der Brücke zugeteilt.
Spanning Tree Protokoll¶
Beim Zusammenschalten aller Arten von Brücken, und natürlich auch mit Hardware-Switchen, sind nicht beliebige, sondern nur baumartige Strukturen zulässig. Alle Kombinationen mit Schleifen (Maschen, Loops, mehreren möglichen Wegen zwischen zwei Teilnehmern) sind unzulässig, denn auf diesen Schleifen können Ethernet-Pakete endlos kreisen und damit Übertragungskapazität vernichten oder im Extremfall sogar Hardware zerstören.
In großen Verbünden von Brücken, z.B. in Rechenzentren oder Kommunikationsnetzen, schaltet man sogar bewusst mehrere redundante Wege zwischen den Komponenten, was ohne Gegenmaßnahme zum Versagen des Gesamtsystems führt.
Das Spanning Tree Protokoll (bridge_stp) löst Zirkelschlüsse auf und optimiert Wege im L2-Netzwerk. Es benutzt dafür eigene Netzwerkpakete des Typs BPDU (Bridge Protocol Data Unit), welche regelmäßig zwischen den Teilnehmern des L2-Netzwerks ausgetauscht werden. Beim Hinzufügen oder Ändern und beim Ausfall eines Teilnehmers wird eine Reorganisation ausgelöst. Dabei wird zuerst ein Teilnehmer zur root-bridge gewählt (bzw. bevorzugt im Amt bestätigt), der dann den Wechsel der Topologie steuert; dabei werden gezielt Ports gesperrt um Schleifen zu unterbrechen. Die automatisch erreichte Baumstruktur entspricht aber nur dann einer der vorgesehenen Konfigurationen, wenn sich der Verwalter des L2-Netzwerk vorher um die Priorität jeder Brücke und die Kosten jeder Verbindung gekümmert hat.
Wer mehrere Brücken verwendet, die aus Unachtsamkeit kreisförmig verschaltet werden könnten, sollte STP zur Vorsicht aktivieren. Wer bewusst kreisförmige LAN-Konstruktionen verwendet, muss auf es auf jeden Fall aktivieren. Alle anderen können STP deaktivieren.
STP benötigt viel Zeit für eine Reorganisation des Netzwerks, per Standardeinstellung 50 Sekunden. Während dieser Totzeit werden normale Ethernet-Pakete nicht weitergegeben. Das Zeitverhalten wird gesteuert über diese Parameter:
| Parameter für STP | |||
| Parameter | Voreinstellung | Beschreibung | Vorschlagswert |
| hello_time | 2 Sekunden | Zeitdauer zwischen BPDU-Paketen | 1 Sekunde |
| max_age | 20 Sekunden | Totzeit im Zustand "blocking" | 4 Sekunden |
| forward_delay | 15 Sekunden | Totzeit in Zuständen "listening" und "learning" | 4 Sekunden |
| 50 Sekunden | gesamte Totzeit | 12 Sekunden | |
Bei einem Verbund weniger Brücken kann man die in der Tabelle vorgeschlagenen Werte einstellen, muss deren Nützlichkeit für den eigenen Anwendungsfall aber erproben.
Die für eine Brücke eingestellten Werte gelten nur, solange diese von der root-bridge getrennt ist, danach werden die Werte von der root-bridge übernommen.
Das zu STP kompatible Protokoll RSTP (Rapid Spanning Tree Protocol) arbeitet schneller, ist aber bei Linux in der nativen Implementierung nicht enthalten. Hardware-Switche mit Linux-Betriebssystem verwenden deshalb herstellerspezifische Erweiterungen oder alternative Implementierungen. Es gibt auch herstellerspezifische Protokolle für die Aufgaben des STP, welche untereinander und zu STP/RSTP nicht kompatibel sind.
Einsatzszenarien¶
Netzwerkverkehr abhören¶
Den Netzwerkverkehr zwischen zwei Rechnern A und B kann man (z.B. zwecks Diagnose) leicht abhören, indem man einen weiteren Rechner C mit zwei Ethernet-Schnittstellen in die Verbindung einschleift, auf diesem Rechner eine Brücke einrichtet, und tcpdump oder Wireshark verwendet. Wenn es wirklich um Diagnose geht, sollte man für diese Brücke STP ausschalten. Ein Angreifer, der solches z.B. für Werksspionage nutzt, wird dagegen möglicherweise STP einschalten und sogar versuchen, sein Schnüffelgerät zur root-bridge zu machen, weil dann der gesamte Verkehr des L2-Netzwerks über seine Abhöreinrichtung läuft.
Den gleichen Effekt erzielt man auch mit einem (jetzt wirklich dummen!) Hub, an den man die Rechner A, B und C anschließt, weil ein Hub ja jedes Netzwerkpaket an jedem Port ausgibt. Mit einem Switch funktioniert diese Vorgehensweise erst dann, wenn man ihn so konfiguriert, dass er jede gelernte MAC-Adresse sofort wieder vergisst und ihn damit zum dummen Hub degradiert.
Bei einem Switch mit Linux als Bridging-Software kann man dies erreichen, indem man die Dauer der Speicherung der MAC-Adressen auf 0 Sekunden setzt:
ip link set HUB ageing_time 0
Stealth Firewall¶
Dies ist eine Variante des vorstehend beschriebenen Vorgehens. Man kann den Netzwerkverkehr mit Netfilter analysieren und modifizieren. Zur Konfiguration der Regeln benutzt man iptables und verwandte Werkzeuge oder nftables.
Man hat diese Möglichkeiten:
Mit dem Modul physdev für iptables kann man auf L3 in der Forward-Chain nach einem Port der Brücke selektieren. Dieses Beispiel selektiert über den Port
port1einlaufende Pakete:iptables -I forward -m physdev --physdev-in port1 …
Das funktioniert genauso mit ip6tables.
Mit dem Programm ebtables kann man Regeln auf L2 formulieren.
NFTables kann alle Regelsätze von Netfilter bearbeiten.
Den Paketfilter kann man mit einem Network Intrusion Detection System wie snort kombinieren. Eine solche Firewall kann nur sehr schwer gezielt angegriffen werden, ist aber natürlich wie jedes zustandsbehaftete System mit einem hinreichend brutalen DoS-Angriff zu überwältigen.
Auf einem Rechner mit einer solchen Firewall muss man STP unbedingt ausschalten, denn mit einem gefälschten und entsprechend präparierten BPDU-Paket kann man sie sonst abschießen!
Standorte auf Layer 2 verbinden¶
An jedem Standorten existiert eine Brücke. Diese sind durch schnelle WAN-Verbindungen verbunden, welche Ethernet-Pakete über UDP/IP tunneln.
Brücken in drahtlose Netze¶
Die beiden Übertagungstechniken Ethernet (IEEE 802.3) und WiFi/WLAN (IEEE 802.11) verwenden für die Netzwerkpakete unterschiedliche Formate, die für eine Verbindung ineinander umgewandelt werden müssen. Dies fällt nicht in den Funktionsbereich einer Brücke und die native Implementierung im Linux-Kernel beherscht diese Umsetzung nicht (mehr). Die ohnehin zur Kopplung an ein Funknetzwerk benötigten Programme wpa_supplicant und hostapd enthalten aber einen derartigen Umsetzer. Man muss ihn nur aktivieren und kann dann eine WLAN-Schnittstelle einer Brücke als Port hinzufügen, weil die WLAN-Programme die Hardware in den 4-Adressen-Modus (4addr mode) umschalten.
Siehe: WLAN mit systemd-networkd
Leider funktioniert das nicht mit allen WLAN-Karten. Der Artikel WLAN-Router beschreibt die technischen Anforderungen.
Die Umschaltung in den 4-Adressen-Modus ist die einzige erforderliche Maßnahme, aber auch die einzige Möglichkeit zum Betrieb einer WLAN-Schnittstelle als Port einer (Pseudo-) Brücke. (Tatsächlich ist der Umsetzer ein transparenter Router.) Der sog. WDS-Modus ist eine spezielle Variante des 4-Adressen-Modus. Leider war in den ersten Normen der optionale 4-Adressen-Modus unvollständig definiert, was zu einer Fülle untereinander inkompatibler herstellerspezifischer Varianten von WDS geführt hat.
Bei Hardware ohne 4-Adressen-Modus kann man anstatt einer Brücke einen Router konfigurieren, siehe WLAN-Router.
Problembehebung¶
DHCP funktioniert nicht¶
Die bei der Standardeinstellung lange Totzeit von 50 Sekunden nach dem Einschalten einer Brücke mit STP kann einen DHCP-Client mit kürzerer Wartezeit zur Aufgabe veranlassen.
Abhilfen:
STP ausschalten.
Totzeit für STP verringern.
Wartezeit des DHCP-Client verlängern.
Start der DHCP-Client verzögern.
Pakete verschwinden¶
Generell wird jedes Paket ignoriert, wenn der Zielport für dieses Paket eine zu geringe MTU eingestellt hat. Ein L2-Netzwerk arbeitet nur dann gut, wenn alle Komponenten denselben MTU-Wert verwenden. Man sollte in der Regel dem Automatismus vertrauen und die MTU-Werte nicht selbst einstellen. Der Automatismus wird ausgeschaltet, indem man einen MTU-Wert einstellt. Er kann nicht wieder eingeschaltet werden.
Bei einem Verbund von Brücken sollte man kontrollieren, ob bei allen Ein-/Ausgängen des gesamten Netzwerks derselbe MTU-Wert wirksam ist und nur eingreifen, wenn dies nicht der Fall ist oder man aus anderen Gründen einen anderen Wert benötigt.
Links¶
Portal für Zugang zu einigen IEEE-Normen 🇬🇧 – Es muss bei IEEE ein Account angelegt werden. Danach hat man kostenfreien Zugang zu ausgewählten, gesponsorten Normen.
Understanding Linux Network Internals (OpenBook) 🇬🇧 – Enthält u.a. eine immer noch lesenswerte detaillierte Beschreibung des STP und dessen Implementierung in Linux. (Copyright und Lizenz beachten!)