Bridge nicht erreichbar

[qnavwhat]

Hallo,

mein Szenario ist schnell erklärt. Ich habe 1 Router, 1 PC, 1 RPI - auf dem RPI hab ich mit brctl eine Netzwerkbrücke aufgebaut welche vom Router eine eigene IP bezogen hat. Das Netz dahinter ist im Subnetz.
Die Bridge verbindet etho0 mit einem virtuellen Port. An eth0 steckt die Verbindung zum Router.

In ifconfig bzw. ip a sieht alles gut aus, alle Interfaces 'up' und mit IP. Mein Problem ist nun dass ich den RPI nicht anpingen kann (weder die Brücke, noch eth0 oder den virtuellen Port). Der RPI kann auch nicht pingen, außer an sich selbst.

dhclient läuft und port_forwarding ist auch aktiviert

Ohne Brücke kann ich eth0 anpingen, ohne Probleme, aber mit Brücke ist der RPI garnicht zu gebrauchen

Hoffe ihr könnt mir helfen

Gruß

[rendegast]

Per
/etc/network/interfaces
konfiguriert?
Diese Datei posten?

In ifconfig bzw. ip a sieht alles gut aus, alle Interfaces 'up' und mit IP.

?

[heisenberg]

Prüfe doch mal folgendes, und stelle die Ausgaben hier rein(Code Tags bitte):

1. Ausgabe ip a von PC und Raspi
2. Ausgabe brctl show vom Raspi
3. IP+Netzmaske vom internen Netzwerkinterface des Routers

[BenutzerGa4gooPh]

Wenn ich es richtig verstanden habe, ist der nicht pingbare RPI als Bridge konfiguriert. Eine Bridge arbeitet ausschließlich auf OSI Layer 2 (Ethernet/WLAN) und interessiert sich erst mal nicht für IP-Protokoll. Transparent für IP. Genau wie ein Switch oder reiner WLAN-Accesspoint. Beide benoetigen für ihre Funktion gar keine eigene IP-Adr. Entweder ist ein zusätzlicher (logischer) IP-Managementzugang zu konfigurieren oder der RPI als Router zu konfigurieren, dann wäre jedes Interface mit IP-Adresse versehen und pingbar und das Gerät inband erreichbar. Sowie per Loopback-Interface. Vlt. funktioniert das mit Loopback auch bei Bridges.

DHCP (inband) ist auf einer Bridge oder WLAN-Accesspoint nicht sinnvoll, bei einem Switch sieht das jeder sofort ein, einen Switch kann man jedoch als Multiport-Bridge betrachten. Für Managemenzugang (outband) muss man sich was einfallen lassen, kenne mich dazu aber nur bei Lancom und Cisco aus. Dafür wäre dann eine feste IP (evtl.auch per DHCP-MAC-IP-Zuordnung) sinnvoll. Bei Switches/Accesspoints/Bridges nutzt man unterschiedliche VLANs für Management (terminiert)und Nutzdaten (durchgeleitet), bei Routern erfolgt das inband per Loopback-Interface oder über die Interface-Adressen.

Also du brauchst fuer Bridge-Management auf einem phys. Interface 2 logische, eines inband für Brueckenfunktion mit einem anderen physischen und ein terminierendes (outband) mit IP-Adr. für Management. Portforwarding für NAT auf Bridge fuer Management? Wäre nicht sinnvoll - ausser evtl. fuer Fernmanagement.

https://learningnetwork.cisco.com/thread/30501
Loopback-If unter IPv4: Netzmaske /32 sinnvoll und üblich.

[dufty2]

Es ist durchaus üblich unter Linux der Bridge selbst eine IP zu geben.
Üblicher als Loopback-Adressen würd' ich mal sagen.

Aus der Beschreibung heraus vermute ich, daß sowohl der Bridge als auch dem eth0 eine IP verpasst wurde.
Dies ist eher unüblich, die IP bekommt nur das Bridge-interface,
vgl. auch https://wiki.debian.org/BridgeNetworkConnections

[BenutzerGa4gooPh]

dufty2 hat bezueglich Debian (sowie Ubuntu) vollkommen Recht, habe mich daraufhin auch belesen, hier noch auf deutsch:
https://wiki.ubuntuusers.de/Netzwerkbrücke/
Also Bridge mit IP-Adr. und "stinknormaler" Netzmaske.

(Zum auf der Bridge laufenden Debian wird wohl einfach inband mit gebrückt. Na ja, sicherheitstechnisch Geschmackssache - zumindest ohne weitere Vorkehrungen. Innerhalb eines Homenetzwerks ohne WLAN belanglos und bequem.)

[qnavwhat]

Ich hatte auch gelesen dass Netzwerkbrücken auf Layer 2 arbeiten (also MAC), dachte also es würde somit mit ping nicht funktionieren.
Nachdem ich etwas probiert hatte und lediglich der Brücke eine IP gegeben hab (ja, ich hatte initial auch den beiden Ports eine IP verpasst), konnte ich auch die Brücke anpingen. Nun gibt es also lediglich EINE IP für den RPI, die IP für die Netzwerkbrücke.
Obwohl alle Geräte bei diesem Szenario nun in einem Netz waren, gehe ich davon aus, dass es auch mit einem Subnetz funktioniert - Tests folgen dafür muss dann aber NAT genutzt werden.
Kurz und knapp, ich habe also nachdem ich die Brücke mit brctl erstellt habe eine flush auf die verbundenen Ports gemacht und es lief

Auf ins Subnet

[MSfree]

gehe ich davon aus, dass es auch mit einem Subnetz funktioniert

Nein, wenn du separate Subnetze willst, muß der Raspi als Router konfiguriert werden und nicht als Bridge.

[BenutzerGa4gooPh]

Entweder wie MSfree schrieb oder:

Nutzung verschiedener VLANs auf (Mulitiport-) Bridge und Routing der VLANs mit unterschiedlichen Subnets durch externen, VLAN-faehigen Router (evtl. extra VLAN mit extra Subnet für Bridge-Management / Rasp mit konfigurierter Bridge)
https://wiki.debian.org/BridgeNetworkCo ... with_VLANs
(Hat aber wenig Sinn für deine wenigen Bruecken-Ports - hast ja nur eth0 und wlan0 - ausser du willst den Management-Zugang zum Rasp von den Nutzdaten derart trennen, dass du z. B. mit Accesslist dazwischen routest. Wäre sinnvoll für Absicherung eines vorher nur gebridgten WLAN-Zuganges. Vmtl. ist jedoch eine Konfiguration als Router für dich am sinnvollsten und einfachsten. In der letzten (?) c't war ein interessantes Routing-Projekt mit Sniffing und IPv6.)

nicht sinnvoll:
unterschiedliche, nur gebridgte Subnets: Wäre das Gleiche wie mehrere PCs mit unterschiedlichen, auf PCs konfigurierten Subnets in einem einzigen LAN-Segment.

[dufty2]

Mmmh, also streng genommen wissen wir nichts von einem "wlan0".
Er (oder sie) schreibt nur von einem "virtuellen port" (was immer auch das sein soll).
Und der PC kann auch direkt am Router hängen, muss nicht notwendigerweise "hinter" dem Raspi stehen.

Und bevor wir uns mit VLANs & Co hier beschäftigen, sollten wir es lieber möglichst einfach halten.
Oder nicht?

[BenutzerGa4gooPh]

Auf ins Subnet

Wenn dann sinnvoll, Router ist schon okay. Sollte der TE aus meiner AW erkennen. Der Raspi hat doch WLAN?!

[qnavwhat]

Oh na das gestaltet sich doch schwieriger als gedacht.
Zunächst, ich habe ein Raspi3 und da ist wlan sogar direkt mit bei.

Mein Ziel ist es den (bzw dann die) Raspi etwas abgekapselt vom restlichen Netz zu betreiben, sprich in einem Subnet. Die Erkenntnis über die Bridge ist zwar gut aber scheint nicht weiter relevant zu sein für das was ich möchte. Am einfachsten wäre sicher einen Router dazwischen zu setzen oder gar den Raspi als Router zu konfigurieren (dass andere Raspi's im Subnet mit dem PC kommunizieren können).

In die VLAN Sache les ich mich mal rein, vllt hilft mir das weiter

[BenutzerGa4gooPh]

Eine Trennung deiner Raspis vom restlichen Netz sollte dein vorhandener Router machen - oder ein Raspi, der als Router konfiguriert wird. Letzterer hat aber wohl nur 2 phys. Interfaces, WLAN und Ethernet.

VLANs brauchst du dann, um auf einem physischen Port (Trunk) logische Trennungen für mehrere physische Accessports an Bridges oder Switches oder Accesspoints vorzunehmen. Um diese auf einem Router (restriktiv) zu verbinden. Ich empfehle, die VLAN-Routing-Geschichte erst mal konzeptionell zu recherchieren (debian-unspezifisch). Z. B.
http://www.dell.com/downloads/global/pr ... ote_38.pdf

Selbst bei einem reinen Bastelprojekt ist es gut, wenn man die zu erfüllende Aufgabe für sich und andere definiert, vielleicht so: Raspi als
- Luxus-WLAN-Accesspoint mit einem Ethernet-VLAN-Trunk-Port und unterschiedlich getaggten VLANs für Management, Eigen- und Gast-WLAN, die dann ein anderer, VLAN-fähiger Router (Raspi) erkennen und restriktiv verbinden muss
- Router mit einem Ethernet-VLAN-Trunk-Port der zwischen unterschiedlich getaggten VLANs routen kann
- WLAN-Router ohne VLANs, Trennung WLAN und Gast-WLAN über Accesslists
- einfacher WLAN-Accesspoint
- oder oder

Ich kann dir aber sagen, dass VLANs privat kaum verwendet werden, das "erschlägt" man einfach über physich getrennte Router-Ports - notfalls mit mehreren Switches bei mehreren Router-Ports, evtl. zusätzlicher Accesspoints, wenn der Router keine Trennung Gast-Eigen-WLAN kann..

[dufty2]

VTP wird nicht klappen, da Cisco-eigen.
Unter Linux müsste man dafür Multiple VLAN Registration Protocol (MVRP) nehmen.

Aber bei diesem Netzwerk ein bisschen overkill

[BenutzerGa4gooPh]

@dufty2:
Oh stimmt, nach IEEE 802.1Q wurde das VLAN-Tagging (endlich,) standardisiert. Bin schon eine alte, proprietäre Saeckin. Wie nennt man das Protokoll an sich jetzt unter Netzwerkern kurz und herstelleruebergreifend? "Tagged Frames nach IEEE 802.1Q" erscheint mir zu unhandlich/unmundlich - müsste aber sinngemäß VTP entsprechen. (Untagged VLANs wären reine Ethernet-Frames ausserhalb eines Switches. Tagged VLANs betreffen wohl mehr das Konzept, dazu gehört nur u. a. das Protokoll.)
Na ich korrigiere mal meinen letzten Beitrag "herstellerübergreifend".

Basteln und Lernen ist doch kein Overkill, bei Dauerbetrieb sieht's anders aus.

[dufty2]

VLAN Trunking Protocol (VTP) ist zum Managen von zig VLANs resp. Switchen gedacht.

Hat man einen trunk mit mehreren (getaggten) VLANs spricht man einfach von ".1q" (dot-one-q).

Vielleicht verrät uns qnavwhat noch, was er für einen Router hat, dann müssen wir nicht über mögliche enterprise-features rätseln

[BenutzerGa4gooPh]

Vielleicht verrät uns qnavwhat noch, was er für einen Router hat, dann müssen wir nicht über mögliche enterprise-features rätseln

Das Bridging-Problem ist eh gelöst, neuer Thread mit neuer Projektbeschreibung?