[tproxy] TProxy version 4.0.0 released

Cameron Schaus cam at schaus.ca
Thu Aug 2 23:45:10 CEST 2007


Jan Engelhardt wrote:
>> How can I make sure packets get routed instead of bridged?  Does this involve
>> using the brouting feature of ebtables?
>
> Yes.
>
> In some network layouts, you can use a half-bridge (which is a cool 
> thing but probably requires the same number of steps) to reduce the 
> number of needed ebt rules.

Thanks, using ebtables brouting does appear to work.  However, it may
be cumbersome for my application to use ebtables rules to keep certain
traffic off the bridge while allowing unproxied traffic across the
bridge.

I have a proxy application running on the bridge IP address, and
iptables rules currently direct traffic of interest to the proxy.  I
want to use the tproxy code to perform a foreign connect using the
client's IP address.  So the client's and server's addresses are more
or less arbitrary.  This makes generating ebtables brouting rules that
preserve the bridge behavior for non-proxied traffic difficult.

What is currently stopping the packets from being diverted locally
once they enter the bridge?  As I understand it now, the packets
destined for the foreign IP address should enter the bridge, and since
they are destined for the bridge MAC address they should enter the
correct protocol handler.  At some point the frames should enter IP
tables PREROUTING where the tproxy code is invoked.  However,
something isn't right.  Perhaps it's because the packet device is
replaced with the bridge device and this doesn't match the socket
information?  I'd like to understand what isn't working in this case.

One way around this is to add a check in br_handle_frame to get the
socket and check if inet->freebind is set, similar to the tproxy
prerouting code.  One drawback of this is that fragmented IP packets
cannot be reassembled to obtain the IP addresses and ports, and would
end up lost in the stack.  An ebtables module could likely be written
to avoid modifying the bridge code.

Are there better ways of getting these foreign packets into the
network stack when they are destined for a local bridge interface?

Thanks,
Cam


More information about the tproxy mailing list