VPN tunnel for apps
-
You can't getAppByManifestId since there can be many apps for a given manifest id. I think you have to store whatever you want in the database in the apps table. Then when you get the app, you can get that information (like say the network id). Sorry, if my answer is totally off since I didn't read the full thread completely.
-
@girish I had actually nailed that issue out actually as a matter of fact. The only thing I have left is
getLocalIPAddressByApp(app)- but maybe theappobject already stores its internal IP (I didn’t think it did, but it stores a lot)? -
@girish As for the first function, it was mainly due to me needing to find a way to identify the VPN client app by the only unique identifier I knew. I’ve hardcoded it for my use case rn...but that won’t work for the production version now that I think about it - so I’ll still need to get app data using the manifest.id (com.joelstickney.openvpn-client-cloudron). So when the app that needs to connect to it starts, it attaches to the container ID of the Open VPN client on
containerCreate.Maybe right now I’ll store the things I need in ENV variables and find a way to use the “apps” object to parse through all of them till I find the VPN client.
-
@girish I think you’re right about using the app table. I’ll try to RE how you use it to populate the
appsvariable.And no worries not following along with this thread. It’s been really difficult for me to get this working so I used this as kind of note-taking. Now that I’m nearly finished, people won’t get as bugged by my posting here every time I discover something new about the way
boxworks.
-
@girish said in VPN tunnel for apps:
getAppByManifestId
I guess the proper function name then would be
getAppsByManifestId- the point is to get the possibly multiple VPN Clients installed to populated the drop down box in other app’s configs asking which VPN Client app they would like to share a network with. So this is a needed function and I can parse through the app DB to collect the data.I found your function to
getIDByIPAddressand I’m basically using it as a reference to write the opposite function nowgetIPAddressById. Would you like me to make this a function or would you like me to just put the code in theNginxAppConfigfunction the singular time I need to use it? It’s needed to make all of this work.I need you to know of the singular limitation of the VPN Client app though:
• Multiple apps can connect to a singular VPN Client app unless two apps exposed
httpPortsare the same. So you couldn’t connect two of the same app or different apps that use the same web port. I cannot find a way around this except to install a second VPN Client. Which I don’t think is a bad solution given how small my app is. But that will have to be enforced in the drop down box via a new function. I don’t plan on touching dashboard code tho so I’ll leave that up to you. But when you get to that step, tell me and I’ll write you a function to only show you the VPN clients whose connectedapp.manifest.httpPortsdon’t conflict with the app being configured in the dashboard to protect users from port conflicts. -
@girish (or @nebulon) I'm finished with the OpenVPN Client app, and with the
docker.jsandreverseproxy.jschanges needed to make it work. Right now, it's hardcoded so that if any app being installed with a domain name containing "vpnconnect" it will connect to the OpenVPN Client if there is one (you'd need to change this hardcodedifconditional to be the dropdown box value where you choose which VPN Client to connect on the Cloudron Dashboard that @girish suggested - since you can install as many as you want and thus connect as many as you want to them, a dropdown will be needed).Everything is working perfectly now. But, my code to get the IP Address and the container name of the OpenVPN Client is...not great.
Ideally, on starting the VPN Client app, it would (if I could have figured it out) add it's IP Address and container name somewhere easy for other apps to retrieve those two pieces of data and connect to the client since those are the only two values needed. But instead I changed the
docker.js-createSubcontainer()function and also when writing the Nginx.confinreverseproxy.js-writeAppNginxConfig()- I parse the DB for those VPNClient values and get them - but it's messy code. Could I send you those files for you to look over? I don't know another way to write the code - but my original goal was to loadVPNClientIPAddressandVPNClientContainerNameinto every app object on initialization if an app exists on Cloudron who'smanifest.idincudes "vpnclient". I'm sure that's possible, but I couldn't find where you load theappobjects values. I could RE some more and find it, but this works so I'm just gonna use it.So now that this is
working with no issues, where should I go from here to:- Make this an official app on the App Store?
- Work with you guys to make the
boxchanges that are needed to make the app work?
-
Note: I'm still working on a simple web interface to change the
.ovpnfile rather than having to replace the file in the Cloudron File Manager (the web interface will do it for you). When the file is changed in the web interface, the container / app will restart via a Cloudron API call meaning the user would have to provide their Cloudron token unless there's another way to restart the container from within it (but I plan on just disconnecting and reconnecting to the new file with no container restart - but for an MVP that will work). Right now, you have to change the file in the Cloudron File Manager and restart the app yourself. -
For anyone interested in the full VPN Client app's code, I pasted it here: https://github.com/lonkle/openvpn-client-cloudron
Still unfinished. Gonna complete 1.0 and then move it to Cloudron's Git.
-
Quick Ideas for the web interface I wanted to jot down:
• Easy access to common VPN providers
• Attaching VPN app to other app's from within the app itself (using the Cloudron API)
• Saving previous connections for later use
• Not having to restart itself (the app) every connection change (there's no avoiding needing to restart an app that's connecting to it though, that's a limitation of docker unlessdocker network connect --link vpnclientcontainername cloudron container2would work to mitigate this - it did not in my testing but I know more now, I'll test this again at some point). -
@Lonk I am not sure changes to the reverse proxy code are required at all. Maybe I didn't get a full grasp of your feature request, so let's take a step back.
-
The reverse proxy is only for inbound traffic. It's not used for outbound traffic. It's just a demuxer for incoming http requests to the app containers. My understanding of the feature you suggested was that we want say TTRSS, to use the tunnel for outbound traffic like say when fetching RSS feeds. This means that https://reader.domain.com itself still points to Cloudron but any outbound traffic originating from the container goes via this tunnel.
-
You shouldn't filter by app id etc in docker. Instead, we have to first create a networkId entry in the apps table. Then, app.networkId is then simply the network id to be used in docker.js when creating the container. We don't even have to filter by openvpnclient app etc. The filtering will be done by the dashboard code (i.e in the UI).
I can help out a bit more but I want to first double check if we are in sync about this reverse proxy stuff.
-
-
@Lonk said in VPN tunnel for apps:
@mehdi said in VPN tunnel for apps:
What you should try to achieve is making only the app's outgoing traffic go through OpenVPN, and the connexion between it and Nginx and stuff stay exactly the same as it currently is
That is currently the case as far as I can tell. All incoming traffic bypasses the VPN entirely. Outgoing traffic uses the VPN's connection. But the NGINX needs an incredibly minor change. There's no way around that.
It seems @mehdi nailed it already
What is the minor change you require in reverse proxy? -
@girish Well, @mehdi is correct that that should be how it works. But it has always worked this way.
The problem was never trying to run incoming traffic through the VPN. The problem lies in that if you connect two app's NetworkMode’s together, they have to share the same IP and it removes all network binds to the secondary app (so your healthcheck and nginx routing can't do anything with the info it usually uses). So, the reverse proxy change detects if an app is connected to a VPN Client and if it is, it uses the Docker actual / internal IP and the secondary app’s actual exposed port to route the incoming traffic to.
It can’t use localhost:randomizedport (127.0.0.1:56343) unless we used a second nginx proxy to forward its randomized Docker port
app.httpPortto its real IP and real exposed port. Docker, in normal circumstances, binds these things for all apps unless their “NetworkMode” is another container - which it is in this case, to make the VPN function.Did I properly explain that / does it make sense?
Note: I'm positive there's a very complicated solution to this that I mapped out and is too ridiculous to implement. But there is a caveat, which is that multiple apps using the same exact
exposedPortcannot co-exist on the "same network" / connected-to-the-vpn-container. But that's kind of the point of the OpenVPN Client sharing it's network connection, sharing the IP. So, we could restrict one app to connect to one VPN rn to remove "Error: Port Collision" user errors - because you can always install more than One VPN client and connect it to the same VPN. Less work. Don't really see a use case for a a lot of the "same exposed port" apps being used with the same vpn client, but we can let the community decide on that later? -
@girish said in VPN tunnel for apps:
You shouldn't filter by app id etc in docker. Instead, we have to first create a networkId entry in the apps table. Then, app.networkId is then simply the network id to be used in docker.js when creating the container. We don't even have to filter by openvpnclient app etc. The filtering will be done by the dashboard code (i.e in the UI).
100% agreed. I'm only doing that now as a proof of concept because, tbh, I'm not sure where to put this option in the dashboard code (plus dashboard code is harder to work with). So, my hack to filter the other apps to crab the
containerIdof the OpenVPN Client (and using a hardcodedapp.fqdnconditional to connect to it), I'll use for now until you have time to get together and talk about how to implement this on the front end. -
TODO: Last two things.
• I WILL: Add backend interface to allow a logged in user to submit any .ovpn file via a file chooser and convert it to what Cloudron needs after submitting the new.ovpn.• @girish MIGHT HAVE TIME TO DO: Modify Dashboard and
appdb.jsto add thevpnclient'svpnContainerIDandinternalIPto use inNetworkModefor any apps choosing to route only their outgoing traffic through the VPN (presumably a drop-down box in the config option of an app which will need to be coded in the dashboard, codes to the ovpn-client's manifest ID - which allows for getting thecontainerIDandinternalIPof thevpnclientapp).DONE:
Add an HTTP API endpoint to change and convert any .ovpn file a user supplies via POST into the container and disconnect from current to connect to the newly added .ovpnDONE:
Add a front end web interface login page at the base URL of the app which allows for logging in to the app via Cloudron's LDAP -
To anyone who really needs this right now. I just finished with the beta. I've tested it, but there is one manual step needed (you have to copy and paste the "containerName" of your app into a file in the OpenVPN Client File Manager) until @girish has time after 6.0 to add some Dashboard polish to the whole thing in which case the only thing you need to do is add an
.ovpnfile to it's backend, which you simply login with the same credentials you login with Cloudron (since it has LDAP integration) and it'll do the rest. The @girish Dashboard code I think he's adding is a dropdown box to all installed OpenVPN client app's to choose which one you want to connect to (right now, like I mentioned, you have to manually add that to the file inside of the VPN Client's filesystem which isn't very intuitive)". -
Oh, and it may require like 4 or 5 patches to
boxcode. Forgot about that.
It's fully functional tho, a little unpolished, a lot unpolished. But everything works. @girish and I will work together to integrate it properly at some point after 6.0. My patches run at "start" time, so the fact they're inefficient isn't too big of a deal, but just know that somewhere down the line, @girish and I will add it properly into a stable version of Cloudron. -
@lonk said in VPN tunnel for apps:
Oh, and it may require like 4 or 5 patches to
boxcode. Forgot about that.It's fully functional tho, a little unpolished, a lot unpolished. But everything works. @girish and I will work together to integrate it properly at some point after 6.0. My patches run at "start" time, so the fact they're inefficient isn't too big of a deal, but just know that somewhere down the line, @girish and I will add it properly into a stable version of Cloudron.What an accomplishment this was for me back then. I like that my first post in the forums is this crazy hellscape of Cloudron and Docker development jargon. I also wonder if this will ever help anyone down the road. Either way, I'm glad this whole thing is archived, it's p nostalgic for me.
️
