Heyaz. This email is meant for all of the people on
the development list. It's an overview of how I see the "VPN"
capability of Kaboodle working, and I need to know if any
of you see a problem.
After sleeping on the idea, I've come to the decision
that utilizing the ZeBeDee utility is the best idea for version
1.0. It may make sense to revisit this decision later on when
more resources are available. But given the requirements, the
budget, and our existing capabilities, it'd be crazy *not*
to use a utility as stable and well supported as ZeBeDee. Put
another way, it's ready now and better than what we could come
up with in any reasonable timeframe (sorry for any hurt feelings
here...no offense intended).
Unfortunately...I am not sure how to best implement
the capability I need using ZeBeDee. Let me describe my target
need first, and then offer some ideas. What I need is this:
PC1 PC2 PC3 PC4
------------- FW1 <=> Internet <=> FW2 --------------
LAN1 LAN2
In this model, PC1, PC2 and PC3 are all running Kaboodle.
LAN1 and LAN2 are behind firewalls, and only a small handful (I
think it's doable with 1, but it's easier with 2) of TCP ports are
opened to PC2 and PC3 (PC1 and PC4 are not externally accessible
at all -- two firewalls direct all incoming Kaboodle-related data
for LAN1 to PC2 and for LAN2 to PC3). Presume that PC2 and PC3 are
connected using the VPN capability that we're now talking about (so
both ZeBeDee client and server binaries are available to all of the
Kaboodle instances). PC4 is not running Kaboodle, nor ZeBeDee, but
it is running a VNC server. Given all that as background, I need the
following to work:
1. Two users on PC2 and PC3 can discover each other using the
existing capabilities of Kaboodle (which now work).
2. Once IP addresses are discovered, PC2 and PC3 connect with
each other in some manner. Let's call this piece the
"Control Channel". Right now, it with some legacy code
that we custom-developed. Going forward, we may find it
better to use ZeBeDee for this as well. We support one
authentication means today; we can add others as we see
fit (or as the users insist).
3. Once the control channel is established, PC2 and PC3 exchange
their NID with each other. Because of this exchange, two
things need to happen: first, the GUI in both LAN1 and LAN2
display the VPN connection state. This works. 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. The information needed to create
this awareness is definitely in the NID.
4. Once the NIDs are exchanged and the target awareness is made
available to all of the services, I should now be able to VNC
from PC1 to PC4 using a combination of Kaboodle tunnels and
the ZeBeDee connection (see below).
5. Importantly, if I am VNC'ing from PC1 to PC4 using this
capability, I should be able to start a Kaboodle file transfer
from PC2 to PC3 without interrupting the VNC connection.
This, I think, will be the trickiest part.
Ideally, this "VPN connection" is secure as possible, so
it is secured between PC1 and PC2 using Kaboodle and between PC2
and PC3 using ZeBeDee (I don't think we can go from PC2 to PC4
using all ZeBeDee...but if anyone sees a way please suggest).
The VNC data flow would look like this: A VNC client on PC1
connects to localhost port 100 where Kaboodle on PC1 is listening.
Kaboodle on PC1 sends this data to port 200 on PC2. On PC2, Kaboodle
is listening to port 200. Kaboodle on PC2 also instructs a ZeBeDee
client on PC2 to listen to port 201 on the loopback interface.
Kaboodle takes the data from port 200, decrypts it using the
existing VNC tunneling capabilities, and pushes that data into
port 201 on the loopback interface. The ZeBeDee client collects
this data from TCP port 201 on the loopback interface of PC2 and
sends it to the ZeBeeDee server on PC3 which is listening to port
300 (it knows to listen to port 300 because Kaboodle on PC3 told
it to). The ZeBeDee server forwards the data it receives on TCP port
300 on PC3 to TCP port 5902 on PC4. The ZeBeDee server knows to
forward the data like this, because the ZeBeDee client on PC2 told
it to do so when it connected (eg, the ZeBeDee client had a kickoff
which looks like "zebedee -b 127.0.0.1 PC3 201:PC4:5902"). The
ZeBeDee client pn PC2 knew to use port 5902 because Kaboodle on
PC3 had this information in its NID after running VNC server
discovery on LAN2. The VNC server receives the data, and the
return path is symmetric.
I think that covers it. Feedback welcome!
cheers,
Scott
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
