Forwarding

X11 forwarding without VPNs

If we don't need a fully fledged VPN, but just want to transmit some well known application data instead of an entire network, there is a nice, small solution, too. Remember that you can forward X11-connection with ssh? The same can be done with glogin, too, and it doesn't require pppd, nor does it require IP-addresses and root-priviledges. The solution is to create an X11 listener socket in the grid-node side of glogin. Glogin will set the DISPLAY-variable of the login-shell accordingly, so that X11-applications will connect the glogin-service. Therefore, the glogin-service can forward the X11-application data over the GSS-connection to the glogin-client, which will send these data to the local running X-Server on the workstation the user is sitting in front of. Since multiple X11-applications can contact the glogin-service, multiplexing of X11-connections becomes neccessary. This means that we have to add something we call a "channel-number" to the data we are transmitting, in order to be able to assign the proper data from the remote X11/glogin connection the the local X11/glogin connection. A byte or two should be enough, allowing for approxy. 256 or 65536 distinct X11-connections. However, we also have to reserve channel-numbers for the login-shell, too: 2 or 3 (stdin, stdout and possibly stderr) are required.

Local and Remote Port forwarding

Port-forwarding in gsh/glogin is another method of transporting data over a GSS connection. It differs from our previous solution in that we forward traffic for TCP/IP-connections instead of unix-pipes. If programs communicate by means of TCP/IP, then port-forwarding from a grid-node would be an easy ``plug-in''-like solution.

As with X11-forwarding, we create TCP-listeners, create new connections and transport their data to the other end of the tunnel, using multiplexing to guarantee uniqueness. But as usual, things tend to become more complicated if we take a closer look.

A forwarder consist of three pieces of information: a port to listen to, a destination host and a destination port. There are two type of forwarders: ``local'' and ``remote'' forwarders. They differ in at which side of the tunnel the listener is created. Local forwarders are created on the system where the users starts the local instance of glogin, remote forwarders are created on the target grid-node. It is possible to use both types of forwarders at once, there is no reason not to do so. To make things worse, it is possible to specify multiple forwarders, resulting in the need to maintain multiple local and multiple remote forwarders. Therefore, at each instance of glogin, we maintain a forwarder-description-table.

At first, we look at remote connection forwarding. A newly created connection is always associated with its creating forwarder. The other side of the tunnel also needs to know which forwarder created the connection, since that information is required to determine the correct destination-address. Since the other side cannot know this association, we have to pass that information first before sending any data. For this, we extend our ``terminal control'' protocol. We define a new type of message, which holds two items of information: the number of the forwarder, which is used as index into the forwarder-description-table, and the socket-descriptor, which is also our channel-number. Using that information, the local node issues a connect(2) to the target address, resulting in a local socket-descriptor. The tuple (localfd, remotefd) exactly determines a forwarded connection at the local machine. At the grid-node, in contrast, the operating system guarantees unique descriptors within a program and we therefore just use these descriptors for connection multiplexing. We don't need descriptor-tuples here.

With local port-forwarding, the situation is a bit different. Again, we can have multiple local port-forwarders. The difference here is that socket-descriptors are created before we have a channel-number for transmission. Our implementation is based on unique channel-numbers, so if the local node creates them itself, traffic-forwarding will not work. As we have said above, the remote node assigns channel numbers - so why not just ask the remote node to assign a free, unusued channel number for us? We do so by again extending our ``terminal control''-protocol by sending a ``CR-Request'' -- a ``channel resolution request''\footnote{the author is amused by the similarity to ARP, the ``adress resolution protocol''}. On the remote node, we have seen that we use the OS to obtain unique descriptors/channel-numbers. We do so again by first connecting to the remote forwarded destination, then sending back the descriptor in a ``CR-Reply'' -- a ``channel resolution reply''. At the local node, we now can form the tuple (localfd, remotefd) and proceed forwarding data as usual.