With the upcoming 4.20 release of ThinLinc later this year, we are excited to share some information about what we have been working on.
My name is Hannes, and I’m a part of the ThinLinc development team at Cendio. For the 4.20 release, my colleagues and I have been working on improving the experience when connecting to ThinLinc Web Access behind a reverse proxy.
A reverse proxy sits between the client and server and redirects the client’s requests to one or more backend servers. This may be done for several reasons, such as policy, security, or organizational needs.
One use case could be when assigning users to some specific subcluster. Instead of all users going via the master server for every connection, the reverse proxy in front of the master can tell all authenticated users to redirect their connections to the reverse proxy managing their specific subcluster. Thus offloading traffic from the master.
With this update, we made necessary server-side restructuring to facilitate reverse proxy communication.
With ThinLinc 4.20 it will be possible to:
-
Run Web Access through a reverse proxy to an agent or with a complete redirect to a new proxy.
-
Run Web Access in a subpath to allow for multiple servers to run on the same reverse proxy.
-
Forward the client’s true IP address using the optional X-Forwarded-For header via a trusted proxy.
We hope these features will help you shape ThinLinc to better fit the needs of your organization. Whether that be running other services on the same server using a subdirectory or using a reverse proxy to separate your internal machines from those externally visible.
Behind the scenes:
For this release, when dividing the tasks, there was a small group tasked with explorative research to find out more about the area, what currently worked, and which tools are commonly used. This initial research was necessary to elevate the knowledge of the entire team in formalizing the goals and requirements.
When we found that configuration alone was insufficient, we looked at how we could improve ThinLinc to allow simpler configurations.
I joined in after the initial research phase, where a large part of the work was spent in iterative steps to minimize the working configurations of Apache, NGINX, and Caddy. When we found that configuration alone was insufficient, we looked at how we could improve ThinLinc to allow simpler configurations. Meanwhile, work was done to start using relative paths in Web Access to minimize the assumptions made about how a network should look and act.
After locating and discussing the part where reverse proxies used to fail with ThinLinc, and some potential solutions, the change to ThinLinc was made in a group session of 3 to 4 developers.
Afterward, effort was made to validate our solution by testing reverse proxy for Apache, NGINX, and Caddy in setups of varying complexities and ensuring a minimal possible configuration. Here, a lot of work documenting our decisions and writing concise and informative documentation for the ThinLinc Administrator’s Guide was also done.
For me, with this being my first experience working with reverse proxies, the most challenging part was to learn one tool and its configuration and then to not make assumptions about how the other tool should work.
There was no one-to-one translation for many of the config settings due to differences in their design. This made the testing to ensure that there was some minimal config for all the proxies and all the test setups critical in testing our solution.
It has been rewarding to, with this release, learn more about proxy configurations, an area that I did not have a lot of experience with going in. We’re all excited to hear what you think! Is this an awaited feature? Will this improve your daily workflow? Please comment and let us know!
And most importantly, download and upgrade to the 4.20 release later this year and join in on the 4.20 beta that released last week!
Best regards,
Hannes