VK:
Hello! Two quick questions:
1. What TCP port(s) does Kaboodle/Zebedee use now?
2. If I have N machines on my LAN running Kaboodle, only one of
them can be the "VPN Master". How does your code determine
which is the VPN Master? I recall seeing that it's a checkbox
in the PropPanel for a Kaboodle device.
3. I think Igor can help with this: only the VPN Master should
ping the LAN every 5 seconds. Every non-Master device should
just listen unless the user hits "Refresh". Otherwise, with
20 Kaboodle instances on a LAN...there's lots of pinging
going on. :)
Thanks!
-Scott
On Sun, 8 Sep 2002, mailbox wrote:
> Hello Scott,
>
> I have added the code for Zebedee (points 3 and 4 of the specifications for
> zebedee integration) in the Wincvs. At present the zebedee path and tightvnc
> paths are hardcode in the code. I will change once you finish your
> preliminary testing.
>
> Please install the tightvnc in C:\program files\tightVNC and zebedee in
> c:\program files\zebedee. Please enable the "Allow loopback connections" for
> tightvnc servers in order to make VNC servers visible in some of cases
> listed below.
>
>
>
> The zebedee works for pc1-- >pc4 , pc1-- >pc3, pc2-- >pc3, pc2-- >pc4,
> pc3-- >pc2, pc3-- >pc1
>
>
>
> Regrads,
>
> Varsha
>
> ----- Original Message -----
>
> From: "Scott C. Best" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, July 04, 2002 11:47 PM
> Subject: [Kaboodle-devel] Kaboodle VPN design review
>
>
> >
> > 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
> >
>
>
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
