* Exposing a server running on the home network (behind NAT on a dynamic IP) to the internet.
* Doing so by renting a cheap VPS and using wireguard to forward traffic to the server at home.
I love wireguard and use it continuously. My phone has always on wireguard to my home network so all my phone traffic goes through my home router/dns, I can access the various private servers I have at home, get dns based ad blocking etc. I use an ISP that give me a static IP so it was easy to set up. It works like a dream.
That said when I want to run a public server I just rent a VPS and run it on that. I don't want anything I don't own initiating connections to anything on my home network in any way.
I have a setup similar to the OP and there's a really good reason for it: cost. For $2k in hardware (one time) and a VPS + electricity at $20/mo, I can run a 64 core, 192Gb, 24TB server. Let's call that $4400 over the course of 10 years. You would burn through that budget in roughly 1 month to get the same specs on AWS.
Obviously I'm neglecting the impact and cost of network, if it's a hobby you can just reuse your existing connection but you can always buy a dedicated line (and adjust the cost calculation accordingly)
In terms of security, you can mitigate the surface area by running a reverse proxy on the VPS. I've got nginx on the front line which does TLS then proxy_passes to my basement server at its wireguard IP address. So it's strictly limited to http, no direct database or ssh access.
I don't know if I'd ever run a "real" website this way but it's great for hobbies and side projects.
I wonder how you build such a hardware with just $2k (3990x alone seems to cost $3.5k), but with €94/mon you can get 16C32T, 128Gb, 8TB server from Hetzner[1]. It has Zen 3 5950X which has better single core performance than your 64 core assuming that you refer to 3990X, and often single core perf is more important than total perf because you don't use all cores all the time.
I estimate such a configuration to be $2.5k. With $2.5k you can keep the server for 2 years, with network and electricity provided by Hetzner. Also you can terminate it and rent another, better server at any time.
That 64 core server is probably sitting nearly idle most of the time. You don’t just spin up big systems on AWS and leave them idle. The whole point of cloud computing is the on-demand scalability.
You can basically spend nothing until a request comes in, and most hobby projects are low traffic.
For example, I found a project that runs plex media server encoding jobs as Kubernetes pods: https://github.com/munnerz/kube-plex
When you’re not encoding anything, you’re not running much compute.
I think I’ve heard of game servers that wait for players to attempt to connect before starting the instance. If all you’re doing is playing a multiplayer game with friends that instance is going to be off 20+ hours a day.
Still, I haven’t done any napkin math on what applications represent cost savings.
Is the RAM ECC ? Are the drives in a RAID configuration? Is it kept in a server rack? What router, switch, and firewall are your using?
I think in you case colocation data center would be alternative solution.
I do this for my personal web server, but also set up the network rule so that its SSH port is only reachable from my VPN.
IMO, this is super convenient. I can keep my public servers out of my home network (so clear separation of private/public networks), but still a VPN connection is required to log into any of my servers.
https://www.ripe.net/publications/docs/ripe-690#4-2-3--prefi...
You must not have met many ISPs.
Edit: Which I could do as my ISP and mobile network both support ip6. Y'all need better ISPs :D
you do need to look for an ISP that gives you a static ip which isnt even possible where i live
First, network overlays are not easier to setup than VPNs. Installing and configuring a network overlay client on every device is much more work than setting up a single VPN tunnel for every network you want to access. Overlay networks are just easier to plan because there is no planning. But they're not easier to implement.
Second, and far more important, meshing all your devices into a single flat network is dangerous. There is a reason why networks are designed with isolation strategies. Introducing an overlay into your networks breaks down these barriers for you, but also for an attacker.
The only overlay network that has built in firewall capabilities is Nebula. When I started configuring its firewall rules I found myself just recreating my existing segmented networks, but in a much more obtuse way. Instead of configuring a central firewall, I was configuring firewall rules on each device.
After all my research, I'm still running the same segmented network I was running before my overlay experiments. But I would like to give some praise to both Nebula and Yggdrasil. IMHO, these are the two most existing projects coming out of this space right now.
If you're going to rent a server, why not just put your stuff there?
It's also a lot easier to show off demo projects like this - you don't need to copy everything to your VPS and figure out how to run it, you just need to have it running on your local machine (e.g. your development laptop) and let other people access that. Obviously that's not a great system for anything long-term, but if you just want to show a friend something you've made, it's quite useful.
1: https://virmach.com/cheap-kvm-linux-vps-windows-vps/
I only need it's IP address and network, nothing else, to setup a stateless reverse proxy. Which I guess is the best use case for such VPS.
Are they good?
If you value the privacy / integrity of other data then that also is more protected.
It’s the convenience of it that is the big selling point to me.
As I get older, I'm less inclined to look into a DIY way to solve a technical problem. Even if it's "not too complex". When I was younger and had more time to kill (aka stay up all night) that was cool. Sometimes I just wanna get a full night of sleep and am fine paying a small fee for access to a tool or service that I don't have to maintain or think about too much.
Yes, it won't scale to a million visitors, but then again, your purse won't scale to a million cloud visitors either.
His simple static page seems to be taking the load of making the front of HN.
No, they didn't get the traffic of a modern Google, say, because not as many people were online, but they did receive as much traffic as an upper-mid-tier modern site, and served it with machines weaker than a lot of modern phones.
Just serving HTML and small media files is something computers are very good at, if you get out of their way.
in case my power goes out or something
Those aren't really comparable. What does "reliability" mean in this context?
I'm pretty sure this is true in China too. What point are you trying to make?
Empirically false.
Since I can use tinc in bridge mode, I can run tinc on the upstream server and on a local machine which then provides access to several physical machines without running extra software on each of those machines, which is particularly useful for machines that are resource limited, like my Macintosh LC II and LC III+:
It'd be nice if it weren't so difficult to get public addresses.
(Every time I see tinc mentioned, I'm frustrated 1.1 hasn't been released. I made contributions to it 15 years ago that still haven't been released.)
[1] https://www.tinc-vpn.org/pipermail/tinc-devel/2006-January/0...
https://serverfault.com/questions/1098093/how-setup-wireguar...
The combination of wireguard + firewalls and the complexity of iptables is not intuitive at all...
Once the clients talk to the lighthouse to build the tunnel they communicate directly
When the NAT punching works it's great. However (AFAIK) there's no option to use the lighthouse as a backup for when NAT punching fails, and when NAT punching inevitably fails it just doesn't work, even when everything can talk to the lighthouse.
I've only used this on very conventional networks, so I haven't quite noticed this difficulty. With this in mind, it is a little harder to generally recommend.
Now I’ve never tested this with a public/high(er) volume service but it lets me pen test internal networks just like I’m sitting in the NOC. And my “VPS” host can handle dozens of simultaneous connections to dozens of endpoints. I have SSH listening on a non-standard port (eliminates 95% of the script-kiddie noise) and cert auth. That’s the only listening service on the VPS box.
I am familiar with some “TCP-in-TCP” problems but I’ve never had any. If it falls down, it just reconnects when traffic can pass again.
So what am I missing?
AutoSSH has been 100% reliable for me, with any lost connection restarting without conflicts, duplication, or error. My AT&T connection is definitely not five nines, so any tunnel needs to deal with restarts very well.
The only upside I can see is that it can protect against targeted attacks on the crappy modem provided by my ISP. But if such an attack is widespread it will probably hit me anyway.
I'd imagine these two points are much more important than DDOS Protection and Caching for most people.
You don't need to pay for an vps nor an extra IP, plus, you don't need to learn about tunneling software such as Wireguard or Zerotier
although clicking the pricing tab - it says hobby / personal use free / "For professional websites that aren't business-critical." - $20 /month
and "For small businesses operating online." - $200 / month
custom price for non-small business..
Although I did not see tunnel there specifically, and the tunnel page just has a 'download the paper' CTA - so it's hard to know what price one should be paying, on top of the first two things of course.
IPv4 isn't cheap these days, so those two requirements are not as easy to attain. Given they specifically mention Hetzner who significantly increased their prices for additional addresses in the middle of 2021 I'm going to assume this page was written some time ago.
Using a single IPv4 should be fine - just port forward that over the VPN. Given most of what people want to publish this way these days is wrapped in HTTP(S), if you want something both local to the VPS and back on your home⁵ server, use nginx or similar as a proxy to split traffic by [sub]domain. You probably want SSH to both the VPS to manage it and to the proxied home server, but that can be done many ways using just SSH¹² or better still use wireguard to connect to the VPN from your remote location and simply route SSH to the home machine over its VPN connection³.
But using something like wireguard is the way to go, many similar examples use SSH tunnels which while fine for some things (I use them all the time) will have additional performance issues in some cases due to TCP-in-TCP congestion management conflicts, and do not deal with temporary connectivity blips (not uncommon on home connections) as gracefully.
----
[1] Though most of these suffer from the TCP-in-TCP issues, that might be less significant than for hosting an app or other service but you are already using wireguard/similar so why not use it some more?
[2] The pure SSH options, which have different [dis]advantages depending on key management, interaction with other tools that wrap SSH, and so forth, include: just manually double-hopping, using the -J option to jump through in one command, configure an alternate named host in your .config using ProxyCommand to configure the second hop, and at least one other that has slipped my mind ATM.
[3] I would still be inclined to have a pure SSH option available as well, in case the VPN is blocked if I find myself constrained by a funky network at a client/other site that isn't limited enough to also block SSH⁴
[4] If you want to go a little more hacky to deal with networks that block try SSH completely but are fairly open wrt HTTPS, there are a couple of options there. I've used shell-in-a-box previously though that seems to be unmaintained ATM, Bastillion may be a better option though I've not tried it myself. Be careful how you secure these tricks if you use them…
[5] I've referred to a “home server” throughout as that is the most common use for this sort of thing in my experience, but it all applies to any other situation where you want to host something on a box that is NAT encumbered and/or not on a fixed IP address.
