VK:
Okay, I think I've got enough of a summary here now to
suggest to you some specific Zebedee command lines. As background,
the setup is as follows:
PC1 PC2 PC3 PC4
------------- FW1 <=> Internet <=> FW2 --------------
LAN1 LAN2
In this model, PC1, PC2 and PC3 are all running Kaboodle
and have Zebedee client/server capability. LAN1 and LAN2 are behind
firewalls. PC4 is running a VNC server but not Kaboodle nor Zebedee.
PC2 and PC3 are connected using Kaboodle's VPN, which I will call
the "control channel". The control channel uses TCP port 4182 only.
Once the control channel is established, PC2 and PC3 exchange
their NID with each other. Because of this exchange, two things
happen: first, the GUI in both LAN1 and LAN2 display the VPN connection
state. Second, the Kaboodle services (ie, VNC and File Transfer today,
other things tomorrow) must recognize the remote machines as valid
"targets". For example, if PC4 is a VNC server on LAN2, then Kaboodle
on PC3 can administer a VNC session from PC3 to PC4. We need to extend
this "target awareness" so that the Kaboodle instances on LAN1 also
recognize PC4 as a valid target for a VNC connection.
Presuming we get all of that right...the VNC data flow would
look like this:
0. As soon as the user on PC1 clicks "Connect" in the VNC Window,
a Zebedee server needs to be started on PC3. Arguably, this server
should be started as soon as a VPN is started: why else initiate
a VPN unless you want to do something with it, right? Anyhow...
PC2 uses the Kaboodle control channel to tell PC3 to activate a
Zebedee server that's ready to do whatever it, as the Zebedee client,
tells it to do. The easiest thing to do on PC3 is just this:
PC3> zebedee -s
The only problem with this is that this Zebedee server will do
anything *any* client tells it to do, even one initiated from
some malicious user somewhere. What we need to do, then, is to
restrict the IP addresses that PC3's Zebedee server will accept
connections from:
PC3> zebedee -s -x "checkaddress a.b.c.d"
In this case, a.b.c.d is the "real world" IP address of PC2, or
in other words, the IP address that valid data from PC2 will be
coming from. Of course, IP addresses can be "spoofed", but this
is much better than nothing. What would be even better would be
if Zebedee on PC3 generated a "shared secret" key on the fly, and
sent that key to PC2 using the existing (encrypted) Kaboodle
channel. So:
PC3> zebedee -x "sharedkeygencommand"
This should create a sharedkey value that is written to stdout. It
should be a 32-digit hexadecimal for a 128-bit encrypted channel,
but going forward I'll just call it "012345678". We could then send
this value to PC2 over the control channel, and then start the zebedee
server:
PC3> zebedee -s -x "checkaddress a.b.c.d" -x "sharedkey 012345678"
Now the server is started on PC3, but it will only accept connections
from a.b.c.d, and then only if that connection includes "012345678"
as the shared key value. Going even further, we could use the -p and
-P switches to require the use of public/private key pairs, rather
than a shared key. This way, even if the Kaboodle control-channel
was broken, and a malicious use intercepted the key value being
transmitted, they still wouldn't have enough information to spoof
the IP address and connect to the Zebedee server. But lets just get
shared key working first.
Lastly, please notice that we could/should have used the -T switch
the whole time:
PC3> zebedee -s -T 11965 ...
The -T switch tells the Zebedee server to listen to the TCP port
11965. This happens to be the default for Zebedee, so it's not
needed as written. However, it's very important to note that no
Zebedee connections will work if the firewall protecting PC3 doesn't
allow this TCP port into the network. Also, if we ever want to change
what ports Kaboodle uses for the VPN connection (ie, if we had a
user-setable value field somewhere), we'd need to specify this
explicitly. So I think we should include it explicitly now so
that it's easy to change later (in some "user this TCP port for
data from your Engaged Partners" field).
That's it for the server side. The Zebedee server on PC3 will
now do whatever the Zebedee client on PC2 tells it to do. Since
we've secured things regarding who PC2 is, this should be fine.
1. Now on PC2, we need to start the Zebedee client which connects
with this Zebedee server on PC3. Keep in mind we have to use both
the -T switch (since Zebedee on PC3 might be listening to whatever
the user chose, the value we know about since it was in the NID
we got over the control channel) and the sharedkey value. This
client will be tunneling VNC data to port 5904 on PC4, so we need
to "open" a tunnel entrance for this data on the loopback interface
of PC2. We can use whatever port number we want on the loopback, so
lets use "55555". All said, it would look something like this:
PC2> zebedee -b 127.0.0.1 -T 11965 -x "sharedkey 012345678"
ip.addr.of.PC3 55555:ip.addr.of.PC4:5904
Taking this apart, we've used Zebedee to open a tunnel from port
55555 on our loopback interface of PC2, and any data send there
will emerge from PC3 headed for port 5904 on PC4. Note that this
is, really, where all the "smarts" are -- setting up the server
was a breeze.
2. Now all we need to do is to get the VNC viewer on PC1 to connect
with TCP port 55555 on the loopback interface of PC2. For this, we
use Kaboodle's *existing TCP tunneling capabilities* -- we just
specify to that tunnel, when we set it up on PC2, the destination
that we want: 127.0.0.1:55555 on PC2. Please note that Zebedee
does *not* have to be started on PC1 -- that would be a bit
redundant as Kaboodle already does this. We could start another
Zebedee server on PC2 and a client on PC1, and make a quick
handoff, but it should be easier to stick with what we have
working already. If you disagree, the Zebedee commands would be:
PC1> zebedee 66666:PC2:55555
PC2> zebedee -s localhost:55555
In the above, we would now just need to point our VNC viewer to
port 66666 on PC1, and the data would find its way to PC4.
I've spoken to Neil Winton (the Zebedee developer) and he's
interested in the idea of Zebedee being updated to be a "passthru"
server, optimized for such things, but that mode doesn't work yet.
Me, I think using Kaboodle for "LAN tunneling" and Zebedee for
"LAN to LAN" tunneling is easier.
3. If, instead, we were starting the VNC viewer session on PC2 and
not PC1, it would be even easier: we'd never even have to use
Kaboodle's tunnel. We could instead connect the VNC viewer on
PC2 directly to it's own loopback interface, TCP port 55555.
4. If, instead, we were using Zebedee to tunnel a Kaboodle
file-transfer from PC1 to PC3, most of the above remains the
same. The Zebedee server startup on PC3 stays the same, but
we'd have to adjust where the tunnel end on PC3 was pointing:
PC2> zebedee -b 127.0.0.1 -T 11965 -x "sharedkey 012345678"
ip.addr.of.PC3 77777:127.0.0.1:7000
Now if Kaboodle on PC3 was listening to TCP port 7000 for
file-transfers, it would hear anything that was written into
TCP port 77777 on PC2. We direct the "client" part of the
Kaboodle file transfer applet to connect there.
In summary, please notice one key element: all of the data
transactions between PC2 and PC3 arrive at PC3's TCP port 11965,
where the Zebedee server is listening. Even if PC2 opens multiple,
simultaneous connections to PC3, it all gets stuffed into the same
"tunnel". That's the whole point of Kaboodle's VPN capability.
Please let me know if this makes any more sense now. Thanks!
-Scott
-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
