I have a thinlinc server on a ubuntu computer which is working and reachable from network 192.168.0.1/24 with dhcp server 1 such that all clients can work with the thinlinc client software. I have installed a second network card on the server with its own dhcp server 2 on the network 192.168.1.1/24.
When a client is on the second network 192.168.1.1/24 he or she can build a ssh connection to the ubuntu server via terminal but, now the problem is, if I try to build a connection via the thinlinc client it tries to reach the thinlinc server at 192.168.0.1 but this fails and the thinlinc client doesnt change and it stays frozen.
How do I have to set the thinlinc server OR the ubuntu network configuration such that clients on the second network 192.168.2.1/24 will get through the second nic a connection to the thinlinc server which was initally configured on the 192.168.0.1/24 network???
We need this due to network balance reasons such that many users are can work on both network cards.
@gwagon what is your agent_hostname parameter (see here) set to in vsmagent.hconf? You can check like this:
$ tl-config /vsmagent/agent_hostname
The ThinLinc client makes two connections per login, one to the master and one to the agent. In your case, both master and agent are on the same machine. The agent is identified to the client using this agent_hostname parameter, and if this parameter is set to your 192.168.0.1 address, this is what the client will try to use for the second connection, regardless of which network it is on.
If I understand your setup correctly, you would need to use some kind of split-DNS configuration. For example, you would need to set agent_hostname to a resolvable hostname (e.g. agent.example.com), and make sure that this hostname resolves correctly for each client. That is, it would need to resolve to 192.168.0.1 for clients on the 192.168.0.0/24 network, and 192.168.1.1 for clients on the 192.168.1.0/24 network.
Another option would be to run ThinLinc in cluster mode (see here). So you would have one master server and several agents, all on the same network, but each with their own network interface. ThinLinc will then load-balance sessions across each agent in the cluster.
thank you very much for your reply and friendly statement.
I looked up and tl-config /vsmagent/agent_hostname gives me empty message and after I looked up in /opt/thinlinc/etc/conf.d/vsmagent.hconf there is no entry in agent_hostname=
I agree the dns split configuration is apparently the solution OR my guess, not sure about this, maybe I need to configure a linux route rule for traffic which comes from 192.168.1. to 192.168.0. where the vsm server and agent are located such that they also reply and use the correct network 192.168.0. for clients of second network.
I would be very happy if you have further suggestions and I am looking forward to your reply.
If agent_hostname is empty, it will default to the IP address of the primary network interface.
There are probably a number of ways you could configure your network to achieve what you’re after, however I suspect the easiest way is to run ThinLinc in cluster mode, with multiple agents to spread the load across.
I’m not sure how a cluster configuration would help in this case ?
The split DNS or static routes on the client should absolutely work. The split DNS is of course the best way to handle this, if possible.
The static route options on all 192.168.1.0 clients also works, but is not that nice.
You probably could assign static host routes via DHCP.
If the thinlinc server requires you to connect to 192.168.1.1
A static host route could solve the problem. This is not a scalable solution but might work for you.
In this setup i don’t think you need to enable IP forwarding on the thinlinc server.
A better way is to setup split DNS. The short version is that if your thinlinc servers is named “thinlinc”. Clients on 192.168.1.0 network should resolve “thinlinc” to 192.168.1.1 and the clients on the 192.168.2.0 network should resolve thinlinc to 192.168.2.1. This can be done in a single DNS server. Google “split dns”
