☰

Warum kann in meinem Fall auf die an die Bridge angeschlossene physische Schnittstelle nicht über das Internet zugegriffen werden?

tag-icon • tag-icon linux networking bridge
Warum kann in meinem Fall auf die an die Bridge angeschlossene physische Schnittstelle nicht über das Internet zugegriffen werden?

Ich habe eine Netzwerktopologie wie diese:

Sie sehen, em1(1.1.8.209) ist die physische Schnittstelle, mit der ich über das Internet kommunizieren kann. Und ich habe zwei VM-Instanzen erstellt: PID 8740und PID 8817, beide verwenden die Netzwerk-IP 1.1.8.210/29und 1.1.8.211/29, beide öffentliche IP-Adressen.

Jetzt kann ich über das Internet mit em1 kommunizieren.

aber ich habe eine Anforderung: Ich möchte direkt auf die beiden VMs zugreifen, also möchte ich em1 anhängen br0.

dann habe ich dies ausgeführt:

brctl addif br0 em1

Die Topologie sieht folgendermaßen aus:

Bildbeschreibung hier eingeben

1.1.8.209Nachdem ich diesen Befehl ausgeführt habe, erhalte ich jedoch eine Fehlermeldung und kann nicht mehr kommunizieren . Dann habe ich den Anhang gelöscht brctl delif br0 em1und kann 1.1.8.209jetzt darauf zugreifen.

Warum habe ich dieses Problem? Ich verstehe es nicht. Bitte helfen Sie mir, es zu erklären.

Antwort1

Wenn die Schnittstelle zu einem Bridge-Port wird, nimmt sie nicht mehr am Routing teil.

Die Einzelheiten auf niedrigerer Ebene werden in diesem Blog beschrieben.Richtige Isolierung einer Linux-Brücke:

  1. Übergeben Sie den Frame an einen globalen oder gerätespezifischen Protokollhandler (z. B. IPv4, ARP, IPv6).

    Für eine überbrückte Schnittstelle hat der Kernel einen gerätespezifischen Empfangshandler konfiguriert br_handle_frame(). Diese Funktion erlaubt keine weitere Verarbeitung im Kontext der eingehenden Schnittstelle, außer für STP- und LLDP-Frames oder wenn „brouting“ aktiviert ist. Daher ist dieProtokollhandler werden nie ausgeführtin diesem Fall.

Die IP-Adresse eines solchen Bridge-Ports wird für das eingehende Paket irrelevant. Wenn sie unverändert bleibt, kann dies das ordnungsgemäße Routing für ausgehende Pakete beeinträchtigen, da diese weiterhin direkt über den Bridge-Port gesendet werden können (obwohl dies nicht mehr der Fall sein sollte).

Was getan werden muss, ist, die IP-Adresse entweder auf ein System (oder einen Netzwerk-Namespace oder sogar das andere freie Ende eines Veth-Paares an derselben Stelle) zu verschieben, dessen anderes Ende mit der Brücke verbunden ist, oder auf den Self-Port der Brücke, also die Brücke selbst. Während dieser Verschiebung wird es immer ein kleines Zeitfenster geben, in dem es zu Störungen kommt, daher dürfen lokal durchgeführte Aktionen zum Ändern dieser Konfiguration nicht vom Netzwerkzugriff abhängen (z. B. dürfen sie nicht davon abhängen, Befehle remote über eine Shell unter Verwendung der gestörten Route einzugeben).

Ich werde im Folgenden nur neuere Tools mit neuerer Syntax verwenden.

Zum Beispiel:

ip address flush dev em1
ip address add 1.1.8.209/29 dev br0

Stattdessen ein anderer Weg, der die Brücke verlässt, die nicht am Routing teilnimmt, und der eine zusätzlichevethDas Ende des Paars (im selben Netzwerk-Namespace), das am Routing teilnehmen soll, könnte sein:

ip address flush dev em1
ip link add name em1twin type veth peer name br0portem1twin
ip link set br0portem1twin master br0 up
ip link set em1twin up
ip address add 1.1.8.209/29 dev em1twin

In beiden Fällen gilt: Wenn eine Standardroute (oder andere Routen) von der Existenz dieser Adresse abhängig war, muss diese Route ebenfalls erneut hinzugefügt werden, da sie verschwunden ist.

verwandte Informationen