IP Forwarding

[Trunks2117]

Hallo,

ich habe folgendes Problem. Ein Server (Debian) mit 2 Netzwerkkarten ist folgendermaßen angeschlossen.

An der einen Karte (eth0) ist ein Netzwerk mit DHCP Server angeschlossen.

An der anderen Karte wird vorerst ein Laptop angeschlossen, später ein haufen Laptops.

Ich möchte das der Laptop an eth1 sich eine IP Adresse des Netzwerks zieht, welche an eth0 klemmt.

Sämtlicher Traffic vom Laptop soll ungefiltert über en vorhandenen Router ins Internet gehen.

DHCP auf dem Server ist aus, IP Forwarding an. Ich kriege aber keine DHCP Adresse des anderen Netzes und kann auch nur den Server erreichen.

Der Server selbst kommt ins Internet. Hat einer eine Idee?

Danke

[Crash2001]

Wie soll das denn auch gehen? Ich denke mal, du deutest IP Forwarding anders, als das, was es ist. IP Forwarding ist nichts anderes als Routing für das IP-Protokoll.

Eine MAC-Adresse bekommt vom DHCP-Server auch nur immer genau eine IP-Adresse zugeordnet. Da sich die MAC-Adresse nicht ändert (eth0 des Linux-Servers) funktioniert das ganze so nicht, wie du es vorhast.

Was du jedoch machen könntest, wäre den Linux-Server einfach als DHCP-Server laufen zu lassen.

Ich wüsste jetzt jedoch keinen Grund (laut deiner Beschreibung), der dagegen sprechen würde, einfach vor den Linux-Server einen Switch zu klemmen. Damit vergibt der DHCP-Server die IP-Adresse direkt an die Clients.

Routing funktioniert ja nur, wenn die beiden IP-Adressen aus unterschiedlichen Netzen sind und nicht wenn sie aus dem gleichen Netz sind. Denn woher sollte der Rechner sonst wissen, wann er die Pakete über eth0 und wann über eth1 raus schicken soll? :confused:

Solltest du den Linux-Rechner als Firewall andenken, oder einfach nur als Weiterleitungsrechner (was auch immer das für einen Sinn machen würde) benutzen wollen, dann funktioniert das so nicht.

Dafür benötigst du "Bridging" und nicht "Ip Forwarding".

[flashpixx]

Falls der Rechner bestehen bleiben soll, wäre es dann wohl sinnvoller den Rechner als Bridge zu betreiben, damit laufen die DHCP Request entsprechend bidirektional zwischen eth0 und eth1 ebenso wie die Daten

[axxis]

Ich werf einfach mal DHCP-Relay in den Raum, das entsprechene Package gibts im Debian Repo

[flashpixx]

Ein DHCP Relay nützt erst mal nichts, denn es werden nur die DHCP Pakete entsprechend weiter gereicht ( Dynamic Host Configuration Protocol )

Damit kann man zwar die IP Vergabe in anderen Netzen realisieren, aber andere Datenpakete werden zunächst an dem Rechner blockiert.

[Crash2001]

Erstens das und zweitens bin ich mir doch ziemlich sicher, dass ein DHCP-Relay nur in Verbindung mit Routing funktioniert, denn sonst ist ja wieder das Problem, wo die ausgehenden Pakete überall hingehen sollen. Dafür darf der Router/Gateway imho nur je einen direkten Zugangspunkt zu einem (Sub)Netz haben.

Ein DHCP Relay forwarded die DHCP-Requests ja nur von einem Netz in ein anderes bzw über ein Gateway an die entsprechend konfigurierten IP-Adressen. Die Antwort vom DHCP-Server geht dann direkt an den Rechner, der den Request abgeschickt hat - auch über Subnetgrenzen hinweg.

[Trunks2117]

Bridging klingt interessant.

Ich muss also nur die beiden devices eth0 und eth1 über eine Bridge verbinden und den erlauben in beiden Richtungen einfach alles ungeblockt durchzulassen.

Für Tipps dazu wäre ich dankbar, wie ich was in der iptables einrichten muss und wie das bridged device zu erstellen ist. Google befrage ich dazu jetzt auch mal.

Danke

[axxis]

Sorry, hab mich bezüglich der Netze vertan,

dann hilft dir das vielleicht weiter brctl(8): ethernet bridge administration - Linux man page, Kernel-Modul muss imho geladen sein.

[Trunks2117]

OK, fast funzt es

Mit brctl kann ich eine Bridge erstellen. Mit eth0 promisc und eth1 promisc klappt auch alles.Auch die Devices der Bridge hinzufügen klappt und wenn ich meinen Lappy anschliesse bekommt er eine IP des richtigen DHCP Servers.

Nun hab ich noch ein Problem. Der Server soll beim Kunden aufgebaut werden. Für die Fernwartung ist openvpn installiert und es ist ein tap0 Device konfiguriert.

Sobald ich bridge up eingebe disabled er das Device. Hat dazu einer Ideen? Ohne das Device ist keine Fernwartung möglich

[Servior]

Welchen Sinn hat deine Konfiguration eigentlich?

Ein Switch an dem alle Geräte hängen (Laptops, DHCP Server und Router) erledigt das ganze ohne Probleme.

Die Lösung über eine Bridge verursacht doch mehr Probleme als diese lösen kann.

[Trunks2117]

Der Sinn ist folgender.

Auf der einen Seite steht ein Hotel mit mehreren 100 Zimmern die Internet anbieten. Unser Server muss alle Internetverbindungen überwachen, damit überprüft wird ob ein Gast auch Internet bestellt hat. Dies geschieht normalerweise damit, das der Gast eine eigene IP von uns bekommt und somit für die Abrechnung identifizierbar ist. Unser Kunde möchte aber das die IP nicht von unserem, sondern von deren DHCP Server kommt und wir auf unseren Server mitloggen welches Zimmer welche IP bekommen hat.

Dazu muss der Rechner als bridge dienen. Das Bridging mit eth0 und 1 klappt ja wunderbar, nur leider will das tap0 Device nicht so wie es soll

[Servior]

Wie verhinderst du die Vergabe der IP-Adresse wenn der Kunde kein Internet bestellt hat?

Wie ordnest du die IP-Adresse einem Kunden zu?

Bei den Lösungen die mir im Kopf rumschwirren benötige ich keine Bridge.

[Trunks2117]

Auf den Zimmern stehen Boxen, über welche die Bestellung abläuft.

Jeder bekommt eine IP, aber nur die Zimmer, welche in einer SQL Tabelle als offen stehen können auch raus. Zimmer welche kein Internet bestellt haben sind closed und sehen nur einen Auswahlbildschirm zum bestellen. Dies wird durch unsere eigene Software ermöglicht.

Ich habe jetzt mal Schritt für Schritt überprüft wann das tap0 Device verschwindet. Sobald es der bridge hinzugefügt wird ist es nach einigen Sekunden weg.

Irgendwer eine Idee?

[Servior]

Wenn letztendlich jeder eine IP bekommt würde ich das ganze ohne Bridge lösen.

Ich kenne eure Software nicht und weiß daher auch nicht wie genau ihr die Filterung vornehmt. Liest sich für mich aber wie eine Art Proxy die du brauchst.

Schließ den DHCP Server und die Laptops an einen Switch an, dann hast du die Vergabe der IP-Adressen bereits abgeschlossen und musst nur noch die Filterung einbauen. Ich vermute mal ihr filtert alle Anfragen die an einem Gerät ankommen und überprüft dann die IP im Zusammenhang mit eurer Freigabe.

Dann dürfte es genügen das Standardgateway auf euren Server zu leiten und der Server überprüft dann ob durchgelassen wird oder eure Webseite angezeigt werden soll.

Der Server hat dann die Verbindung zum Internet/Router.

[Trunks2117]

Das ist zwar eventuell möglich, muss doch aber auch über eine bridge lösbar sein. Ich habe bisher keine Lösung gefunden warum das tap= Device nicht mit in die Bridge will.

ETH0 und 1 gehen in den Forwarding mode, aber das tap0 disabled sich dann

[Crash2001]

Ich denke mal das kommt daher, dass wenn eth0 und eth1 in den promiscous Modus versetz werden, das tap-device, das ja die VPN-Verbindung über eine der Schnittstellen entgegennehmen können soll, nicht im promiscous Modus erlaubt ist und Linux das bemerkt und es daher disabled.

Somit würdest du, falls du per VPN Fernwartung machen möchtest auf diesem Gerät noch eine zusätzliche (evtl geht auch eine virtuelle Netzwerkkarte / Subdevice) Netzwerkkarte einrichten müssen.

Ist jedoch nur eine Vermutung.

Andererseits ist der promiscous Modus auch was besonderes, in dem alle Pakete gelesen werden (können) und nicht nur diejenigen, die auch wirklich für den entsprechenden PC gedacht sind (vorausgesetzt sie kommen an dem entsprechenden Port des Switches an) und von daher macht es durchaus Sinn, dass Linux da blockiert und sagt "Nö, VPN darüber will ich nciht machen, das ist mir zu unsicher!" oder etwas in der Art...

Ihr schafft mit der Bridge übrigens ein ziemliches Nadelöhr zwischen dem Router und dem restlichen Netzwerk.

Gut - ich weiß nicht, was für eine Internetanbindung in dem Hotel existiert, aber wird denke ich ja mal schon ein etwas schnelleres DSL sein. Zudem kann das bridging zu Problemen führen, bzw du hast immer eine erhöhte Verzögerung drin, die auch noch lastabhängig ansteigt.

Rein theoretisch könnte ein einziger PC die gesamte Konstruktion lahm legen, indem er den Router, bzw somit gleichzeitig auch den "Bridge-PC" zuflooded mit irgendwelchem Traffic. Da er ja auf dem "Bridge-PC" nicht einfach verworfen wird, sondern die Netzwerkkarten im Promiscous Modus sind und somit alle Pakete annehmen, geht das ganz leicht.

Ich persönlich würde jedenfalls definitiv eine andere Art von Captive Portal verwenden und nciht solche eine umständliche Lösung.

Wieso soll es denn UNBEDINGT über die Bridge gemacht werden, wenn es anders doch viel einfacher geht? :confused:

[Trunks2117]

Bei einer externen Lösung könnte der Kunde unseren PC einfach abklemmen und wir hätten keine Kontrolle mehr über unser System.

Läuft aber der gesamte Verkehr über unseren PC haben wir noch die Kontrolle.

Den VPN Tunnel einfach auf ein Subdevice lenken ist eine gute Idee.

Alternativ wurde mir empfohlen das ich in der iptables einfach nur eintragen soll das jeglicher Traffic auf jeglichen Port zwischen den Karten weitergeleitet wird.

Somit soll auch eine DHCP Anfrage an eth1 an den Server hinter eth0 weitergeleitet werden.

Allerdings habe ich dazu noch keine wirkliche Lösung.

Letzte Alternative ist sonst für mich eine dritte Netzwerkkarte, über welcher der SSH Tunnel läuft, sowie eine Bridge zwischen eth0 und 1

[Crash2001]

Bei einer externen Lösung könnte der Kunde unseren PC einfach abklemmen und wir hätten keine Kontrolle mehr über unser System.

Wen meinst du hier mit "der Kunde"? Den Auftraggeber, oder den Surfer?

Läuft aber der gesamte Verkehr über unseren PC haben wir noch die Kontrolle.

Also da gibt es definitiv auch andere Möglichkeiten für - z.B. per Scripting IP-Adressen auf access-lists setzen auf dem Router o.ä. ...

Letzte Alternative ist sonst für mich eine dritte Netzwerkkarte, über welcher der SSH Tunnel läuft, sowie eine Bridge zwischen eth0 und 1

Wenn Subdevices nicht gehen und du unbedingt die Bridging-Lösung nehmen willst, dann wird dir alternativ nciht viel anderes übrig bleiben als eine dritte NW-Karte einzubauen.