I am using tproxy to do source IP address transparency on our proxy, and it is working well. I would like to extend the functionality of tproxy to provide source MAC address and VLAN transparency as well. The proxy in question runs as a transparent bridge, so I think that I have to integrate the tproxy framework with ebtables, but I'm not 100% sure how to go about that. I would like to set up an ebtables (or equivalent) rule that does source MAC natting, similar to the source IP addrses NAT rule used by tproxy today, and I would also like to rewrite the VLAN tag in the outgoing packet to that of the original connection, if any. Can anyone give me any pointers about how to best accomplish what I am trying to do? Thanks, Cam
On Wed, 2007-07-11 at 14:58 -0600, Cameron Schaus wrote:
I am using tproxy to do source IP address transparency on our proxy, and it is working well. I would like to extend the functionality of tproxy to provide source MAC address and VLAN transparency as well. The proxy in question runs as a transparent bridge, so I think that I have to integrate the tproxy framework with ebtables, but I'm not 100% sure how to go about that.
I would like to set up an ebtables (or equivalent) rule that does source MAC natting, similar to the source IP addrses NAT rule used by tproxy today, and I would also like to rewrite the VLAN tag in the outgoing packet to that of the original connection, if any.
Can anyone give me any pointers about how to best accomplish what I am trying to do?
Before starting anything, you should check out our latest tproxy4 patches, posted to netdev@ around March, and work relative to that tree, as I don't want to maintain the old, NAT based approach anymore. Other than that, doing MAC level transparency is not very easy, you need: Input path: ----------- * save the source MAC whenever a connection is redirected (and ignore the fact that destination MAC can change from packet-to-packet) * create a possibility for the proxy application to query this MAC address Output path: ------------ * create a possibility to set the outgoing source MAC address for outgoing connections This violates a couple of layers, thus it is not going to be easy. Especially if you also want to provide MAC level transparency (e.g. you save the destination MAC as well and use this same MAC address for destination on your server side connection to avoid ARP lookups) Anyhow, I'd be interested in such work be integrated to the TProxy proper. -- Bazsi
On Sun, Jul 15, 2007 at 05:38:53PM +0200, Balazs Scheidler wrote:
Before starting anything, you should check out our latest tproxy4 patches, posted to netdev@ around March, and work relative to that tree, as I don't want to maintain the old, NAT based approach anymore.
Thanks for the suggestions. I found the tproxy4 code you made reference to above, and I have looked at the patches. This definately looks like an improvement over the NAT based approach that I have been using to date. I have some questions about the tproxy4 patches posted to the netdev@ list: - how can I access the latest version of this code? Is there a repository I can checkout the source from? - how stable is this code? Is it ready for production? - what does the userspace code look like? From reading the patches, I would expect something like fd = socket(...) setsockopt( fd, SOL_IP, IP_TRANSPARENT, 0, 0 ) bind( fd, foreign_address, ... ) connect(...) or listen(...) Thanks, Cam
On Mon, Jul 16, 2007 at 03:51:28PM -0600, Cameron Schaus wrote:
I have some questions about the tproxy4 patches posted to the netdev@ list: - how can I access the latest version of this code? Is there a repository I can checkout the source from?
I've wondered about this as well.
On Mon, 2007-07-16 at 23:52 +0200, Lennert Buytenhek wrote:
On Mon, Jul 16, 2007 at 03:51:28PM -0600, Cameron Schaus wrote:
I have some questions about the tproxy4 patches posted to the netdev@ list: - how can I access the latest version of this code? Is there a repository I can checkout the source from?
I've wondered about this as well.
I'm currently maintaining our kernel patchset in an StGit repository, and it currently has a single patch for tproxy which I'm refreshing from time to time. This loses history, thus I thought I'd migrate it over to use straight git, and rebasing it all the time. But this has yet to be done. I'll publish the tree as soon as I have some time. -- Bazsi
hi, I can't wait to be a beta user of tproxy4! I plan to build a test environment with kernel patched and a modified version of Dansguardian to test tproxy4. Is there any tarball available?
On Mon, 2007-07-16 at 23:52 +0200, Lennert Buytenhek wrote: On Mon, Jul 16, 2007 at 03:51:28PM -0600, Cameron Schaus wrote:
I have some questions about the tproxy4 patches posted to the netdev@ list: - how can I access the latest version of this code? Is there a repository I can checkout the source from?
I've wondered about this as well.
I'm currently maintaining our kernel patchset in an StGit repository, and it currently has a single patch for tproxy which I'm refreshing from time to time.
This loses history, thus I thought I'd migrate it over to use straight git, and rebasing it all the time. But this has yet to be done.
I'll publish the tree as soon as I have some time.
-- Bazsi
_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
Regards Daniel tooldcas@163.com 2007-07-19
Hi, On h, júl 16, 2007 at 03:51:28 -0600, Cameron Schaus wrote:
- how can I access the latest version of this code? Is there a repository I can checkout the source from? - how stable is this code? Is it ready for production?
I don't know how far Balazs got since the end of May, but it was certainly not production-ready by that time (it wasn't heavily tested).
- what does the userspace code look like? From reading the patches, I would expect something like
fd = socket(...) setsockopt( fd, SOL_IP, IP_TRANSPARENT, 0, 0 ) bind( fd, foreign_address, ... ) connect(...) or listen(...)
Yes, something like this should do. You'll probably need to set IP_FREEBIND, too (or enable the ip_nonlocal_bind sysctl globally) to be able to bind to a foreign address. -- KOVACS Krisztian
participants (5)
-
Balazs Scheidler
-
Cameron Schaus
-
Daniel
-
KOVACS Krisztian
-
Lennert Buytenhek