Multiple routes by uid-owner

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(My apologies if this is a repeat message-- netfilter.org appeared to be 
having some difficulties at the time of my original posting yesterday, 
and the new post has not appeared-- I'm assuming it's been lost) 

Hi, 

I'm currently trying to test several independent internet links. 

To do this, I instantiate two or more interfaces, which I aim to allow
to route packets as though two separate machines were each independently
connected to the internet, and independently downloading some file using
http. 

- I run wget http://www.google.com with uid=500
- I run wget http://www.google.com with uid=501 

- I set up using iptables; 
chain OUTPUT
 MARK all -- anywhere    anywhere  OWNER UID match 500 MARK set 0x1
 MARK all -- anywhere    anywhere  OWNER UID match 501 MARK set 0x2


- I set up using ip; 

ip rule add fwmark 1 table link1
ip rule add fwmark 2 table link2 
ip route add default dev ppp0 table link1
ip route add default dev ppp1 table link2

- This all works more-or-less correctly.  
Now, running wget and tcpdump reveals a DNS lookup going out on the
correct interface, depending of course which userid is running. 

Notably, the SOURCE address isn't that of the PPP interface, it's of
another (ethernet) interface in the machine.  Now, for profiling the
connection, this is clearly unacceptable (Packets need to come back on
the interface they were sent!)  Now, IIUC, an application can bind to
any given source address-- but this is a bad idea in my case, since it
requires each application be aware of its environment-- fine if my test
is ALWAYS wget (since I have the source), but bad generally. 

So, I've turned to SNAT, which I'm abusing to switch the source IP
address to that of the ppp interface on the way out.  

A la, 

iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source x.x.x.x 

This certainly fixes the issue of errant source address, but now, a
totally different problem..... Packets coming IN off the ppp interface
(now bearing the correct address) don't appear to make it to the
application! :( 

I had no idea what was going on, but suffice to say started messing
around with the PREROUTING table enough to notice that these returning
packets don't seem to traverse that hook either; they must be dropped
somewhere in the kernel, however I'm not sure where or why.  I had been
thinking that a corresponding DNAT rule (as crude as it must sound)
would be a quick-and-dirty solution, but since the packets don't enter
that chain.. Well, it's a non-starter :( 

Why are the packets dropped?   The requests are sent out over the same
interface on which they are received (Which is a noted caveat for
netfilter).  









[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux