Hello Scott,
Please find my replies in Blue.
----- Original Message -----
From: "Scott C. Best" <[EMAIL PROTECTED]>
To: "mailbox" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 09, 2002 1:27
PM
Subject: Re: Kaboodle + zebedee
Status
> VK:
> Hello! Two quick questions:
>
> 1. What TCP port(s) does Kaboodle/Zebedee use now?
>
> Hello! Two quick questions:
>
> 1. What TCP port(s) does Kaboodle/Zebedee use now?
>
I am using port 2001 as Zebedee
client listening port and 5991 for VNC viewer.
> 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.
>
The VPN code has the array of sockets which contents the information regarding the networkIDs and Remote IP address for the established VPN connections.
The algorithm is as follows.
I first try to find the VPN connection information in the Kaboodle instance from which the VNC connection is initiated. If the connection request is for the machine on different LAN then it tries to find the VPNed machine using the VPN socket array information. If the instance requesting the VNC connection is not VPNed it sends the message to other kaboodles on LAN to find the VPNed machine with the networkID information. The Kaboodle instance having the match with the requested networkID sends a message back to the kaboodle instance requesting the VNC connection with its IP address.
> 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. :)
>
This can be done but what if none of the machine on the LAN is VPNed?
I have a one more suggestion for the same. In case of the LAN without the kaboodle VPNed instance we can just restrict one kaboodle instance to do passive network device detection.
> 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
> > >
> >
> >
>
>
