VK:
Heya. Some replies to your replies:
> > 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.
Sorry, let me ask this differently. If Kaboodle is running
on PC2 and PC3:
PC1 PC2 PC3 PC4
------------- FW1 <=> Internet <=> FW2 --------------
LAN1 LAN2
What TCP ports do I need to open and forward on FW1 and
FW2? Ideally...there's only *one* port needed. True?
> > 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.
Good idea.
> > 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?
As above...in order for Kaboodle to VPN, I'll need to open
a TCP port in my firewall. If the firewall does NAT/PAT, I'll also
have to forward that port to one of the Kaboodle machines. So...one
of the PC's on the LAN is *always* the "master", in a way.
If when Kaboodle starts up and there is no Master on the LAN,
that Kaboodle instance should declare itself the Master.
> 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.
Nah, the other way is better: passive listening doesn't
generate any traffic. And, listening is hit-or-miss anyhow: success
depends on how good the NIC is and how busy the CPU is. So the more
listeners you have, the better chance you'll have at hearing a new
device enter the LAN. Only one device, though, should be the pinger,
and that should be the VPN Master.
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
