but without nix it’s a pita to maintain through restores/rebuilds.
No it isn't. You can even define those routing polices in your systemd network unit alongside the network interface config and it will manage it all for you.
If you aren't comfortable with systemd, you can also use simple "ip" and "route" commands to accomplish that, add everything to a startup script and done.
major benefit to using a contained VPN or gluetun is that you can be selective on what apps use the VPN.
Systemd can do that for you as well, you can tell that a certain service only has access to the wg network interface while others can use eth0 or wtv.
More classic ip/route can also be used for that, you can create a routing table for programs that you want to force to be on the VPN and other for the ones you want to use your LAN directly. Set those to bind to the respective interface and the routing tables will take place and send the traffic to the right place.
You're using docker or similar, to make things simpler you can also create a network bridge for containers that you want to restrict to the VPN and another for everything else. Then you set the container to use one or the other bridge.
There are multiple ways to get this done, throwing more containers, like gluetun and dragging xyz dependencies and opinionated configurations from somewhere isn't the only one, nor the most performant for sure. Linux is designed to handle this cases.
In terms of homelab stuff, I know a lot of people appreciate the containerized approach.
What I said applies to containerized setups as well. Same logic, just managed in a slightly different way.
By “set up wireguard to route through the VPS” you mean having wireguard forward a port from the VPS to a port on the homeserver at its wireguard IP address?
Yes, he means that.
qBittorrent will still need to publish the right IP address to peers though, right? So I will need to configure the proxy VPS’s IP address in qBittorrent…
No. For most things qBittorrent does public IP detection. For the rest your VPS will be doing NAT between the WG interface and the public internet. This means your qBittorrent client sends outgoing packets with the source address of your WG private IP and then the VPS will change those to it's public IP address.
The thing you must be careful about is that you need to restrict qBittorrent to only send and receive traffic on the WG interface, otherwise it will be using both. You can do it in the settings, but the safest way is to do it at the container setup or systemd service level and completely hide any interface that isn't the WG one from it.
You can force all outgoing traffic to use the VPN interface via iptables/routes (meaning if it doesn’t exist or doesn’t work nothing will be able to access the internet) OR use systemd globally hide the non-VPN network interface from all services except for the VPN client.
All of that can be achieved with simple systemd or iptables/routes tweaks. You can force all outgoing traffic to use the VPN interface via routes (meaning if it doesn't exist or doesn't work nothing will be able to access the internet) OR use systemd globally hide the non-VPN network interface from all software except for the VPN client.
Exactly that's a job for the parser / consumer.
No, I'm kind of serious, the comment situation is already solved in JSON... about the rest yeah, Yaml might be easier but the different isn't that much. Non tech people can't edit Yaml properly either so.
There's a lot of JSON parsers that don't mind to see comments there, just ignore them. And there's also the "_comment" / "$comment" thing.
Yes, they could've just used JSON. Totally pointless waste of time.
It depends on what you're self-hosting and If you want / need it exposed to the Internet or not. When it comes to software the hype is currently setup a minimal Linux box (old computer, NAS, Raspberry Pi) and then install everything using Docker containers. I don't like this Docker trend because it 1) leads you towards a dependence on property repositories and 2) robs you from the experience of learning Linux (more here) but I it does lower the bar to newcomers and let's you setup something really fast. In my opinion you should be very skeptical about everything that is "sold to the masses", just go with a simple Debian system (command line only) SSH into it and install what you really need, take your time to learn Linux and whatnot.
Strictly speaking about security: if we're talking about LAN only things are easy and you don't have much to worry about as everything will be inside your network thus protected by your router's NAT/Firewall.
For internet facing services your basic requirements are:
- Some kind of domain / subdomain payed or free;
- Preferably Home ISP that has provides public IP addresses - no CGNAT BS;
- Ideally a static IP at home, but you can do just fine with a dynamic DNS service such as https://freedns.afraid.org/.
Quick setup guide and checklist:
- Create your subdomain for the dynamic DNS service https://freedns.afraid.org/ and install the daemon on the server - will update your domain with your dynamic IP when it changes;
- List what ports you need remote access to;
- Isolate the server from your main network as much as possible. If possible have then on a different public IP either using a VLAN or better yet with an entire physical network just for that - avoids VLAN hopping attacks and DDoS attacks to the server that will also take your internet down;
- If you're using VLANs then configure your switch properly. Decent switches allows you to restrict the WebUI to a certain VLAN / physical port - this will make sure if your server is hacked they won't be able to access the Switch's UI and reconfigure their own port to access the entire network. Note that cheap TP-Link switches usually don't have a way to specify this;
- Configure your ISP router to assign a static local IP to the server and port forward what's supposed to be exposed to the internet to the server;
- Only expose required services (nginx, game server, program x) to the Internet us. Everything else such as SSH, configuration interfaces and whatnot can be moved to another private network and/or a WireGuard VPN you can connect to when you want to manage the server;
- Use custom ports with 5 digits for everything - something like 23901 (up to 65535) to make your service(s) harder to find;
- Disable IPv6? Might be easier than dealing with a dual stack firewall and/or other complexities;
- Use nftables / iptables / another firewall and set it to drop everything but those ports you need for services and management VPN access to work - 10 minute guide;
- Configure nftables to only allow traffic coming from public IP addresses (IPs outside your home network IP / VPN range) to the Wireguard or required services port - this will protect your server if by some mistake the router starts forwarding more traffic from the internet to the server than it should;
- Configure nftables to restrict what countries are allowed to access your server. Most likely you only need to allow incoming connections from your country and more details here.
Realistically speaking if you're doing this just for a few friends why not require them to access the server through WireGuard VPN? This will reduce the risk a LOT and won't probably impact the performance. Here a decent setup guide and you might use this GUI to add/remove clients easily.
Don't be afraid to expose the Wireguard port because if someone tried to connect and they don't authenticate with the right key the server will silently drop the packets.
Now if your ISP doesn't provide you with a public IP / port forwarding abilities you may want to read this in order to find why you should avoid Cloudflare tunnels and how to setup and alternative / more private solution.
If you know your way around Linux you most likely don’t need Proxmox and its pseudo-open-source... you can try Incus / LXD instead.
Avoid Proxmox and safe yourself a LOT of headaches down the line. Go with Debian 12 + Incus/LXC, it runs VMs and containers very well. Proxmox ships with an old kernel that is so mangled and twisted that they shouldn’t even be calling it a Linux kernel. Also their management daemons and other internal shenanigans will delay your boot and crash your systems under certain circumstances.
LXD/Incus provides a management and automation layer that really makes things work smoothly - essentially what Proxmox does but properly done. With Incus you can create clusters, download, manage and create OS images, run backups and restores, bootstrap things with cloud-init, move containers and VMs between servers (even live sometimes).
Another big advantage is the fact that it provides a unified experience to deal with both containers and VMs, no need to learn two different tools / APIs as the same commands and options will be used to manage both. Even profiles defining storage, network resources and other policies can be shared and applied across both containers and VMs.
I draw your attention to containers (not docker), LXC containers because for most people full virtualization isn't even required. In a small homelab if you can have containers that behave like full operating systems (minus the kernel) including persistence, VMs might not be required. Either way LXD/Incus will allow for both and you can easily mix and match and use what you require for each use case. Hell, you can even run Docker inside an LXC container.
For eg. I virtualize the official HomeAssistant image with Incus because we all know how hard is to get that thing running, however my NAS / Samba shares are just a LXD Debian 12 container with Samba4, Nginx and FileBrowser. Same goes for torrent client that has its own container. Some other service I've exposed to the internet also runs a full VM for isolation.
Like Proxmox, LXD/Incus isn’t about replacing existing virtualization techniques such as QEMU, KVM and libvirt, it is about augmenting them so they become easier to manage at scale and overall more efficient. I can guarantee you that most people running Proxmox today it today will eventually move to Incus and never look back. It woks way better, true open-source, no bugs, no delayed security updates, no BS licenses and way less overhead.
Also, let's consider something, why use Proxmox when half of it’s technology (the container part) was made by the same people who made LXD/Incus? I mean Incus is free, well funded and can be installed on a clean Debian system with way less overhead and also delivers both containers and VMs.
Yes, there's an optional WebUI for it as well!
- Context on Incus vs LXD: https://www.theregister.com/2023/08/04/incus_lxd_fork/
- A sum of my experience with Proxmox over the years: https://lemmy.world/comment/7476411
Some documentation for you:
The technology has "been there" for a while, it's trivial do setup what you're asking for, the issue is that games have anti cheat engines that will get triggered by the virtualization and ban you.
You next OS will be... Debian. Because you care about your time and you want stuff to be stable.
I would go with Prosody or Ejabberd, and here's a good comparison: https://stackoverflow.com/a/45531372 and Ejabberd is the most used thing out there. https://xmpp.org/software/
Dude the guy is running on system with restricted resources and you're suggesting the most bloated and prone to fail thing ever.
The OP would be way better with Debian + Cockpit (also provider a webUI and virtual machine manager) or Debian + LXD/LXC (containers + VMs, optional webUI). Both of those solutions are way lighter and won't mess your base system.
Likely because it’s mainly written in PHP and the default database is SQLite
Maybe the issue isn't the technologies but rather the complete and utter ineptitude of NC's developers and bullshit decisions their business team makes. Every tool is a great tool if you know how to use it properly.
So… you're looking for communism in the form of web hosting? 😜
So... now nuclear is considered "green power". Okay boomers.