Hi Ramin, --- Ramin Dousti <ramin@xxxxxxxxxxxxxxxxxxxx> wrote: > I don't see any solution to your problem. First of > all you cannot > switch between 1 and 2 in the middle of a stateful > session like TCP. ok - i understand, but just redirecting udp would be 90% of our goal. Let's put tcp out of the picture. > Secondly when 2 is down, that IP is unreachable, so > the option that > you would always send packets to 2 (even through A) > is out of question. no - S would always send packets to IP (1), the NAT in R would translate (1) to (2). R will know when (2) is on-line. > > As I said before you need to have a nailed-up IP on > M which can be We *cannot* have a dummy IP. The IPs come from A & B networks (DHCP) where we have only limited influence. > reachable through both A and B. When R knows that IP > is reachable through > B (ie when 2 is up) it sends the packets out through > B, otherwise it > keeps sending the packets through A. This is ok if we can have changes made in A&B, but we may not have this privilege! If I want *existing* UDP connections to be diverted, I need to change both the NAT table *and* the connection tracking table, is this right? Can somebody tell me if this can be done with iptables? Do I have to hack the code? I may do so if need be. Is there another NAT sollution out there that can do what I need? Is using a NAT to divert existing UDP streams technically possible? Thanx for your help. Steve > > Ramin > > On Wed, Jul 16, 2003 at 01:25:38PM +0800, Stephen > Bylo wrote: > > > --- Ramin Dousti <ramin@xxxxxxxxxxxxxxxxxxxx> > wrote: > > > > > > > Hi Ramin, > > (sorry, an amended version) > > > > _______A_(slow)____(1) > > S ----------------R___________________ M > > B (faster) (2) > > > > + Yes, R is Linux > > + (1) and (2) will get their IPs through > > DHCP whenever they connect. > > + We have full influence on S, R and M but only > > *partial* influence on A & B networks. > > + M can inform R which IP to use (1 or 2). > > + S can only know 1's IP. > > + A UDP stream can exist through S->R->A->(1) and > > should be diverted by R (through A to 2) when > (2) > > comes on-line. > > + The UDP stream can be diverted back agin to (1) > > when (2) goes off-line again. > > > > Does this help? > > > > Thanx > > Steve > > > > > > Hi Stephen, > > > > > > You lost me here. M is a remote host with two > > > interfaces. There are > > > two networks (AS) between your router R and M. I > > > take that R is a > > > linux box (??). Interface 1 is always up and > > > interface 2 is sometimes > > > up. Now you want to send the packets (mostly > UDP) > > > from your server S to M > > > and you want the router R to do some kind of > magic > > > and know when 2 is up > > > and nat to 2 and use 1 otherwise. While this > might > > > work for UDP (if I only > > > knew how) there is no way you can switch between > dst > > > IP's of a TCP session. > > > > > > What you could do is: > > > 1) Have a loopback(dummy) interface D on M > > > 2) Use some kind of routing protocol on M to > > > propagate this D through > > > 1 and 2 to the networks.. > > > 3) Receive this route from those networks on R > > > > > > Then you could assign a higher cost to the > network > > > connected to 1. When 2 is > > > up your preference would be through the lower > > > network. When 2 is down, the > > > only path would be through 1. At any rate the > server > > > S should only talk to > > > D. This solution works for both UDP and TCP... > > > > > > But I'm certain that M (being mobile) cannot > send > > > out any routing information. > > > And besides your ISP's are not willing to > receive > > > the route from M and also > > > are not willing to pass that route to R. > > > > > > So, no, sorry I don't have any solution for you. > > > > > > Ramin > > > > > > > > > On Wed, Jul 16, 2003 at 10:12:58AM +0800, > Stephen > > > Bylo wrote: > > > > > > > Dear Ramin & List, > > > > > > > > Thanx for your mail. The world is getting > more > > > > mobile, so here is some detail to my problem: > > > > > > > > A mobile host M has two interfaces 1 & 2. > > > > M is reading an open udp stream from host S > > > (server) > > > > on interface 1. Interface 1 is always > on-line. > > > > Interface 2 is only sometimes online and the > route > > > to > > > > 2 provides much more bandwidth than the route > to > > > 1. I > > > > want to route the stream through the higher > > > bandwidth > > > > without S having to know about it. S should > > > always > > > > think its communicating with the IP on > interface > > > 1. > > > > > > > > ____some network___(1) > slow > > > > S -------- NAT ---R___________________ M > > > > some network (2) > fast > > > > > > > > R = our router to two different external > networks > > > > > > > > Tcp connections should also be "kept alive" > and > > > > diverted to interface 2 on M. > > > > > > > > After reading > > > > "netfilter-hacking-HOWTO.linuxdoc-4.html" and > > > > "iptables-tutorial.html" I find that existing > > > > connections will not be "diverted" in this > way, > > > only > > > > new connections are looked up in the NAT > table. > > > > Would it be possible to change the dst values > in > > > the > > > > "conntrack" table as well as changing the NAT > > > entry > > > > when interface (2) comes on-line ? > > > > > > > > Any other ideas ? > > > > > > > > Thanx for any help, > > > > Steve > > > > > > > > --- Ramin Dousti <ramin@xxxxxxxxxxxxxxxxxxxx> > > > wrote: > > > > > On Tue, Jul 15, 2003 at 06:01:15PM +0800, > > > Stephen > > > > > Bylo wrote: > > > > > > > > > > > Dear list, > > > > > > > > > > > > I am looking into the use of a NAT > "router" to > > > > > change > > > > > > the destination (or source) IP addresses > of > > > > > packets in > > > > > > existing connections. Maybe it sounds > weird > > > why I > > > > > > might want to do this, but I need to > divert > > > > > streams to > > > > > > other destinations! > > > > > > > > > > > > I understand from the iptables docs that > only > > > the > > > > > > first packet of a connection is examined > for > > > NAT > > > > > > entries, subsequent packets do not need to > be > > > > > > processed again. > > > > > > > > > > They do get processed. There is a short > circuit > > > to > === message truncated === __________________________________________________ Do You Yahoo!? Send free SMS from your PC! http://sg.sms.yahoo.com
