VPN tunnel for apps
-
Talked to @girish a little bit to confirm that the
ExposedPortbinds to theapp.httpPortviadockerode.createContainermagic. Soooo...there's only one solution. Usedockerode'sown library to fix this problem. How to do so...I'm not sure, time to look intodockerode'slibrary. But, the.runcommand looks promising. -
This is likely what I need to use (conditionally when connecting the OpenVPN Client app to another Cloudron app):
Closer than I've ever been now. But I still don't know how to use that command yet.
-
Or...or, what if I forced the
ExposedPortto mirror thehttpPort. That would solve the Nginx "502 Bad Gateway" issue (which is the last hurdle for a perfectly working PoC). I mean, is there really any reason for an exposed port in a Cloudron sense since it just reverse proxies all apps exposed ports to 80, 443 anyway. I think I'm going to try this first instead of the whole diving intodockerodething. -
Okay...there is a tiny reason. More like a medium reason. More like a BIG reason. Which is, the web apps themselves most-of-the-time choose to listen only on their exposed port (which means, I'd still need to manually proxy their exposed port to their
app.httpPort...somehow). But I'll deal with that later. Gotta try this "mirror ports" experiment first to even see if it works.Making a PoC is more important than those logistics rn tho.
-
-
@robi That's a great idea. I've thought about it before, and I'm 99% sure it would work...I just can't wrap my head around it (it's roughly what I meant in my last post when I said " I'd still need to manually proxy their exposed port to their app.httpPort...somehow").
Tbh, I think I burnt myself out because I know you're right. I mean, putting another nginx reverse proxy behind the randomized
app.httpPort(say 32344) toproxy_passto an exposed port (say 8080) would so work. My brain is just having trouble processing the concept rn (as in, where I'd need to put that code since I think it would still have to be created at theboxlevel). -
So, your idea is my next attempt at making the OpenVPN client universal.
Oh, and I need to find a way to make Cloudron expose all of OpenVPN Client's internal ports. Or at least the common ones - because the second app inherits the exposed ports of OpenVPN Client app (so the two apps would need to match up their exposed ports somehow, and a wildcard, open all ports on the OpenVPN Client's side seems like the only way to do so).
-
@Lonk said in VPN tunnel for apps:
@robi That's a great idea. I've thought about it before, and I'm 99% sure it would work...I just can't wrap my head around it.
Take a break. Please
A nap, walk, anything.@Lonk said in VPN tunnel for apps:
So, your idea is my next attempt at making the OpenVPN client universal.
Right on!
Oh, and I need to find a way to make Cloudron expose all of OpenVPN Client's internal ports.
That means Nginx goes into the OpenVPN container, no?
Rules for reverse-proxying are something along the lines of:
if coming from internal IPs, do X
if coming from cloudron IP, do Y
if coming from elsewhere, do Z to the App. -
@robi said in VPN tunnel for apps:
That means Nginx goes into the OpenVPN container, no?
Rules for reverse-proxying are something along the lines of:
if coming from internal IPs, do X
if coming from cloudron IP, do Y
if coming from elsewhere, do Z to the App.I'm new to nginx, literally only using it's .conf files to try to get this working as a mere proof of concept. But so far I'm only familiar with
proxy_passfor it taking incoming 80, 443 ports to pass it to the internal Docker port (and IP...I think but I don't *think this is an IP issue, though it might be). -
@robi But if I wanted to expose all of it's ports, it would actually be more of a
boxdocker.jsthing with the "exposed ports" parameter being fed togContainer.createContainer. I should be able to do that after I give my mind a lil break. -
Okay, after hardcode exposing ALL internal ports of the OpenVPN container, now the last thing is adding a second nginx reverse proxy which would mean this:
My exposedPort for the Gucamole app I'm installing to connect to the OpenVPN Client app exposes 8080. It gets a Docker internal
httpPortof 32455. Nginx already correctly creates a nginx proxy config from web incoming port 80 and 443 to 32455 (somehow, presumably DNS TXT records, it even gets an SSL cert).So, I need to have nginx after that continue to proxy it to 8080. Which normally is Docker's job (with it's binding port) but when connecting two container's networks together, it doesn't do that job with the
dockerodelibrary for some Docker-y reason. I wonder...can I reverse proxy it in the same file as the original reserve proxy server. Or do I have to create a.confand an entirely new one? -
If I have the same nginx reverse proxy "listen" to it's own forwarded port (32455), then I could
proxy_passagain to the real internal port and IP (8080) of Guacomole (the test app I'm now using to connect to the vpn client app)...or maybe I need another reverse proxy residing at Internal-IP-of-Guacomole:32455 to thenproxy_passagain to 8080. -
The problem there is that the stuff in the container doesn't have access outside the container, so it's hard to drop updates to the host Nginx as another .conf file.
You could tell box to do it via how it already happens for new apps. Must be an API for it.
-
@robi I keep trying to experiment on how to shoehorn a second Ngnix proxy into this to get it all up and running 100% with no success.
Inter-communication between the two containers would be nice, but tbh I could hardcode that if I knew how to setup the second reverse nginx inside of
reverseproxy.js. Which, honestly, I can't figure out how. -
I know the answer lies here:
https://git.cloudron.io/cloudron/box/-/blob/master/src/reverseproxy.js#L463
I can configure a second file for a second nginx server to proxy
app.httpPorttoapp.manifest.httpPort- but, like, I don't know how to change that it's hardcoded to listen only on 80 and 443. Plus, I don't know how to actually get this hypothetical second nginx reverse proxy running to "take" the new config within the container that's connecting to the VPN. But that's the last step here on how to make this work. -
@mehdi said in VPN tunnel for apps:
(Disclaimer: I am no expert on docker networking magic)
I think instead of trying to find a way to expose the ports from the OpenVPN container, you should instead try and find a way to make it work directly from the app container itself.
Even if you do make it work for the exposedPort (which, I think, refers to the main web port exposed by the app, the one which is behind the reverse proxy, to expose its web interface and such, that's why there's only one: there's only one web interface), you're gonna have trouble with the extra ports (the ones defined in the manifest here https://docs.cloudron.io/custom-apps/manifest/#tcpports ) for apps that use these.
I really think this. You should try finding a way to make the app container's default route be through the OpenVPN network, but still be connected to cloudron's regular network so it can interact with nginx and stuff. There is no good reason to make all the traffic, even the local one, be through OpenVPN.
@Lonk is there a repo with your box changes ? Maybe I'll have time to take a look this WE
-
@mehdi You only have to change one file (docker.js) so I’ll send that to you today!
But the app has no other issues. It is on the Cloudron network. It has everything network-wise that the OpenVPN container has which means there are no issues anywhere. The only issue is that Nginx doesn’t take that into account because it inherits all network ports and modes from the OVPN Client it’s connected to.
I actually have an idea though to prove that everything works except the web interface using the app terminal.
I will also be sending you my OVPN client in chat so you can see how it works.
I had a sneaking suspicion it was a 
