Hallo LUG,
ich habe für einen Server (Debian etch) eine primäre IP-Adresse in einem Subnet und 5 weitere IP-Adressen in einem anderen Subnetz. Für beide Netze habe ich separate Gateway und Netzwerkadressen. Da ich nur eine Netzwerkkarte in der Maschine habe, weise ich die Adressen aus dem zweiten Netz über IP-Alias (eth0:1 - eth0:5) zu.
Leider scheint das Routing nicht so zu funktionieren, wie ich das gern hätte. Im Moment werden alle Pakete zu einem externen Netz über das Gateway der primären Adresse geroutet. Für einen Anwendungsfall ist es aber erforderlich, dass Pakete von den IPs des zweiten Subnetzes über dessen Gateway geroutet werden.
Wenn ich für die IP-Adressen aus dem zweiten Subnetz in der /etc/network/interfaces die Gateway-Adresse händisch eintrage, funktioniert das trotzdem nicht, weil anscheinend das default-Gateway für die primäre IP-Adresse gewinnt.
Gibt es eine Lösung für dieses Problem z.B. mit ip route statt mit dem Gateway-Eintrag in der /etc/network/interfaces? Über konstruktive Ideen würde ich mich freuen. Mit Tante google (Suchbegriffe debian ip alias routing) bin ich leider auf keine passende Lösung gestoßen.
Viele Grüße Jan Dittberner
Hallo,
sind die Gateways der verschiedenen Netze physisch gleich, also auch auf einem Rechner mit IP Aliasing? Sowas habe ich vor Ewigkeiten mal machen wollen, da hat mir der Router, ebenfalls eine Linux Kiste, immer ein ICMP Redirect auf seine IP im primären Netz geschickt, die dann aber wiederum nicht im Netz des entsprechenden Alias Interfaces war. Mußte mal mit Ethereal nachschauen, ob das Problem immer noch besteht.
Tschau,
andre
On Mon, Feb 12, 2007 at 05:00:34PM +0100, André Schulze wrote:
sind die Gateways der verschiedenen Netze physisch gleich, also auch auf einem Rechner mit IP Aliasing? Sowas habe ich vor Ewigkeiten mal machen wollen, da hat mir der Router, ebenfalls eine Linux Kiste, immer ein ICMP Redirect auf seine IP im primären Netz geschickt, die dann aber wiederum nicht im Netz des entsprechenden Alias Interfaces war. Mußte mal mit Ethereal nachschauen, ob das Problem immer noch besteht.
die gleiche Hardware scheint es zu sein, zumindest haben beide Gateway-IP-Adressen die gleiche MAC-Adresse (ich habe in /proc/net/arp auf meinem Server nachgesehen)
Ein ICMP-Redirect habe ich mit tshark (Teil von wireshark, dem ethereal-Nachfolger) nicht aufspüren können. Ich habe mal beide Gateways angepingt, was auch funktioniert hat.
Das Problem scheint also, so wie ich das verstehe, ein Routingproblem meiner Kiste zu sein. Ist es denn überhaupt möglich irgendwie zu sagen, dass ein Subnetz das eine default-Gateway und ein anderes ein davon verschiedenes haben soll?
Gruß Jan
Am Mon den 12 Feb 2007 um 08:38:32PM +0100 schrieb Jan Dittberner:
Das Problem scheint also, so wie ich das verstehe, ein Routingproblem meiner Kiste zu sein. Ist es denn überhaupt möglich irgendwie zu sagen, dass ein Subnetz das eine default-Gateway und ein anderes ein davon verschiedenes haben soll?
Es sind ja verschiedene Interfaces und jedes Interface kann AFAIK ja ein eigenes gateway haben, zumindest kann man ja sowas hier sagen:
ifconfig eth0 up 192.168.0.1 default 192.168.0.254 ifconfig eth0:1 up 10.0.0.1 default 10.0.0.254
Das gateway muß ja auch immer im Subnetz des Interfaces liegen, sonst kann das ja seine Pakete nicht loswerden.
Tschau,
andre
Am Montag, 12. Februar 2007 23:00 schrieb André Schulze:
Das gateway muß ja auch immer im Subnetz des Interfaces liegen, sonst kann das ja seine Pakete nicht loswerden.
Stimmt nicht ganz - eine Lösung mit Gateway != Subnetz hatte ich hier schonmal geschrieben. Das ging in etwa so: # rechner1-ip: 192.168.x.y # rechner2-ip: 141.76.z.z rechner1% route add -host 141.76.z.z rechner1% route add default gw rechner2
Etliche Installer (z.B. FreeBSD) prüfen, ob Gateway ein Element von Subnetz ist, und lassen das obige nicht zu. Solche Installer sind kaputt, da steckt mal wieder zuviel Automatismus drin.
Josef
Hi Josef,
On Tue, Feb 13, 2007 at 08:39:24 +0100, Josef Spillner wrote:
Stimmt nicht ganz - eine Loesung mit Gateway != Subnetz hatte ich hier schonmal geschrieben. Das ging in etwa so: # rechner1-ip: 192.168.x.y # rechner2-ip: 141.76.z.z rechner1% route add -host 141.76.z.z rechner1% route add default gw rechner2
Sowas faellt aber in die Kategorie "Krankes Routing"[tm] :) Jedenfalls springt bei diesem Szenario der rp_filter auf rechner2 an, wenn dieser nicht weiss, wo ploetzlich Pakete von 192.168.x.y ueber sein Interface in 141.76.z.z herkommen.
Hab die Sache gerade mit einem physischen Rechner und einem QEMU nachgebaut. Das virtuelle Ethernetkabel zwischen den beiden Rechnern endet in tap0 auf dem Host und eth0 im QEMU-Gast. Auf dem Host hat tap0 die Adresse 10.0.2.2/24, im QEMU-Gast gebe ich eth0 die Adresse 192.168.50.1/24. Dann trage im Gast ich die Hostroute auf 10.0.2.2 ein:
route add -host 10.0.2.2 dev eth0 (ohne das Device eth0 laesst sie sich nicht eintragen)
und setze die Defaultroute ueber 10.0.2.2:
route add default gw 10.0.2.2. Wenn ich nun
Wenn ich jetzt im Gast versuche, die Defaultroute zu benutzen
ping 1.2.3.4
antwortet der Host noch nicht mal auf die ARP-Anfragen nach 10.0.2.2, was genau das Verhalten von rp_filter ist: Host sieht auf tap0 ein Paket mit Absenderadresse 192.168.50.1 reinkommen, prueft per Route Lookup, ob er zum Ziel 192.168.50.1 ueber dieses Interface routen wuerde. Das ist nicht der Fall, also geht er von Adress-Spoofing aus schmeisst das Paket weg.
Natuerlich kann man rp_filter ausschalten, aber in den meisten Faellen will man das nicht.
Gruss, Chris
Am Dienstag, 13. Februar 2007 21:54 schrieb Christian Perle:
Sowas faellt aber in die Kategorie "Krankes Routing"[tm] :)
Das kann ich verstehen - aber wenn man sich in einer Netzsituation befindet, in der das nicht anders möglich ist, freut man sich wenn's so geht. In besagter Originalmail war ich glaube ich darauf eingegangen [warum haben wir kein vernünftiges Archiv?]. Die vermurkste Situation war wohl die, dass ich von rechner1 aus über Proxy im lokalen Netz HTTP-Zugriff hatte (seine MAC-Adresse war im Router gesperrt), und rechner2 hingegen eine öffentliche IP-Adresse hatte und über den Router lief (man will ja mehr als HTTP, von beiden Rechnern aus). Ist aber nun > 2 Jahre her, von daher alles IIRC.
Auf alle Fälle sollte man das mal (mitsamt Erwähnung der Auswirkungen) in einem HOWTO veröffentlichen.
Josef
P.S. Spoofing per IP-Adresse ist out. Heutzutage im Zeitalter von Web Services und WS-Adressing (= Antwortadresse für asynchrone Aufrufe) kann man das bequem auf XML-Ebene machen und findet jede Menge "Enterprise-Dienste", die das nicht checken, und jede Menge "Security-Spezialisten", die das ebenfalls nicht checken... :-)
Am Mo, 12.02.2007, 23:00, schrieb André Schulze:
Am Mon den 12 Feb 2007 um 08:38:32PM +0100 schrieb Jan Dittberner:
Das Problem scheint also, so wie ich das verstehe, ein Routingproblem meiner Kiste zu sein. Ist es denn überhaupt möglich irgendwie zu sagen, dass ein Subnetz das eine default-Gateway und ein anderes ein davon verschiedenes haben soll?
Es sind ja verschiedene Interfaces und jedes Interface kann AFAIK ja ein eigenes gateway haben, zumindest kann man ja sowas hier sagen:
ifconfig eth0 up 192.168.0.1 default 192.168.0.254 ifconfig eth0:1 up 10.0.0.1 default 10.0.0.254
Das gateway muß ja auch immer im Subnetz des Interfaces liegen, sonst kann das ja seine Pakete nicht loswerden.
Mit dieser Vermutung bin ich auch an die Sache rangegangen. In der /etc/network/interfaces bei Debian schreibt man die Gateway-Adresse ja schließlich auch bei dem jeweiligen Netzwerk-Interface hin.
Prinzipiell funktioniert das Routing ja auch, d.h. ein Paket was von außen an eine Adresse des zweiten Subnetzes geht, wird auch an diese wieder rausgegeben.
Inzwischen nehme ich an, dass es eher ein Konfigurationsproblem des eingesetzten Dienstes ist. Ich schau mir das erst nochmal näher an.
Viele Grüße und Danke für alle bisherigen Denkanstöße Jan
Am Di, 13.02.2007, 08:47, schrieb Jan Dittberner:
Prinzipiell funktioniert das Routing ja auch, d.h. ein Paket was von außen an eine Adresse des zweiten Subnetzes geht, wird auch an diese wieder rausgegeben.
Inzwischen nehme ich an, dass es eher ein Konfigurationsproblem des eingesetzten Dienstes ist. Ich schau mir das erst nochmal näher an.
Diese Vermutung hat sich soeben als richtig herausgestellt. Nachdem ich den Dienst vernünftig konfiguriert habe, arbeitet er jetzt auch mit einer IP-Adresse aus dem zweiten Subnetz.
Viele Grüße Jan
On Monday 12 February 2007 14:44, Jan Dittberner wrote:
Hallo LUG,
Hallo Jan,
ich habe für einen Server (Debian etch) eine primäre IP-Adresse in einem Subnet und 5 weitere IP-Adressen in einem anderen Subnetz. Für beide Netze habe ich separate Gateway und Netzwerkadressen. Da ich nur eine Netzwerkkarte in der Maschine habe, weise ich die Adressen aus dem zweiten Netz über IP-Alias (eth0:1 - eth0:5) zu.
Leider scheint das Routing nicht so zu funktionieren, wie ich das gern hätte. Im Moment werden alle Pakete zu einem externen Netz über das
[...]
Kannst du mal diese Ausgaben von route -n sowie ifconfig (Adresse und Netmaske) schicken. So richtig verstanden habe ich dein Anliegen noch nicht.
Viele Grüße Jan Dittberner
Jens
lug-dd@mailman.schlittermann.de
-
André Schulze -
Christian Perle -
Jan Dittberner -
Jens Lorenz -
Josef Spillner