<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Cipe and advanced routing
From: Petr Konecny <pekon,AT,informatics,DOT,muni,DOT,cz>
Date: Mon, 19 Feb 2001 07:14:44 +0100
In-reply-to: <qww3ddfllln.fsf@decibel.fi.muni.cz>

>>>>> Zygo Blaxell (Zygo) said:

 >> I would like most traffic between the laptop and network A to go through
 >> CIPE tunnel. I have access to a computer G on network N, that can be
 >> used as a proxy/gateway/router.

 Zygo> OK, so the laptop has an address A on N, but is not physically 
connected
 Zygo> directly to N?  This is important.  ;-)
That's right. The address of the cipe tunnel on laptop's side is set to
laptop's address in network N. Gateway G works as an proxy arp to fool
other N's computers into thinking that the laptop is actually connected
to it. I suppose I could change addresses of both end points to private
address space, however I am not convinced that this would help.

I know that it is possible to do what I want with SNAT in iptables,
however its use requires connection tracking which slows down local
traffic on G's side quite a bit.

 Zygo> I don't know why you want to keep ssh out of CIPE, though...I prefer to
 Zygo> run my ssh connections over my CIPE tunnels wherever both are 
available.
 Zygo> Why allow any extra opportunity for traffic analysis?  Also, you can
 Zygo> always get an ssh connection outside of CIPE by ssh-ing directly to the
 Zygo> CIPE peer IP address instead of its host name, in case you need to 
debug
 Zygo> the CIPE connection or something.
I am not concerned about traffic analysis, I am more worried about
computational resources of G. Double encryption wastes cycles. Moreover
if the tunnel dies/doesn't work I lose all my ssh connections to other
computers in network N.

 Zygo> By the time the OUTPUT chain sees these packets, the routing
 Zygo> decision is already made, and it's too late to change it.  You
 Zygo> need to use iptable and find an earlier step in the routing
 Zygo> process to mark the packets, then use multiple routing tables.
 Zygo> AFAIK this requires the very newest kernel 2.4.x IP routing
 Zygo> tools; I once had to do a similar thing with kernel 2.2.x and
 Zygo> found that it was impossible without kernel patches.
I do use the latest kernel (2.4.1-ac18 right now). In iptables OUTPUT
chain actually precedes routing, see
http://netfilter.kernelnotes.org/unreliable-guides/netfilter-hacking-HOWTO/netfilter-hacking-HOWTO.linuxdoc-3.html

 >> Is there any way to get this to work ?=20

 Zygo> Yeah, stop trying to do it at the IP routing level and do it at
 Zygo> the application level instead.  ;-)

Using suggestions from Myles Uyema (thanks :-) I was almost able to get
it to work.  It sends all packets through the correct interface. However
there is one remaining _big_ problem. When I attach tcpdump to the
tunnel it shows that the source address of packets going through is the
address of laptop's eth interface. I think I understand why is it
happening, but see no way to fix it, other then a bit of kernel hackery.
In fact the page above has some hints.

 Zygo> DNS hacking (i.e. using an /etc/hosts with a "private" view of
 Zygo> the IP namespace) works very well for me.  I actually extend this
 Zygo> to use subdomains, where a mobile machine searches
 Zygo> "machine-name.example.com" prior to "example.com" in the DNS, to
 Zygo> get the tunneled IP addresses instead of the untunneled ones when
 Zygo> using short machine names.
Hmm, this could help. I suppose I could make a static NAT map
10.0.0.x <-> A.B.C.x (where A.B.C.0/24 is my network N) on G, and make
 entries in /etc/hosts or local DNS server for these addresses. Then I
could route everything to 10.0.0.0/24 through CIPE.  Thanks for the
suggestion. Of course I would still like to do it on IP level, because
there would be just one place with all configuration.

                                        Regards, Petr

-- 
A banker is a fellow who lends you his umbrella when the sun is shining
and wants it back the minute it begins to rain.
                -- Mark Twain





<< | Thread Index | >> ]    [ << | Date Index | >> ]