[erledigt] IP Routing erzwingen - Server und Client gleiches Netz, anderes Standard-Gateway

[McAldo]

Eine zusammenfassende Überschrift ist etwas schwierig für dieses Thema.

Folgender Netzaufbau ist vorhanden:


Server und Clients sind mit einem Standardgatway verbunden für den Weg ins Internet. Der Server hat aber noch ein Interface ins Client-Netz um darüber DHCP-Anfragen zu stellen. Wenn einem Client-Rechner z.B. eine SSH Verbindung zum Server aufgebaut werden soll, geht die zur IP aus dem Netz 192.168.10.0, über das Default-Gateway. Der Server sendet das Paket aber dann direkt über das Interface heraus, welches im Client-Netz hängt.
Wie kann ich das System dazu "zwingen", die Pakete, die über das Interface im Netz 192.168.10.0/24 herein kommen, auch wieder darüber hinaus zu senden?

Versucht hatte ich schon das: https://unix.stackexchange.com/question ... s-incoming
Klappte aber nicht. Da sind die Hosts zumindest nicht im gleichen Netz.
Gibt es eine Möglichkeit das zu lösen? DHCP-Relay ist aktuell leider nicht möglich.

[bluestar]

Du könntest auf deinem Router einstellen, dass du Subnetz 192.168.5.0/24 bei Zugriff auf die 192.168.10.0/24 maskierst...

Leider gibt dein Bild keine Antwort auf die Frage "Warum dein Server in beiden Subnetzen steht", ein derartiges Konstrukt zu vermeiden wäre höchstwahrscheinlich einfacher.

[unitra]

Um DHCP Anfragen zu beantworten richtet man am "default-gateway" ein "dhcp relay" ein. So macht man das in 99% der Fälle. Der Router nimmt die Broadcastanfrage an aus dem Clientnetz an, und leitet es weiter per Unicast and die IP Adresse des DHCP Servers, hier z.B. 192.168.10.10 (imaginäre IP Adresse des Servers im Subnetz 192.168.10.0/24).

Wenn der Router aber keine DHCP Relay Funktion hat, dann könnte man das so ähnlich lösen wie in der Zeichnung. Das ist aber ein blöder Netzwerkhack und nicht zu empfehlen, weil es ein Glückssache ist ob es nach dem nächsten Update auch funktioniert. Im schlimsten Fall verlierst Du Stunden oder Tage um das wieder ans Laufen zu kriegen.

Um IP Pakete zu zwingen über die NIC die Anfragen rauszuschicken wo sie reingekommen sind kann man "source routing" benutzen.
https://lartc.org/howto/lartc.rpdb.multiple-links.html . Siehe 4.2.1. Split access im URL.

Mehr Informationen über IP Pakete und zwingen findet man in dem Beitrag: viewtopic.php?f=30&t=173007

Ob das in dem Fall wie Du es schilderst klappt, musst Du ausprobieren. Denn eigentlich sind beide Fragen zunächst getrennte Netzwerkprobleme.

Ich schließe mich der Meinung von bluestar an, das Netzwerkdesign in der Graphik ist, ich sage das mal vorsichtig, suboptimal, oder verbesserungswürdig. Besser ist es die 2-te NIC am Server wegzulassen aus dem Clientnetz, dann wäre das sauber und zuverlässig.

... Der Server hat aber noch ein Interface ins Client-Netz um darüber DHCP-Anfragen zu stellen.
....
Wie kann ich das System dazu "zwingen", die Pakete, die über das Interface im Netz 192.168.10.0/24 herein kommen, auch wieder darüber hinaus zu senden?
...

[McAldo]

Ich habe es mal noch etwas erweitert:


Wie geschrieben, im Moment kann ich kein DHCP-Relay einrichten. Das große Problem sind z.B. SSH-Verbindungen aus Netz 192.168.5.0/24, die durch das Default-Gateway über 192.168.10.2 hereinkommen, weil nur auf eth1 der SSH-Daemon lauscht. Da eine Absender-IP z.B. 192.168.5.20 sein kann, wird das Paket dann über eth0 zurück geschickt.

Es muss also das hereinkommende Paket aus Netz 192.168.5.0/24 irgendwie markiert werden, um es wieder über eth1 zurück zu schicken. Da bisher keine der Anleitungen mit firewall-mark oder anderem geholfen hat, bin ich mir nicht sicher, ob das überhaupt geht. Auf dem Gateway kann ich diesbezüglich auch nichts einstellen (fragt da bitte nicht, es waren Windows-Admins am Werk ...). Ich muss das für den Moment auf diesem DHCP-Server lösen.

Es müsste etwas wie ein PREROUTING MASQUERADING sein. Aber das gibt es ja so in der Form nicht.

[McAldo]

Habe das Problem nun erstmal damit gelöst, den sshd doch an eth0 lauschen zu lassen. Geplant ist ein DHCP-Replay auf dem Gateway einzurichten, aber da muss erstmal ein Bug behoben werden durch den Hersteller.