Installing Yunohost in an lxc behind a reverse proxy

Hello,
I recently installed Yunohost (again), and this time in an lxc behind a reverse proxy. While trying to do it I found there wasn’t a whole lot of good documentation for that. So I thought I’d do it myself and maybe help whoever comes searching next. So after digging in threads, reading docs and a whole lot of googling, I present this mess of a tutorial.

I tried to post it here but there were too many links apparently.

7 Likes

Hi PseudoMotivated,

Welcome to the forums!

Nice of you to write the tutorial :slight_smile:

Are you happy with the setup?

1 Like

Thanks for sharing :+1:

Github README support mermaid diagram, zomg :open_mouth:

Here are my notes on an SNI-based approach (with the goal of being to be able to host several machines being a single IP, or expose a YunoHost that cannot be easily exposed through traditional means using another external YunoHost)

The remaining part of the PR is kind of tricky because implementing fail2ban on the proxied server aint trivial in this approach, because all traffic (in terms of IP layer, the one on which fail2ban/iptables act) appears as coming from the reverse proxy so eh

3 Likes

I have, a long time ago, written a tutorial on how to run yunohost 4 inside an lxc container with another lxc container running a docker app (azuracast). All this in a virtualbox VM under windows, proxied by my main yunohost server (an old laptop).
All was working great, but I deleted the VM after a while since I didn’t need the containers.
I also had to move my blog from Hugo to something else, because I had very little time on pc and preferred other solution to easily write on phone (meanwhile my blog is showing “under construction”). The idea of writing on github seems very interesting.

Yes absolutely!

Pretty much indistiguishable from baremetal performance, and so far minimal issues.

However there is only one thing I’ve yet to figure out how to solve and that is forwarding the real IP address of client to the final destination. As in the webmin interface all logs show that it thinks its talking to 127.0.0.1.
Which can be bad, however my threatmodel allows for it, though if anyone has any suggestions it would be much appreciated :slight_smile:

Hello,
I also noticed this issue, and I believe that I fixed it in this revision because when I test with the ynh app ifconfig it now tells me my real IP instead of the reverse proxy containers IP as it did with the previous revision of the guide. I have however not retested this new version beginning to end as I did the previous one and therefore put it in a different branch. What I did is enabled proxy_protocol for the containers proxy devices, and in the nginx configs. I then added a config to the yunohost nginx to get the clients ip from the reverse proxy. It wasn’t a totally obscure fix, and it seems to work as far as I can tell. Here is the revised version

Yes, the “proxy protocol” / X-Real-IP thing in nginx is “half” of the solution

The real issue is that in an ideal world, you would like the proxied yunohost to handle fail2ban on its own. But the whole X-Real-IP thing happens on the HTTP layer, whereas iptable acts on the IP layer … and on the IP layer, every packet appears as sent from the reverseproxy “front” …

so even if an attacker is doing nasty stuff from, say, IP 66.66.66.66 … nginx will indeed log the right IP because of the proxy protocol / X-Real-IP-whatever … hence fail2ban will indeed end up banning this IP … but all the packets actually arrive from 192.168.x.y (the reverseproxy front) so banning the IP has no effect.

1 Like

I see, in that case then I don’t see any possible solutions. I guess unless fail2ban ran directly on the host or the proxy. To be frank I am in way over my head here anyways, but if I do find some way to work around this I will try to improve the guide to integrate it.