Naturally, the network at the site where ThinLinc is to be installed needs to be prepared for the installation. This section aims to help in understanding the requirements of the network for a successful ThinLinc installation.
We will explain the most common setups, including a typical Novell site and a typical Microsoft site. Also, we will explain how a site with NAT can use a NAT/Split-DNS setup to access ThinLinc in an efficient way both from the inside network as well as from the Internet.
In Figure 3.1, a very simple ThinLinc setup is shown. In this setup, clients are configured to connect to thinlinc.example.com, DNS is configured with information about what IP addresses correspond to the hostnames thinlinc.example.com, tlagent1.thinlinc.com and tlagent2.thinlinc.com and no firewalls are in the path between the clients and the servers.
The number of VSM agents will range from 1 (on the same host as the VSM server) to a larger number, based on the number of users that are using the system. In this example, there are one host running both VSM server (the software controlling the whole ThinLinc cluster) and VSM agent, and two dedicated VSM agent hosts running only sessions.
Clients will communicate with the servers via port 22. If clients and servers are configured to use unencrypted graphic sessions, clients will also connect to port 5900-6000 as well as on a number of ports below 32767. See Appendix A, TCP Ports Used by ThinLinc for full information about which ports are used at different occasions.
In Figure 3.2, ThinLinc is installed in a Novell environment, and integration with Novell eDirectory and/or Novell Netware fileservers are in use.
The ThinLinc servers will need to communicate with the eDirectory servers on either port 389, if using unencrypted LDAP, or on port 636, if using encrypted LDAP (ldaps).
The ThinLinc servers will also need to communicate with the Novell Netware file servers. In the case where NCP is used to access the files, the ThinLinc servers needs to communicate with the Netware servers on TCP or UDP port 524. In the case where NFS is used to access files, UDP port 111, TCP and UDP port 2049 and a range of dynamically allocated UDP ports are used to communicate with the file servers. If there is a firewall between the ThinLinc servers and the Netware file servers, it needs to have support for understanding portmap requests, opening NFS UDP ports on demand, or there can be no restrictions for the traffic between the ThinLinc servers and the Netware file servers.
In Figure 3.3, ThinLinc is installed in a Windows environment, and integration with Windows Domain Services and/or Windows Fileservers are in use.
The ThinLinc servers need to communicate with the Windows Domain Controller on TCP port 139.
The ThinLinc servers will need to communicate with the Windows file servers using TCP port 139 and/or TCP port 445.
At many sites, the internal network is behind a firewall doing Network Adress Translation (NAT). This means that the IP adresses on the internal network are allocated from so-called RFC1918 space, i.e., they are within the range 10.0.0.0-10.255.255.255, 172.16.0.0 - 172.31.255.255 or 192.168.0.0 - 192.168.255.255.
As long as ThinLinc servers are only meant to be accessed from the internal network, this is no problem, and the situation will be like the one described in Section 3.3.1, “ A Simple ThinLinc Setup ”. However, if the ThinLinc servers are meant to be accessed from the Internet as well, special arrangements need to be made.
Note
An alternative to using a split DNS configuration is to use a client side translation configured by the HOST_ALIASES parameter, but in most cases, a proper DNS setup is recommended. See Section 7.8, “ Client configuration storage ” for more information.
First, relays must be configured in the firewall. One IP address reachable from the outside network per ThinLinc server needs to be available, and each should be equipped with a relay forwarding traffic from TCP port 22 on the outside to TCP port 22 on one specific ThinLinc server. In our example, as shown in Figure 3.4, there is one relay listening to TCP port 22 on the externally reachable IP address x.12.253.1 forwarding traffic to the ThinLinc server on the internal network with IP address 10.0.0.12, one relay listening on TCP port 22 on the externally reachable IP address x.12.253.2 forwarding traffic to the ThinLinc server on the internal network with IP address 10.0.0.13, and so on.
After configuring the relays, DNS must be configured so DNS queries for the hostnames of the ThinLinc servers get different answers depending on the origin of the query. DNS queries originating from the internal network should be answered with the real IP adresses of the servers, and DNS queries originating from the outside network should be answered with the IP adresses on the firewall, where the relays are listening.
In our example, if a host on the internal network is asking for the IP adress of the hostname thinlinc.example.com it should get the IP address 10.0.0.12 as answer. If a outside host is asking for the IP adress of the same hostname it should instead get the IP address x.12.253.1 as answer.
When configured this way, a client connecting from the internal network will communicate directly with the ThinLinc servers, without the need to pass the firewall, while clients connecting from the outside will pass through the firewall and the relays to communicate with the ThinLinc servers. This will ensure optimal performance for clients from the internal network, at the same time lowering the load on the firewall.
Finally, after configuring relays and DNS, the VSM agents must be configured to respond with the correct hostname when asked by the VSM server what hostname the clients should connect to. The default behaviour is to respond with the IP adress of the host, but that will not work in this case since clients connecting from the external network won't have any route to for example 10.0.0.13. Instead, the VSM agents should be configured to respond with the hostnames that can be found in both the internal and the external DNS.
This is done by setting the parameter /vsmagent/agent_hostname on each of the VSM agents in the ThinLinc cluster. In our example, set /vsmagent/agent_hostname to tlagent1.example.com on the machine with IP adress 10.0.0.13.
If users are supposed to be able to connect using a web browser, using the ThinLinc Java Browser Client, they must be able to connect not only to port 22, but also to port 443 (https) on both the VSM server and on all VSM agents. This is because the Java Applet needs to be downloaded from the same host that it will later connect to, in order to get through the Java Security model.
If the native client is used from a browser, including the Native Client Verification Applet, access to port 443 (https) is only required for the VSM server machine. It must still be possible to reach all VSM agents on port 22, though.
If it should be possible to connect to the ThinLinc server using port 80 (ordinary, non-encrypted http), port 80 should also be allowed. However, port 80 access is only needed to the VSM server, not to the agents. HTTP Connections to port 80 will be redirected to a https connection, if using the standard ThinLinc setup. Having the http port open is probably a good idea from a ease of use perspective. Getting users to remember they must use https can be hard.
In the NAT/Split-DNS setup, relays must obviously be configured in the firewall not only for port 22, but also for port 443 and possibly for port 80. Figure 3.5 displays what such a setup could look like.
In order for ThinLinc to function properly together with the rest of the network, they will need to synchronize time with some internal or external time source. Linux machines use the Network Time Protocol (NTP), so if there is one or several NTP servers on the internal network, the ThinLinc servers will need to communicate with them. Otherwise, the ThinLinc servers should be configured to use some external time source, and should be allowed to communicate with it.