Understandable. I tried to put it in easy terms above, not sure how well I did.
You got your NAT’ed private IP for your Pi, 192.168.0.x. You got your public IP on your router, 140.140.140.140. You port forward the VPN port (for openvpn is 1194). Now whatever traffic hits 140.140.140.140:1194 will be directed towards 192.168.0.x:1194 (assuming a 1:1 mapping, so 1194 → 1194).
That means that in order to access your VPN, you need to connect to your router’s public IP on port 1194. If you know your IP address, then that’s easy. But if you don’t and your IP changes (because that’s how all residential connections work), you need a Dynamic DNS. A device on your network will do requests to a DynDNS server to update the IP address whenever the public IP changes. Your Pi can also do that.
Once you are connected to the VPN, you can just access your vaultwarden by going to 192.168.0.x to connect to your reverse proxy on https 443, which in turn connects to vaultwarden (whatever port you gave it).
ah okay, so if I don’t want to create a situation where all of the stuff is gone through one website and instead possibly more then one website having a seperate DDNS is probably best. So that probably should be done before completing the wireguard. I do wonder what the whole thing is with Wireguard as a Docker would be but I feel like that’s beyond my understanding at the moment.
Docker is just a container technology that has a NAT’ed network to access services. Installing wireguard on docker is just like installing wg on your Pi and port-forwarding on your router. But in docker, you port forward from your Pi’s IP to the docker’s port. So the order of things would be: 140.140.140.140:51820 (I think that’s the default wg port) → 192.168.0.x:51820 → docker:51820. Docker is supposedly a convenient way to install, configure and update software, I find it mildly complicated, but that’s just me.
I used to host a bitwarden_rs myself, back when vaultwarden was named that. I fugred how to do persistent storage and all, but it would have been much easier and made more sense if it was just a package available via a package manager or a repo, but I digress.
After struggling to figure out what to do setting up wireguard, I think I might want to go with doing Docker for everything just because it’s popularity means that it seems likely there would be more relevant tutorials and it might make troubleshooting simpler.
Instead of just making a wg conf, you have to also compose a docker run command (not docker-compose). I don’t understand the final docker command part, it looks like part of the config is there in the run command (which I would expect), but I don’t see the private key or the peer public key being mentioned, so I have no idea how that docker config would work.
Not, unfortunately, since the config to run it is quite large. Just that you’d be doing it through a web GUI where you insert each variable to a new entry.
oh yeah if I also want to do Home Assistant stuff do I set up Home Assistant somehow in the Pi and install wireguard a second time?
Or is the HomeAssistant stuff meantured on the wireguard github page unrelated. Where there might be an iso or something where everything is seen through the server being HomeAssistant.
I don’t know how HomAss works, I believe they have both a docker and an image for the RPi and for other boards as well (like the Odroid N2+, which they have a bundle for). But for that, you’d probably have to backup your containers and relaunch them on the fresh homass install. If you use the docker version, you shouldn’t have to worry about (if I’m correct and they have a docker version).
Technically, their version of the OS should be lighter, because it is based on Alpine Linux (which you can install yourself on the Pi). Alpine doesn’t have a desktop, like the RPi OS. Well, it is a good idea that you don’t use the desktop version of RPi OS anyway if you are going to run other stuff on it (to save on resources), but it shouldn’t make that much big of a difference, it’s mostly in RAM consumption, because even if you don’t log in, the login manager (I think they use lightdm) will still eat a bit of RAM there).
So people like using PiMox, which is Proxmox for the Raspberry Pi. Still based on debian, has the same interface and even supports the same clustering methods (corosync)… It has the advantage that you can launch LXC on it via Proxmox webGUI and docker via Portainer (the later which you install manually). It does make managing it a bit easier if you don’t want to use the CLI and still gives you a shell in the web if you need it. I just prefer LXD, because the CLI on it makes sense and is pretty easy to use (proxmox uses its own tooling to manipulate lxc).
before starting on this self-hosting project I actually did set up a new image for the raspberry pi to wipe all the random stuff I had from a python project 2 years ago and I installed the 64 bit version of RPi OS since I saw one video that said it was better then the 32 bit version for the RPi 4.
It is my strong opinion that one doesn’t need to wipe and reinstall linux to make it functional. It does require getting accustomed to keeping track of what’s installed and purging all the unneeded packages. Or at least knowing what was added by doing a list of installed packages (or trial and error and seeing what can be deleted and what not, sometimes by removing multiple packages at once, to get rid of unmet dependencies by removing only some packages).
Anything, this is probably sounding a bit complicated for a beginner. I did take a look on homass and it has the OS version (which from what I remember is based on Alpine), the docker version (which is what I’d recommend you install if you want to play with homassm, via portainer) and some more advanced installs which I won’t look into. Just go with docker, it will be fine.
okay, I think the thing I might be most uncertain about, other then I’ve not really purged anything unneeded that came as a default on Raspberry Pi OS is that there was a cloudflare script to try and keep track of DDNS that I had set up and then I deleted since it connected to a domain other then the one I wanted to use vaultwarden on and I don’t know exactly what needs to be done to get it working properly again. Or if by reserving the WLAN for the RPi if it’s unnecessary. Oh yeah the DDNS thing was done as root. I think it was this video and I’ve failed when trying to recreate it using the domain I’ll be using for vaultwarden. DDNS on a Raspberry Pi using the Cloudflare API (Dynamic DNS) - YouTube
All that the duckdns script does is that it connects to the duckdns servers with your DNS authentication key. Their servers notice your ipv4 address, so whenever it changes, they will update the entry. Then you just ping the duckdns domain you set and see that you can ping your home router.
Then you use the duckdns domain and your port-forwarded ehm… port, to connect to wireguard running on the pi. It is pretty straight forward.
Yeah, I’m guessing it does, I maybe should try and see if I can get the dynamic dns on the unused domain to be working properly to fix my mistakes so I’m not leaving tiny weird things as root that are broken.
Follow whatever guide you used to install it in reverse. If it’s a script, it should have an uninstall option (well, some scripts do). Otherwise, check for any running services, kill them, reboot your system and see if they come back up. If so, look for systemd services or crontab entries.
If you know how to read shell scripts, might make life easier in removing the things that the pi-vpn installer added.
Since it’s a github thing I wonder if by just deleting the directory I can restart it. Or is this one of those bad idea things. Though I also haven’t rebooted the pi since doing the most recent test that didn’t work.
Reading it the only thing I’m modifying is a cloudflare.sh though thinking about it maybe what I should have done was just delete the script and make another copy of the script template. But I’ll be smart and reboot first rather then just keep trying things again and again.
okay yeah the crontab is still around should I remove that before testing if anything else is fixed? Actually given what it looks like I can just comment it out instead that seems easier.