On Sunday, January 5, 2020, 4:16:46 PM GMT+1, Nick Couchman <[email protected]>
wrote:
>
> Mostly that Guacamole is designed to be a web-based remote desktop client,
> not a full VPN client, and we're interested in keeping the
> scope contained.
Understandable. However, I'm still not sure how the commercial product I
mentioned earlier does it. Even though the provider mentions "SSL-VPN" in its
on-line guide, I doubt it can be a "real" VPN client as it would imply admin
privs on the client (supposedly, nothing is supposed to be run as root/admin).
So that's why I'm wondering (cannot confirm it yet) if the provider has
implemented some sort of HTML to image rendering, or if it's "merely" a
redirection to a reverse proxy. If that were the case then I already have my
Apache HTTP service configured for reverse proxy (I also have a few Squid
instances for other HTTP services). So sure, I could merely "extend" Guacamole
to display URL connection objects when the user logs in, alongside RDP, telnet,
ssh and VNC connections. The problem I'm facing is that for some reason I don't
fully share, I am asked to create a single portal and a single URL, eg.
https://guac.domain.org/ from which the users can then connect to whichever
internal service. Since I've managed to configure fully functional reverse
proxies with Apache HTTP (but had redirection issues with Squid), I would need
to use at least a different port or domain. I guess what I really need to do is
learn how to configure a reverse proxy with Apache Tomcat and try to use the
same port for that. It would look something like this:
https://guac.domain.org/proxy1 -> internal HTTP service 1
https://guac.domain.org/proxy2 -> internal HTTP service 2
https://guac.domain.org/proxy3 -> internal HTTP service 3
and so no.
And of course, https://guac.domain.org/ would have to be the guacamole web
client.
I'm new to Apache Tomcat so I guess I have a lot of homework to do.
> First, i share your desire to do as much as possible with Open Source
> software, and I routinely have to fight the battle of why to stick
> with open source rather than spending money on a commercial product.
It's not just a question of money. It is also because OSS is extremely
flexible, and usually adapts faster and better. Customization is the key. Sure,
development can be a bit chaotic sometimes (à la freerdp lib...), but I guess
that's part of the fun.
Big thanks for the support.
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
