Are you sure? Take a look into: http://tldp.org/HOWTO/TransparentProxy-6.html Regards El Vie, 9 de Marzo de 2007, 1:05, Alec Matusis escribió: > I have not considered bridge and ebtables yet. I assume I'd have to > implement this in the "routing" box A. Is ebtables CPU-intensive? The goal > of setting up this forwarding is to reduce the load on the router box A. > > Also, is it very surprising that there is no way to build a transparent > proxy/router with standard iproute2 and iptables tools ONLY? It would seem > that transparent forwarding of TCP connections to another machine is a > very > common task. > > > From: Robb Bossley [mailto:robb.bossley@xxxxxxxxx] > Sent: Thursday, March 08, 2007 9:13 AM > To: Alec Matusis > Subject: Re: routing TCP to another box preserving ORIGINAL client > IPs > > Have you considered putting a bridge in and using ebtables? That might be > what you are looking for. > > > On 3/7/07, Alec Matusis < alecm at chatango.com> wrote: > Hello Martin, > > I tried implementing DNAT as you indicated: > > iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 > > After that, I can see SYN packets arriving on BOX_B_ETH1, having the > original client's IP. Only half of the connection gets established after > this: > I cannot see ACK packets from box B anywhere (neither on BOX_B_ETH0, nor > on > BOX_A_ETH0). I think the reason is that since box A never sends a SYN > packet > itself, it never classifies the connection as ESTABLISHED, so all further > traffic gets rejected. It's still a mystery to me what happens to SYN > packets from be in this scenario however. > > It turns out that I have to supplement DNAT with SNAT for this to work > correctly. > On box A: > iptables -t nat -i eth0 -p tcp -m tcp --dport $SERVER_PORT -j DNAT > --to-destination $BOX_B_ETH1 > iptables -t nat -A POSTROUTING -d $BOX_B_ETH1 -p tcp -m tcp --dport > $SERVER_PORT -j SNAT --to-source $BOX_A_ETH1 > > in this case, the clients can connect, however the server on B sees only > IP > of BOX_A_ETH1, not the original client IPs. > > Regarding tproxy: > I am currently running the TCP server on box A. I would like to move it to > box B to reduce the load on A. Other services on A are bound to the same > IP > address as the server that I need to move, so simply moving that IP > address > to BOX_B_ETH0 is impossible. > Box A has 2.6.11 kernel. Does tproxy install over netfilter? I am sort of > scared to tamper with netfilter installation on A, since it is currently > running live services. > > It it possible to implement this scenario: > * the client thinks it's connected to Box A > * Box A knows its connected to the client > * Box A uses client's source address to initiate traffic to Box B > * Box B thinks it's connected to client > with advanced routing and iptables only? > > Thanks > > Alec. > > > > -----Original Message----- > From: Martin A. Brown [mailto:martin@xxxxxxxxxxxx] > Sent: Wednesday, March 07, 2007 8:24 PM > To: Alec Matusis > Cc: lartc@xxxxxxxxxxxxxxx > Subject: Re: routing TCP to another box preserving ORIGINAL client > IPs > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greetings Alec, > > : My TCP clients connect to box A. I need to forward those > : connections to a server on box B, such that the original client > : IPs are visible to the server on B. > : > : Each box has two Ethernet ports. One port on each box is > : connected to WAN, and they are cross-connected in a LAN via > : remaining ports: > : > : ------------------- ------------------- > : WAN -- |eth0 Box A eth1|---LAN---|eth1 Box B eth0| -- WAN > : ------------------- ------------------- > : > : > : Is there a way to do this with iproute2 and iptables tools ONLY? > : Can you provide an example? Nothing in Google after more than a > : week of searching. An additional requirement is to reduce the > : load on box A as much as possible (I guess the server on B would > : still have to reply to the client via A, not using B's own WAN > : interface however..) > > You need to provide us a bit more information to help you figure out > the right way to solve this problem. Why is DNAT not sufficient? > Given your description, you should simply be able to: > > iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 > > If it were that simple, though, you shouldn't have spent a week > looking for the answer. > > Do you have a TCP service on Box A which is providing services to > the client across the WAN? If so, then you are looking for > something called transparent proxying in the Linux networking world. > You will want to examine the tproxy patches to iptables [0]. > > If you go with the transparent proxying method, it's helpful to > remember: > > * the client thinks it's connected to Box A > * Box A knows its connected to the client > * Box A uses client's source address to initiate traffic to Box B > * Box B thinks it's connected to client > > In either case, you are correct about routing. Box B must send its > traffic back to Box A to forward back across the LAN. > > Good luck, > > - -Martin > > [0] http://www.balabit.com/products/oss/tproxy/ > http://www.balabit.com/downloads/tproxy/linux-2.4/ > > - -- > Martin A. Brown > http://linux-ip.net/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: pgf-0.72 ( http://linux-ip.net/sw/pine-gpg-filter/) > > iD8DBQFF74/JHEoZD1iZ+YcRAlRaAJ4wf2fIc3oBJnGstjUBdpKWn1wOsQCbB2Ee > 5Q7zrssGkA02Pq+298i9tEA= > =O3sf > -----END PGP SIGNATURE----- > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
