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