Live data from Hacker News

Internet centralization and the original sin of NAT

dreamstation.systems

91–100 of 197 posts

Re: Internet centralization and the original sin of NAT

#91
post #85

NATs are also firewalls. I think people forget that before NATs, when you would install Windows, the minute you connected it to the internet, you had to rush to update it before a virus would infect it. The OS of the 90s weren't secure enough to be exposed to the WAN.

NATs are not firewalls. Any firewall-like functionality provided by NAT is entirely accidental and better provides by an actual NAT.

Re: Internet centralization and the original sin of NAT

#93
post #39
post #17

Earlier quoted context omitted.

I'm using tailscale to tunnel from an hetzner vm to my home, so that the vm can use my home connection for certain traffic. Traverses NAT and GNAT. It just works: connect devices and they immediately show up in their portal. Most config is just clicking, but more advanced things can be configured as well. Definitely feels like a high quality product, not just something thrown together by a developer that learned a fe…

>"that the vm can use my home connection for certain traffic. " Huh. Why are you doing this, is the datacenter IP being (rightfully) blocked by some service to avoid abuse? Is your usecase breaking some services ToS? Certainly adding more fire to the "never a GOOD reason to use this" thesis

> Certainly

So you make up reasons to be judgemental and then insist they're right?

It's practical to block entire datacenters. It's not so "right" that working around it becomes "wrong". If whatever the server's doing can fit through a single home connection then it's probably fine.

I'll give you a concrete use case: A few times a month I want to wget a file on imgur to my server. That's a valid action miles away from any kind of abuse, but the IP range is blocked so I use my desktop to do it. If I routed it over tailscale instead that would be equally valid.

Re: Internet centralization and the original sin of NAT

#94
post #47

> There’s lots of things you can blame for killing the open Internet, but I think NAT was one of the earliest. Running a server used to be trivial: run an executable, tell people your address, done... It also trained everyone to think client‐server is natural. “My device talks to The Cloud which talks to other devices” feels normal, when that feeling originated as an artifact of address scarcity. A lot of this feels…

> Running a server used to be trivial: run an executable, tell people your address, done... This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, triv…

> most of the time they are unwanted users trying to break in.

Exactly. Of all the reasons why the average person doesn't have an Internet-visible server, NAT, I would say, is pretty far down on the list.

Re: Internet centralization and the original sin of NAT

#95

The designers of the internet made one fundamental mistake, namely applying meatspace norms to cyberspace. In the "real world", you don't really need that much security. Your actual security comes from the fact that all the worst criminals are already locked up, most of the would-be criminals are afraid of being locked up, and if somebody does actually commit a crime, they will get locked up and won't be able to do i…

Uhh... you can have a firewall without NAT, including one at the perimeter.

This is a very common misunderstanding. NAT and firewalls are separate concepts. You can also have NAT with no meaningful firewall -- a port remapping NAT that allows anything through.

Most IPv6 networks are firewalled but there's no NAT.

Re: Internet centralization and the original sin of NAT

#96
post #74
post #43

Earlier quoted context omitted.

The fact that it's a VPN is also pretty important, despite the utility of it also dealing with NAT headaches for you. The main selling point is acting as a relatively efficient private overlay network, giving you a consistent private network even as devices move between different internet connections. (Something that NAT makes a bit harder but you don't get for free even if NAT isn't a factor)

I see it now, it's a bundle of both the practical and security aspects. I think the security aspects serve mostly as a marketing tool, potentially serving users who truly need a VPN. But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing)…

This use case you have in mind where someone has a fixed server and uses tailscale to patch over the lack of IP, I think is a very rare use case.

Re: Internet centralization and the original sin of NAT

#97
post #8

I remember times before NAT and SSL You could share things easily, sure, but anyone could get hacked pretty easily and very targetted. After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely…

Firewalls, both at the perimeter and locally, was what patched over this. NAT had nothing to do with it.

You can have firewalls with no NAT just fine. You can also have NAT with no firewall.

NAT is not about security and never was. It's about stretching the IPv4 supply and allowing each endpoint to just get one precious V4 IP.

Re: Internet centralization and the original sin of NAT

#98
post #85

NATs are also firewalls. I think people forget that before NATs, when you would install Windows, the minute you connected it to the internet, you had to rush to update it before a virus would infect it. The OS of the 90s weren't secure enough to be exposed to the WAN.

Windows wasn't secure enough.

I ran Linux, *BSD, and Solaris systems for years without any firewalls, host or otherwise.

Re: Internet centralization and the original sin of NAT

#99
post #9
post #8

I remember times before NAT and SSL You could share things easily, sure, but anyone could get hacked pretty easily and very targetted. After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely…

It brings the requirement for a firewall on every endpoint with a unique address. My Phone often has an ipv6 address (found out this holiday wen I couldn't resolve one of sites because of an orphan ipv6 entry nobody noticed), and has little problems. Perhaps there is also "firewalling" on the router and the phone can't even have incoming connections. Not sure. In any case, the phone seems to do fine.

[deleted]

Re: Internet centralization and the original sin of NAT

#100

The consequences are so much more significant than people seem to realize. Because of NAT, hierarchy (centralized servers) is the foundational design pattern of the internet, and anyone who wants any semblance of anarchy (decentralized networks) must use a workaround that is itself hierarchical and costly. We are all interconnected, but only a wealthy few can truly speak fist.

while i agree with your sentiment, i personally think that the foundational design pattern of the internet as a network is highly decentralized. once you get public IP space and the infrastructure required to talk BGP, making decentralized designs is actually quite easy.

The issue that ipv4 exhausting and "solutions" around it like NAT are making it very hard for actual users (bussiness, people etc) to get access to public IP space without strings attached.

IPv6 solves a lot of this, especially because IP space is so massive LIR's don't need to be so spare with giving out address space.

The far larger issue we have is that applications are ingrained in a client server mindset, in which big incumbents want to have this architecture because it forces control from the server towards to client. And control usually also means having the data itself, which is where the real value lies.

Post reply on HN