[Spread-users] Tunnels

[Mark Anacker]

Oh sure, that's easy - a couple of lines of perl code would make an
effective tunnel.  And it's easy to forward it over SSH - I do that now. 
The only problem is that at the remote end, the messages coming in from the
tunnel appear to originate with the tunnel-client, not the actual sender
from it's local segment.  This may or may not be a problem - you can always
carry the sender ID in the data payload, but that violates the spirit of a
transparent distributed network layer.

It's much the same situation as you can get with some application protocols
and NAT (or masquerade).  The classic example is the CuSeeMe
videoconferencing system.  Their client read it's hosts's IP address and
sent that in the data stream.  This was fine if everybody had a public IP
address, but what happens if your client is on a 192.168.x.x private net
behind a NAT?  They didn't provide any way to substitute the external, real
IP address of the gateway.  On Linux, there is a special firewall module
that actually reaches inside the payload and substitutes the outside
address.  Not only is this an ugly hack, but it's fragile.

So yes, it's quite easy to make a client tunnel, but it's not the *correct*
way.

On Thu, 10 Jan 2002 21:44:57 -0500
Yair Amir <yairamir at cnds.jhu.edu> wrote:

> Ok,
> 
> So that is doable: spread clients can connect to multiple
> spread networks (because they can make multiple connections and in each
> of them they specify the daemon address to connect with).
> 
> The only issue is encryption of the client-daemon connection (to the home
> network from the office). What about a quick and dirty ssh forwarding?
> 
> 	:) Yair.
-- 
Mark Anacker
Senior Software Architect
Copyright 2002, LizardTech, Inc. All rights reserved.  Unauthorized
disclosure prohibited.