Route über zwei Subnetze mit Raspberry Pi

[RalphS]

Zunächst: Management networks sind eigentlich per Design getrennt. Da soll man "von vorne" gar nicht rankommen.

In konkret dieser Situation muß auf der FB eine statische Route eingerichtet werden, sodaß

192.168.200.0/24 192.168.1.50

damit die Fritz!Box weiß, daß Pakete mit 200.0/24 eben nicht ins Internet sollen, sondern zum Raspberry.

Außerdem benötigt das "System" eine Rückroute, damit es auch antworten kann.
Hierfür ist der Raspberry zuständig.
Da ist dann die Frage, was dort bereits eingerichtet ist. IP Forwarding muß aktiv sein.
Der eingerichtete Standardgateway des Raspberry sollte auch für die Pakete aus Richtung System in Richtung Internet genügen, wenn das der Fall ist.

Ein potentielles Problem gibt es nur, wenn das System ins Internet soll und der Raspberry aber nicht.
Da müßte man dann mit iptables/nftables ran und über die FORWARD Chain gehen. Ansonsten sorgt jede passende Route auf dem Raspberry nur dafür, daß dieser ebenfalls Zugriff aufs Internet bekommt.

Note, iptables/nftables kann man im Zweifel auch so fürs Routing mitverwenden, wenn man das möchte. Dann hätte man nur einen Anlaufpunkt fürs "Paketmanagement" und nicht mehrere.


Für ein Managementnetwork wäre die Herangehensweise allerdings eine andere:
1. Einen PC zum Management-PC befördern, kann zB der Windows PC sein
2. Zweite NIC dran (wenn nicht bereits vorhanden)
3. Zweiten Switch beschaffen
4. Die Managementports von PC und System mit diesem Switch verbinden.

Prinzipiell ginge das auch über VLAN, aber Fritz!Box hust.

 

[levelextreme]

wäre das dann: ip route add 192.168.200.0/24 dev eth0 192.168.1.0/24 dev wlan0
?

Das funktioniert so nicht, es sagt entweder duplicate oder garbage. Bin leider nicht so der Linux experte.

 

[Salamimander]

Da hat dein Linux recht, das ist garbage..

Du bist irgendwie komplett falsch unterwegs.

Wenn das Thema für dich so extrem Weltfremd ist, dann lasse lieber die Finger davon.

Ließ noch mal ganz genau, was du eigentlich tun sollst und an welcher Stelle, dann fällt dir der Fehler in deinem route add command auch selber auf.

 

[Raijin]

ich konfiguriere also die Route dafür auf dem Pi.

Das funktioniert so nicht, es sagt entweder duplicate oder garbage. Bin leider nicht so der Linux experte.

Der PI  hat bereits alle nötigen Routen. Sobald zB eth0 eine IP bekommt, wird automatisch eine Route für das Subnetz angelegt. Hat der PI zwei IPs, gilt das entsprechend für beide. Mehr muss der PI zum Routing nicht tun. Der PI weiß somit, dass Subnetz A über eth0 erreichbar ist und Subnetz B über wlan0.

Die oben erwähnte Option IP-Forwarding sagt dem Betriebssystem lediglich, dass Netzwerkpakete, die nicht für den PI selbst bestimmt sind - also eine andere Ziel-IP haben als die des PI - nicht einfach verworfen/ignoriert werden, sondern weitergeleitet werden. IP-Forwarding heißt also nichts anderes als IP-Weiterleitung. Ist das =0 macht der PI einfach nix, routet nicht, antwortet nicht, null, nada, niente, weil die Pakete nicht für ihn bestimmt sind und er ja eben nicht forwarden soll. Mit =1 tut der PI aber dann genau das, weiterleiten.

Am PI lann bzw muss neben den jeweiligen IP-Adressen an den Interfaces somit abgesehen von IP-Forwarding nichts weiter eingestellt werden.
Es sei denn die FORWARD Chain von iptables steht auf default:drop oder ist anderweitig eingestellt und blockt somit jedwede Weiterleitung (trotz IP-Forwarding=1). Hierzu bitte mal bei iptables checken wie die FORWARD Chain aussieht. Im einfachsten Fall steht da default accept

Routen benötigst du nur an der Quelle und am Ziel bzw ggfs in dessen Standardgateway. Trägst du die Route wie beschrieben in der Fritzbox ein, wird dein PC die Verbindung zum Ziel zunächst Richtung Fritzbox schicken (Standardgateway) und die Fritzbox wird zum PI weiterleiten. Der PI prüft IP-Forwarding, prüft die FORWARD Chain von iptables auf Freigabe und leitet anschließend durch die oben erwähnte automatische Route an eth0 weiter zum Ziel.

Das Ziel wiederum bekommt nun eine Vernindungsanfrage aus einem anderen Subnetz. Nun kann die Firewall des Ziels selbst hier schon sagen "Nein, nur Verbindungen aus dem lokalen Subnetz erlaubt". D.h. man muss die Firewall des Ziels ggfs um eine Ausnahme erweitern, die Anfragen aus 192.168.1.0/24 zulässt. Ist das bereits der Fall bzw steht die Firewall auf "Quell-IP=egal" würde das Ziel nun antworten wollen. Dazu prüft es seine eigene Routing-Tabelle auf einen passenden Eintrag und nimmt ggfs die Standardroute, wenn keine bessere Route gefunden wurde. Das Ziel schickt seine Antwort also ohne explizite Route für 192.168.1.0/24 Richtung Standardgateway oder verwirft die Antwort, wenn es kein Standardgateway gibt.
Ergo muss das Ziel eine händische 192.168.1er Route via PI bekommen oder aber das dortige Standardgateway.

Dies ist der Weg über reines Routing, setzt aber administrativen Zugang zum Ziel-System oder dessen Standardgateway voraus. Ist weder noch gegeben, muss man am PI SNAT/masquerade einrichten. Das ist eine Funktion bei iptables, die kurz vorm Abschicken der besagten IP-Weiterleitung die Absende-IP austauscht und statt Quell-IP=192.168.1.x die Quell-IP auf die IP von wlan0 des PI setzt. Am Ziel kommt also die weitergeleitete Verbindung an und das Ziel glaubt, der PI wäre der Urheber. Der PI liegt im Subnetz des Ziels und somit wird es ihm auch direkt antworten und der PI übersetzt das dann zurück und leitet die Antwort gemäß seiner Interfaceroute wieder an den PC zurück.


Wie du siehst steckt der Teufel im Detail und es steht und fällt mit dem administrativen Zugang zum Ziel und/oder dessen Gateway. Sonst bist du auf (S)NAT/masquerade im PI angewiesen.