This doesn't really work, if you're behind carrier grade NAT and inbound traffic gets dropped.
For example, I tried having a homelab where 2 of my servers would be publicly accessible, could join Docker Swarm/Kubernetes clusters that would be controlled from other cloud VPSes or vice versa, but couldn't really do that.
I did actually document how I worked around it by having 2 cheap VPSes with static IP addresses that forwarded traffic to my local servers, with the local servers being the ones to establish the connection with WireGuard in my blog post "How to publicly access your homelab behind NAT": https://blog.kronis.dev/tutorials/how-to-publicly-access-you...
Of course, forwarding all ports (even if most are closed) might be a little bit insane and the article could be written better, but definitely not everyone gets publicly accessible IPs from their ISP without opening their wallet and forking over some cash (getting a VPS and using WireGuard was easier).
Then again, having a homelab and using personal hardware for hosting non-essential stuff is a pretty great approach! You'll most likely be able to get resources much cheaper than renting VPSes from most providers (especially AWS, Azure and GCP) would be in the long term. That said, things like my homepage or blog are hosted "in the cloud" due to this allowing me to break my homelab or have maintenance windows whenever I want without inconveniencing anyone.
> If you're behind carrier grade NAT and inbound traffic gets dropped then you don't have an internet connection.
What an interesting statement. It's certainly called an Internet connection in all of the marketing materials and is regarded as such by everyone that I've talked to. I guess it's a case of most people's standards and thus common parlance being vastly different to what someone else might expect. Then again, self hosting is a niche thing to do, so that's understandable.
In addition, one could even argue that giving people's devices public IP addresses might be a bit problematic in the first place, from a security point of view - in University every device that I connected to the network got a public IP address and without fail any with an SSH server was the subject of attacks not long after.
Though the real explanation is probably one that has to do with finances and the lack of IPv4 addresses, as well as the fact that IPv6 adoption in Latvia is basically non-existent, from what I can tell.
This doesn't really work, if you're behind carrier grade NAT and inbound traffic gets dropped.
For example, I tried having a homelab where 2 of my servers would be publicly accessible, could join Docker Swarm/Kubernetes clusters that would be controlled from other cloud VPSes or vice versa, but couldn't really do that.
I did actually document how I worked around it by having 2 cheap VPSes with static IP addresses that forwarded traffic to my local servers, with the local servers being the ones to establish the connection with WireGuard in my blog post "How to publicly access your homelab behind NAT": https://blog.kronis.dev/tutorials/how-to-publicly-access-you...
Of course, forwarding all ports (even if most are closed) might be a little bit insane and the article could be written better, but definitely not everyone gets publicly accessible IPs from their ISP without opening their wallet and forking over some cash (getting a VPS and using WireGuard was easier).
Then again, having a homelab and using personal hardware for hosting non-essential stuff is a pretty great approach! You'll most likely be able to get resources much cheaper than renting VPSes from most providers (especially AWS, Azure and GCP) would be in the long term. That said, things like my homepage or blog are hosted "in the cloud" due to this allowing me to break my homelab or have maintenance windows whenever I want without inconveniencing anyone.