[gelöst] Netzwerk-Bridge eth0 <-> eth1

[TomL]

Moin

Ich habe heute mal ein typisches Schlecht-Wetter-ist-mir-draussen-zu-kalt-Problem und hoffe aber trotzdem auf Eure Hilfe. Im Moment komme ich nicht weiter, weil mir nicht klar ist, ob ich was falsches erwarte oder ob ich einfach nur nen Fehler gemacht habe. Das Problem als solches ist natürlich wieder mal eingerahmt von der Normalität unmengen veralteter HowTo's im Web. Ok... was möchte ich tun? Ganz einfach:

- Mein PC hat zwei NICs, eth0 und eth1.
- eth0 ist das Standard-Interface für alles, eth1 wurde bisher nicht genutzt.
- Ich möchte jetzt eth1 in Betrieb nehmen, um dieses via Patchkabel mit einem RPi zu verbinden, quasi als zweites (eigenes) Netzwerk
- Ich möchte eine Bridge erstellen, die die zwei Netze verbindet, so das der Pi die anderen Clients erreicht und selber ins Internet kann

Ich hab also bisher folgendes gemacht, um das zweite Netz zu starten:

Code: Alles auswählen

ip link add br0 type bridge
ip addr add 10.10.100.1/24 broadcast 10.10.100.255 dev br0

dnsmasq --conf-file=/home/thomas/Install/dnsmasq.conf

ip link set br0 up
ip link set eth1 master br0
ip link set dev eth1 up

Und an diesem Punkt angekommen hätte ich nun erwartet, dass sich eth1 aus dem IP-Range (siehe unten) eine IP aus dem Netz 10.10.100/24 zieht. Tut es aber nicht, weder automatisch noch manuell. Bevor ich mir weitere Gedanken über die Funktion der Bridge mache, muss doch aber zumindest das Client-DHCP-Gedöns via dnsmasq funktionieren.... aber scheinbar habe ich da irgendwo nen Bock drin.

Code: Alles auswählen

# dnsmasq conf 
strict-order
pid-file=/var/run/dnsmasq/dnsmasq.pid
except-interface=lo
bind-dynamic
interface=br0
dhcp-range=10.10.100.2,10.10.100.32
dhcp-no-override
dhcp-leasefile=/var/run/dnsmasq/dnsmasq.leases
dhcp-lease-max=253
dhcp-hostsfile=/var/run/dnsmasq/dnsmasq.hostsfile
addn-hosts=/var/run/dnsmasq/dnsmasq.addnhosts

Warum genau so gelöst? Weil ich gerne etwas mehr von Netzwerken verstehen möchte.

[dufty2]

Eine Bridge funktionokelt ähnlich wie ein Switch auf Layer-2.
Wenn Du also dem bridge-inteface br0 eine IP verpasst, werden eth0 und eth1 zu reinen Paketschubsern degradiert und erhalten selbst keine IP mehr.
Raspi 10.10.100.2, br0 10.10.100.1, fritzbox (default-gateway) 10.10.100.254

Sind es wirklich zwei getrennte Netze, fungiert Dein PC nun als router und nicht mehr als bridge, br0 ist damit hinfällig:
Raspi 10.10.100.2, eth1 10.10.100.1, eth0 192.168.0.1, fritzbox (default-gateway) 192.168.0.254
"IP Forwarding" einschalten nicht vergessen.

[TomL]

Hi Dufty

Ja, das hat mir jetzt deutlich gemacht, dass ich da wohl auf falscher Fährte war. Das folgende trifft es, genau das hatte ich im Sinn:

Sind es wirklich zwei getrennte Netze, fungiert Dein PC nun als router und nicht mehr als bridge, br0 ist damit hinfällig:
Raspi 10.10.100.2, eth1 10.10.100.1, eth0 192.168.0.1, fritzbox (default-gateway) 192.168.0.254
"IP Forwarding" einschalten nicht vergessen.

Jetzt habe ich -dabei das zu vervollständigen- ein Problem, was mich erst mal wieder völlig überraschend kalt erwischt hat und mir unerklärlich ist. Das ist nun die aktuelle Ausgangslage an meinem PC:

eth0 -> 192.168.0/24 = Fritzbox/LAN/Internet
eth1 -> 10.10.100.1/24 mit Crossover-Patchkabel auf RaspberryPi->eth0

Die dnsmasq.conf habe ich nun überarbeitet:

Code: Alles auswählen

 strict-order
 pid-file=/var/run/dnsmasq/dnsmasq.pid
 except-interface=lo
 bind-dynamic
 no-dhcp-interface=eth0
 interface=eth1
 dhcp-range=10.10.100.2,10.10.100.4,2h
 listen-address=127.0.0.1
 listen-address=10.10.100.1
 dhcp-no-override
 dhcp-leasefile=/var/run/dnsmasq/dnsmasq.leases

Jetzt hatte ich erwartet, wenn auf meinem PC eth1 up ist und dnsmasq gestartet ist, dass sich der hochfahrende RPi via seinem dhcpcd-Client eine 10.10.100-IP zieht. Sobald ich ihn an meine Fritzbox hänge, zieht er sich ja auch eine 192'er IP aus meinem LAN. Das verblüffende auf dem RPi ist nun, er startet systemd-network und holt sich via dhcpcd eine IP... und zwar 169.254.22.171. Ich gucke zweimal und denke "häh? wo kommt die denn her?"

Wenn ich nun meiner PC-eth1 zusätzlich mit

Code: Alles auswählen

ip addr add  169.254.22.1/24 dev eth1

eine IP aus gleichem Netz vergebe, ist der RPI sofort erreichbar. Aber das verrückte ist, wo kommt diese IP her? Auf dem PI wird das Netzwerk via systemd-networkd gestart, aber dort ist ausser dhcp=v4 nichts eingestellt. Ein dnsmasq läuft dort nicht. Die dhcpcd-conf enthält keine relevanten Einträge ..... irgendwoher muss der sich doch diese 169er IP vergeben.... wo könnte sich dhcpcd dafür bedienen?

[dufty2]

IP-Adressen aus dem 169.254.0.0/16-Bereich treten dann auf, wenn ein dchp-client seinen dhcp-server keine IP abluchsen kann und sich quasi selbst eine vergibt, damit er wenigstens eine hat.
Man nennt diese "link local"-Adressen (ipv4). Unter Microsoft sind sie als APIPA bekannt.

Kann nicht ganz nachvollziehen, warum Du dynamische IP-Vergabe brauchst bei Deinem doch sehr überschaubaren und eher statischen Konstrukt.

[TomL]

Hi Dufty

IP-Adressen aus dem 169.254.0.0/16-Bereich treten dann auf, wenn ein dchp-client seinen dhcp-server keine IP abluchsen kann und sich quasi selbst eine vergibt, damit er wenigstens eine hat.Man nennt diese "link local"-Adressen (ipv4). Unter Microsoft sind sie als APIPA bekannt.

Ja, das passt zu dem, was ich gerade selber festgestellt habe. Der Verursacher war der Daemon 'dhcpcd'. Nachdem ich den "disabled" hatte, wurde die IP nicht mehr vergeben. Auf eine LL-Adresse unter IPv4 als Background wäre ich jetzt nicht gekommen... das war mir neu.... und wieder was dazugelernt.

Kann nicht ganz nachvollziehen, warum Du dynamische IP-Vergabe brauchst bei Deinem doch sehr überschaubaren und eher statischen Konstrukt.

Von "brauchen" kann keine Rede sein.... ... ich teste nur gerade was und versuche die Zusammenhänge zu verstehen. Da soll jetzt kein fertiges Produkt bei rauskommen... oder anders gesagt, das fertige Produkt wäre "Wissen" (bei mir). Interessant ist aber, dass ich das erfolgreiche Netzwerk des RPi komplett lokal manuell starten und einrichten kann. Vergebe ich ihm eine manuelle IP, funktioniert alles sofort. Ich bekomme aber keine Reaktion, wenn ich den dhclient von Hand starte... keine Journal-Reaktion auf meinem PC, dhclient ist auf dem PI nicht erfolgreich.

Code: Alles auswählen

dhclient -v eth0

Was mich nun irritiert ist die Tatsache, dass sich auf meinem PC im Log (journalctl -f) überhaupt nichts rührt, wenn der RPI via dhclient die IP anfordert... nix, nullkommanix, keine Bewegung.... als würde da nix ankommen. Ich sehe, dass dnsmasq auf Port 53 "lauscht" und sich regelmäßig imJournal aktiv meldet. Ich sehe sofort am PC in der Journalausgabe, wenn ich das Interface am RPI up oder down setze, aber es erfolgt keine Reaktion wenn der RPI->dhclient eine IP anfordert. Als wenn das Interface PC->eth1 nicht auf eine eingehende dhcpc-Anfrage über Port 53 reagieren würde.

Gibt es sowas? Kann das sein? BTW, PC->eth1 ist ein uraltes 10/100-Interface. Ich bin damit auch erst weiterkommen (zur ersten funktionerenden manuellen Test-Verbindung), als ich das normale Patchkabel mit einer Kupplung und einem Crossoverkabel "verlängert" habe. Möglicherweise hat das NIC ein Alters-Problem oder deswegen weniger Funktionen.... *hmmm*

[dufty2]

Ob was ankommt, sieht man recht schnell via z. B.

Code: Alles auswählen

# tcpdump -i eth1

auf dem PC.
Und analog auf dem Raspi machen, um zu sehen, ob dieser auch was verschickt.
Um z. B. auszuschließen, ob Client- resp. Server-seitig nicht etwa iptables und/oder ebtables Pakete blockieren.

[TomL]

Ob was ankommt, sieht man recht schnell via z. B.:::
Um z. B. auszuschließen, ob Client- resp. Server-seitig nicht etwa iptables und/oder ebtables Pakete blockieren.

Oh scheisse.... meine iptables.... .... Ich könnt' gerade vor Scham im Boden versinken...

[TomL]

Es funktioniert! Danke! Ich ärgere mich immer noch, wie ich das übersehen konnte...