On Sun, Sep 15, 2013 at 12:52 AM, Eliezer Croitoru <eliezer_at_ngtech.co.il> wrote:
> I have found the problem and I will rephrase the problem description:
> While using tproxy the main issue is that the ports of the source IP is
NOPE. As I said before, it's NOT related to TPROXY code at all. Same
problem exists, even when you try to bind with 2+ local IPs. Check
both scenarios with my test script provided above.
> beeing decreased to half for the same pair of ip:Xport to ip:Xport.
> Which means that 192.168.1.1 cannot connect like regular proxy to 65k
> ports but to 32k ports which makes IP "cheaper".
> it's the same for server and client both..
> While using the port range of:
> # cat /proc/sys/net/ipv4/ip_local_port_range
> 32768 32867
> #end
> the main issue is that the OS tries to bind using a 0 value maximum
> ports per IP by the above mentioned value.
Let me rephrase the issue. With the above config (100 ports allowed
for auto-selection) the maximum number of ports you can assign is
exactly 100. But it has to be n*100, where n is the number of IPs you
use (either local or remote with TPROXY)
> the kernel itself wont even try to bind an already binded ip+port so
> there is no need for the upper layers of the user-land to "recover" from
> such a state.
> leaving these matters to the kernel level is much more appropriate from
> any aspect you look at the OS.
That's for sure. The problem is that I don't believe the kernel guys
will fix this issue soon. So we have to adapt on application layer.
Niki
Received on Sun Sep 15 2013 - 12:45:37 MDT
This archive was generated by hypermail 2.2.0 : Sun Sep 15 2013 - 12:00:04 MDT