First-pass specification of TCP-application tunneling
capabilities of Kaboodle, using VNC as an example application.
Comments/corrections/feedback welcome!
OVERVIEW
========
In addition to being able to encrypt VNC traffic, Kaboodle must
be able to act as a gateway for VNC connections. The network topology can
be represented as follows:
LAN-1: PC1 (Kaboodle + VNC Client) <=> PC2 (Kaboodle VPN endpoint)
LAN-2: PC3 (Kaboodle VPN endpoint) <=> PC4 (No Kaboodle)
In the above, presume that PC2 and PC3 are endpoints in a VPN
connection using Kaboodle's existing VPN capabilities. Also presume that
a VNC server is installed on every machine. Lastly, presume that a VNC
client is installed only on PC1.
USER INTERFACE
==============
In all cases, the user experience is the same. Via the Kaboodle
GUI, the user opens the Property Panel of the target device, selects
the VNC Property Tab in that PropPanel, and clicks the Connect button.
At no time is the user ever prompted for an IP address.
PC1 to PC1
==========
A user on PC1 can, via the Kaboodle GUI, initiate a VNC connection
to either PC2, PC3 or PC4. But the GUI should prevent users from
initiating a VNC connection back to their own machine; ie, PC1 to PC1
should not be allowed via the Kaboodle GUI. Ideally, the Connect button
in the VNC PropertyTab should be simply "greyed out" in this same
machine case.
PC1 to PC2 (same LAN)
=====================
If the user on PC1 is connecting to the VNC server on PC2,
which is on the same LAN as PC1, the connection process is as follows.
If the VNC server on PC2 is running under Kaboodle control (ie, it
is not started until Kaboodle tells it), then when the Kaboodle user
activates a connection in the VNC PropPanel, Kaboodle on PC1 signals
Kaboodle on PC2 with a VNC connection initiation request, so that
Kaboodle on PC2 can initiate PC2's VNC server. Once started, Kaboodle
on PC2 reports to Kaboodle on PC1 what port the VNC server is listening
to on PC2.
If the VNC server on PC2 is not running under Kaboodle control,
of if PC2 is not running Kaboodle at all, then Kaboodle on PC1 will
initiate a VNC connection to the VNC server port number that's already
indicated in the Kaboodle GUI. Please note that other portions of
the Kaboodle code already auto-detect this VNC port number. It is
also a user-configurable port-number, via the existing work being
done to the VNC PropertyTab part of the GUI.
In either case, once PC2 is ready, Kaboodle on PC1 then
initiates the VNC client directing it to a.b.c.d:xyz, where "a.b.c.d"
is the IP address of PC2 on LAN-1, and "xyz" is the port number
obtained by one of the two methods described above. After the VNC
client connects to the server, the remainder of the VNC session TCP
data flow is independent of Kaboodle.
An enhancement for the future is to secure the intra-LAN
traffic by encrypting it with the shared Kaboodle key. In this case,
Kaboodle on PC1 binds a port on its local interface, and then
initiates PC1's VNC client to connect to this port. Data received at
that port is received by Kaboodle on PC1, encrypted with the shared
Kaboodle key, and then directed to Kaboodle on PC2. Kaboodle on PC2
decrypts this data, and then directs it to PC2's loopback interface
and so into the VNC server on PC2. Again, this same-LAN enhancement
is for the future.
PC1 to PC3 (different LANs)
===========================
If the user on PC1 is connecting to a VNC server on PC3, which
is on the remote LAN, the connection process is as follows. When the
Kaboodle user on PC1 activates a connection in the VNC PropPanel,
Kaboodle on PC1 signals Kaboodle on PC2 about an VNC connection
initiation request intended for PC3. Since Kaboodle on PC2 is the VPN
endpoint for LAN-1, it is its job to broker these requests on behalf
of PC-1. Thusly, using the existing VPN control channel between PC2 and
PC3, Kaboodle on PC2 signals Kaboodle on PC3 of this VNC connection
initiation. Kaboodle on PC2 and PC3 then establish a connection using
their existing VNC tunneling capabilities (in the future's "steel tube"
implementation, this step is unnecessary, as all tunnel data and VPN
control data will be multiplexed within a single TCP connection between
the VPN endpoints).
Additionally, PC2 binds a TCP port, and then uses Kaboodle-to-
Kaboodle signaling to tell Kaboodle on PC1 what this TCP port number
is. Lastly, Kaboodle on PC1 initiates the VNC client on PC1, directing
it to a.b.c.d:xyz, where "a.b.c.d" is the IP address of PC2 on LAN-1 and
"xyz" is this port number. Kaboodle on PC2 treats all data arriving at
this port number from PC1 as VNC data intended for PC3. Kaboodle on PC2
collects this data, encrypts it using the VNC tunnel key, and the
directs it into the tunnel to PC3.
Kaboodle on PC3 extracts the data from the tunnel, decrypts it,
and directs the TCP data to the VNC sever on its loopback interface.
Kaboodle on PC3 handles the initiation of PC3's VNC server in the same
manner as described in the PC1-to-PC2 case above.
PC1 to PC4 (different LANs)
===========================
This is the most difficult scenario.
If the user on PC1 is connecting to a VNC server on PC4, which
is on the remote LAN but is *not* running Kaboodle, the connection
process is as follows. When the Kaboodle user on PC1 activates a
connection in the VNC PropPanel, all details about the interaction
between PC1, PC2 and PC3 are the same as in the above PC1-to-PC3 case.
However, when the TCP data arrives out of the VNC tunnel into
Kaboodle on PC3, it is that Kaboodle's task to transmit that data to
VNC server port on PC4. Importantly, PC3 must establish its own TCP
connection with PC4, as all TCP replies from PC4 must be received
by Kaboodle on PC3 and then put back into the tunnel back to PC2,
and so back to PC1.
Note that the VNC tunnel between PC2 and PC3 MUST be capable
of carrying multiple VNC sessions simultaneously. For example, a user
on PC1 MUST be able to create one VNC connection to PC3 and then,
simultaneously, create a VNC connection to PC4. It is required that
these two (or more) independent VNC sessions share a single VNC tunnel
TCP connection. This "multiplexing" will require some mechanism by
which data in the tunnel is accompanied with some addressing as well
as some content typing, so that the receiving device knows what is
to be done with the data. These addressing and content-typing
mechanisms must be built to accommodate at least 16 content-types (one
of which is VNC, another HTTP, another Kaboodle VPN Control, and the
remainder undefined) and at least 4 delivery priorities (which will
be used by some future enhancement).
<END>
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
