Live data from Hacker News

Locally hosting an internet-connected server

mjg59.dreamwidth.org

91–100 of 183 posts

Re: Locally hosting an internet-connected server

#91
post #4

Earlier quoted context omitted.

I have multiple devices on my internal network that I want to exist outside, and dynamic DNS is only going to let me expose one of them

Yes, that's how it works when you only have a single IP. The standard way to deal with this is a reverse proxy for web requests. Other services require different workarounds. I have a port 22 SSH server for git activities, and another on a different port that acts as a gateway. From that machine I can SSH again to anywhere within my local network. It's really not onerous or complicated at all. It's about as simple as…

The entire point of this is that I don't want to deal with non-standard port numbers or bouncing through hosts. I want to be able to host services in the normal boring way, and this approach lets me do that without needing to worry about dynamic DNS updates whenever my public IP changes.

Re: Locally hosting an internet-connected server

#92
I do something similar but using GRE since I don't need encryption. Then I have OSPF on the resulting overlay network (there are several sites) to deal with ISP outages. One hop is via Starlink and that does use Wireguard because Elon likes to block tunnel packets but we gets through.

Re: Locally hosting an internet-connected server

#93
post #89
post #72

Earlier quoted context omitted.

I don't know what you mean by "the protocol". There is a destination IP address on every packet... getsockname() will tell the proxy which local IP the client dialed, allowing it to create "virtual hosts" (or you can actually run multiple proxies bound on different local addresses).

I have one public IP address. I have three machines behind it that I want to SSH into. How does the machine with the public address know where to route an incoming port 22 packet? For HTTPS this is easy - browsers send the desired site in the SNI field of the TLS handshake, so the frontend can look at that and route appropriately. For SSH there's no indication of which host the packet is intended for.

Well you can't, but that wouldn't work with routing either, and it is not the situation at hand: in the article there are multiple IPs on the VPS:

> you now have multiple real-world IP addresses that people can get to

In your new situation that is not the one in the article, you can just use different ports.

Re: Locally hosting an internet-connected server

#95
post #29

This and the comments highlight how bad many ISPs in North America and Western Europe are at IPv6, still , in 2025, and the lengths to which people will go to treat that as damage and literally route around it. One of the biggest ISPs in my country has been promising IPv6 since 2016. Another, smaller, competitor, advertised on "World IPv6 Day" in 2011 that it was way ahead of the competition on supplying IPv6; but in…

Once again I voice the only sane option: Skip IPv6 and the insanity that it is, and do IPv8 and simply double (or quadruple) the address space without introducing other new things.

That is not a sane option. IPv6 isn't actually that hard, companies are just lazy and refuse to implement it (or implement it correctly).

Re: Locally hosting an internet-connected server

#97
post #4

Earlier quoted context omitted.

I have multiple devices on my internal network that I want to exist outside, and dynamic DNS is only going to let me expose one of them

Yes, that's how it works when you only have a single IP. The standard way to deal with this is a reverse proxy for web requests. Other services require different workarounds. I have a port 22 SSH server for git activities, and another on a different port that acts as a gateway. From that machine I can SSH again to anywhere within my local network. It's really not onerous or complicated at all. It's about as simple as…

Same for me, I actually like having a reverse proxy as a single point of entry for all my web services. I also run OpenVPN on 443 using the port share feature and as a result I only need one IP address and one open port for everything.

Re: Locally hosting an internet-connected server

#98
post #69

This article was not worth having to solve a captcha to read. I think I will be done with sites that require me to solve captchas to visit for simple reading, just as I am done with sites that require me to run javascript to read their text.

how do you feel about proof of work human detection mechanisms? I think those are more tolerable given that it's just a short pause in browsing.

Re: Locally hosting an internet-connected server

#99
post #96

Why would you want to expose your IP to the internet? I still feel that's dangerous, susceptible to DDoS attack, and I avoid that as much as possible. I put everything behind a Tailscale for internal use and behind Cloudflare for external use.

What the heck? That's like not wanting a street address because people might come to block your front door somehow, or burglars might find your building and steal from it. The big brothers you mention would be like gated/walled communities in this analogy I guess

Saying this as someone who's hosted from at home for like 15 years

Also realise that you're sending the IP address to every website you visit, and in most VoIP software, to those you call. Or if you use a VPN 24/7 on all devices, then it's the VPN's IP address in place of the ISP's IP address...

Re: Locally hosting an internet-connected server

#100
post #70
post #68

> Let's say the external IP address you're going to use for that machine is 321.985.520.309 and the wireguard address of your local system is 867.420.696.005. What is going on here with these addresses? I'm used to seeing stuff like this in movies – where it always destroys my immersion because now I have to think about the clueless person who did the computer visuals – but surely this author knows about IPv4 address…

The author did not want to use real addresses and was not aware of the 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 ranges specified in RFC 5737 - IPv4 Address Blocks Reserved for Documentation.

TIL!!!
Post reply on HN