Raspberry Pi's per Ethernet/LAN koppeln?

theSplit

1998
Registriert
3 Aug. 2014
Beiträge
5.857
Nabend,

ich habe hier einen Raspberry Pi 3b bei dem "scheinbar" das Wifi, ich vermute, aufgrund eines Hardwaredefekts des Wifi-Chips, nicht mehr ansprechbar ist.

Nun hätte ich die Überlegung den Raspberry Pi an einen anderen Raspberry Pi (z.B. die 4te Generation) über Ethernetkabel mit dem bestehenden, teils defekten Pi, zu koppeln. Könnte man den zweiten, neuen, Raspberry Pi dann, theoretisch, ans Wlan verbinden und auch gleichzeitig DHCP Server für den anderen Pi spielen lassen, über Ethernetkabel?
 
Ich nehme an, Deine Raspberrys laufen mit Linux? Dann schieb ich Dich mal dahin, das klingt mir eher nach einem Softwareproblem als nach Hardware. :)

Was Du vermutlich suchst:




Allerdings frage ich mich, wozu Du bei einem einzelnen nachgeschalteten Client zwingend DHCP brauchst. Würde da eher eine statische IP vergeben.
 
Du kannst auf dem zweiten Raspi auch beide Adapter bridgen, dann leitet er den Verkehr nur durch zum anderen, inklusive DHCP etc.

Aber: Wozu der Aufwand? Klemm das Teil halt an einen Switch direkt ran und nimm den zweiten besser her, um die Aufgaben des ersten zu übernehmen, wenn der unbedingt an einer nicht LAN-angebundenen Stelle sitzen muss.
 
  • Thread Starter Thread Starter
  • #4
Den Raspberry Pi direkt an den Switch/Router zu hängen fällt flach, da in anderem Raum und ausschließlich über SSH wollte ich nicht auf das Gerät zugreifen. Daher wäre wichtig "es vor der Nase stehen zu haben".

Das mit dem Bridgen klingt interessant. Wenn du da etwas an der Hand hast oder eine Empfehlung, würde ich mich über mehr Informationen dazu freuen. Wirklich akut würde es dann aber erst, vermutlich, nächsten Monat werden.
 
  • Thread Starter Thread Starter
  • #6
Kannst du dich daran erinnern, dass du mal bemängelt hast, dass ich "chmod +x" anstelle der Bitmask empfohlen habe?

Genau so kurz ist dein Tip ;) - ich hab jetzt danach gesucht und bin auch fündig geworden, hier, mit dem Fazit:
a) nur temporär und nach Reboot futsch
b) leitet (scheinbar) alle Traffic weiter, nicht nach Interface getrennt (hauptsache IPv4?) ?

Tausend Dank, da hast du mir den richtigen Tip gegeben. Die Links im Kompendium zu dnsmasq und auch zu raspberrypi.org helfen wunder und sind, bis auf minimale Konfiguration sehr leicht verständlich. Und auch mit statischer IP, gerade eben wegen SSH zum Beispiel.

...

Grundsätzlich wäre aber dnsmasq schon deshalb gut, nicht nur dass man einstellen kann, welches Interface man zum Router nutzt und welches Interface bzw. Netzwerkschnittstelle weitergeleitet wird - gerade auch, jetzt kommts, weil ich eine Host Blackist auf dem routenden PI installieren würde, welche auch mit und innerhalb von dnsmasq funktioniert.
 
Zuletzt bearbeitet:
@theSplit: Korrekt, der Tipp ist kurz, weil auch so einfach.

Nein, der Traffic wird nicht "einfach so" durchgeleitet, sondern natürlich nur, wenn der Empfänger auch auf der anderen Seite zu vermuten ist. D. h. der eigene Netzwerkverkehr wird natürlich nicht weitergeleitet, auch die Antworten nicht, nur die entsprechenden Anfragen an und vom Client auf der anderen Seite. Effektiv arbeitet der Raspi dann als Router, ipcontrack kümmert sich um die korrekten Zuweisungen. Willst du das reboot-sicher haben, schreib dir nen kurzen Systemd-Service (simple), der nach network-online.target installiert wird.
 
  • Thread Starter Thread Starter
  • #8
[,,,] Effektiv arbeitet der Raspi dann als Router, ipcontrack kümmert sich um die korrekten Zuweisungen. Willst du das reboot-sicher haben, schreib dir nen kurzen Systemd-Service (simple), der nach network-online.target installiert wird.

Da muß ich mich erst schlau machen. Habe noch nie mit Systemd-Diensten gearbeitet. Aber momentan würde ich eher zu dnsmasq tendieren. Oder gibt es einen Grund warum man nicht dnsmasq nehmen sollte?
Im Grunde scheint mir dabei die Konfiguration leichter von der Hand zu gehen. Und wie gesagt, das mit der Host Blacklist (in dnsmasq) wäre dann ja gleichzeitig für beide Raspberrys. Von daher würde ich es sowieso installieren wollen.
 
@theSplit: Ja, sollte man nicht machen, weil du sonst zwei DHCP-Server im gleichen Netz hast und das Probleme geben kann. Zumal die richtige Einrichtung von dnsmasq wesentlich komplexer ist als einfach nur ein Forwarding einzurichten mit einem Systemd-Dienst.
 
Unter debian sollte es nicht nötig sein einen systemd Dienst hierfür zu schreiben.

/etc/sysctl.conf:
net.ipv4.ip_forward = 1

das sollte reichen.
Der Artikel ist zwar schon etwas *hust* alt, auf den ersten Blick erscheint mir das aber alles noch als sinnig:



Bitte korrigieren wenn das so deprecated ist dass systemd nun hierfür verwendet werden muss.
 
@PLanB: /etc/sysctl.conf ist uralt, soweit ich weiß auch definitiv deprecated. Aber ja, es ist möglich. Debian ist so stockkonservativ, dass fast alles, was irgendwann mal ging, immer noch läuft. Die schönere Art ist, dafür Systemd zu nutzen, und nach network-online.target.wants zu verlinken.
 
  • Thread Starter Thread Starter
  • #12
Frage an euch, wäre es möglich DNSmasq einzusetzen, mit einer Host-Blocklist und dennoch das IP4 Forwarding zu verwenden?

Wenn ich richitg im Bilde bin, schaltet sich DNSmasq ja nur zwischen die Anfragen vom Hostgerät wie auch dem geforwardeten "Client"? Und muß dann nicht zwingend als DHCP-Server funktionieren?
 
Frage an euch, wäre es möglich DNSmasq einzusetzen, mit einer Host-Blocklist und dennoch das IP4 Forwarding zu verwenden?

Wenn ich richitg im Bilde bin, schaltet sich DNSmasq ja nur zwischen die Anfragen vom Hostgerät wie auch dem geforwardeten "Client"? Und muß dann nicht zwingend als DHCP-Server funktionieren?

Ja, wenn du die Firewall richtig schreibst. Sonst antwortet es nämlich auf alles (wobei du natürlich einrichten kannst, ob es DNS und/oder DHCP machen soll). Schlag dir dnsmasq aus dem Kopf, für deinen Anwendungsfall ist das ungeeignet, weil es nicht die Weiterleitung übernimmt, sondern ein Netzwerk verwalten soll. Das ist nicht das, was du tun willst. Selbst WENN du es einsetzt, und richtig konfigurierst, musst du TROTZDEM den oben genannten Befehl ausführen, weil sonst ists Essig mit der Kommunikation der Netze untereinander. Ich hab das Setup, wie du es betreiben willst, an drei Standorten laufen (mit 2x4 und 1x6 Subnetzen), ich weiß schon, wovon ich rede. Und nein, ohne Firewall ist das grenzdebil, deshalb sind die Scripte auch recht umfangreich.

Systemd wertet auch nur die Variablen aus aus.

Ach ja, richtig, Systemd hat das wieder reaktiviert (wohl, weil RHEL es nutzt), liest aber dafür nicht die PAM-Limits aus (was bei so Sachen wie Soft und Hard FD-Limits echt ätzend ist). Ist trotzdem eher nicht 'the Debian way'.
 
Zurück
Oben