[[Vorlage(Getestet, )]] [[Vorlage(Fortgeschritten)]] {{{#!vorlage Wissen [:Pakete_installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:sudo: Als Root arbeiten] [:Editor: Einen Editor öffnen] }}} [[Inhaltsverzeichnis(1)]] 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 [#Links Netzwerkschichtenmodell] miteinander verbindet: Ethernet mit Ethernet [#Links (IEEE 802.3)], Token-Ring mit Token-Ring [#Links (IEEE 803.5)] usw., aber nicht z.B. Ethernet mit WiFi/WLAN [#Links (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 Einsatzszenarien]. Schnittstellen mit unterschiedlicher Übertragungstechnik, insbesondere Ethernet und WiFi/WLAN, können nicht direkt in einer Brücke gekoppelt werden. Der Abschnitt [#Bruecken-in-drahtlose-Netze „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 [#Links 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: {{{#!vorlage Paketinstallation bridge-utils }}} = Einrichtung = {{{#!vorlage Hinweis In den konkreten Beispielen werden beispielhaft diese Namen benutzt, welche durch zutreffende eigene Bezeichnungen ersetzt werden müssen: * `HUB` als Name der Brücke * `port0`, `eth0` usw. 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: {{{#!vorlage Befehl ip link add HUB type bridge }}} Eine vorhandene Schnittstelle `port0` als Port einer vorhandenen Brücke hinzufügen bzw entfernen: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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 Spanning Tree Protokoll] (STP) ein- und ausgeschaltet: {{{#!vorlage Befehl 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: {{{#!vorlage 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: {{{#!vorlage Befehl man ip-link }}} Zur Anzeige des Betriebszustandes und für weitere Einstellungen kann man auch das Programm '''bridge''' aus dem Paket '''iproute2''' gebrauchen: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl man bridge }}} == Automatische Einrichtung beim Rechnerstart == Man kann zur Konfiguration einer Brücke auch die bei Ubuntu üblichen Konfigurationsprogramme [:interfaces:ifupdown], [:NetworkManager:] oder [:systemd/networkd: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 eth0 }}} Man 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:systemd-networkd] siehe [:systemd/networkd/#Beispiel-Netzwerkbruecke: 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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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: {{{#!vorlage 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: {{{#!vorlage Tabelle <-4 tableclass="zebra_start3" rowclass="titel" :> 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: {{{#!vorlage Befehl ip link set HUB ageing_time 0 }}} == Stealth Firewall == Dies ist eine Variante des [#Netzwerkverkehr-abhoeren vorstehend beschriebenen Vorgehens]. Man kann den Netzwerkverkehr mit [:iptables2: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 `port1` einlaufende Pakete: \\ {{{#!vorlage Befehl 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 [:WLAN/wpa_supplicant:wpa_supplicant] und [:WLAN_Router/#hostapd: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: [:systemd/WLAN_mit_systemd-networkd:WLAN mit systemd-networkd] Leider funktioniert das nicht mit allen WLAN-Karten. Der Artikel [:WLAN_Router: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: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 = * [https://de.wikipedia.org/wiki/OSI-Modell ISO/OSI-Referenzmodell Netzwerk (Netzwerk-Schichten)] {de} * [https://www.elektronik-kompendium.de/sites/net/0509111.htm Überblick IEEE 802 – Netzwerktechniken] {de} * [https://ieeexplore.ieee.org/browse/standards/get-program/page Portal für Zugang zu einigen IEEE-Normen] {en} – Es muss bei IEEE ein Account angelegt werden. Danach hat man kostenfreien Zugang zu ausgewählten, gesponsorten Normen. * [https://wiki.linuxfoundation.org/networking/bridge Projektseite Linux bridge code] {en} ### * [https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git/ Projektseite bridge-utils] {en} [mark]verschwunden ???[/mark] * [http://ebtables.netfilter.org/ Projektseite ebtables] {en} * [https://github.com/openvswitch/ovs Projektseite openvswitch] {en} * [wikipedia:Spanning_Tree_Protocol:Spanning Tree Protokoll] {de} * [https://doc.lagout.org/operating%20system%20/linux/Understanding%20Linux%20Network%20Internals.pdf Understanding Linux Network Internals (OpenBook)] {en} – Enthält u.a. eine immer noch lesenswerte detaillierte Beschreibung des STP und dessen Implementierung in Linux. (Copyright und Lizenz beachten!) ### Was soll damit geschehen? ### [[Bild(./bridge-entwurf.png, align=center)]] ### * ''VPN erweitern'' [[BR]]Mehrere Rechner des lokalen Netzes in ein ''Virtual Private Network'' einbinden. ### Intel Centrino (ipw2200) funktioniert leider definitiv nicht. # tag: System, Netzwerk, WLAN