SOCKS vs NAT (by alaric)
The standard solution these days to the problem of a large internal network of client machines that need Internet access is to stock them behind a NAT, with a single external IP from which connections can originate.
However, before NAT was popular, I remember setting up SOCKS proxies, which did more or less the same thing.
The downside was that not all applications supported SOCKS, and annoyingly there generally wasn't an easy way of telling the whole machine to use SOCKS; each application had to be configured manually, while NAT works by providing the illusion of real Internet access.
The upside, however, is that SOCKS doesn't work by fooling anyone. The application knows that the IP address it gets from the local stack is not necessarily global, and can ask the SOCKS server what the global address is. And the application can ask for a listening socket, making peer to peer file transfers and the like work properly.
Perhaps rather than using NAT for more and more, we ought to be putting support for SOCKS right into the IP stacks of operating systems, so applications using the standard TCP/IP APIs work with SOCKS right out of the box, and specifying a DHCP option so a DHCP server can nominate a SOCKS server to a client machine?
Then we wouldn't have all this pain with peer-to-peer file transfers...
Sat 24th Dec 2005 1:55 am 2 Comments
Other Links to this Post
RSS feed for comments on this post. TrackBack URI
Subscribe
By andyjpb, Sat 24th Dec 2005 @ 1:08 pm
I've always thought that this was a good idea. I even set up a web proxy server at home. OK, it's not a SOCKS proxy, but it's along the same lines. As for peer to peer file transfers, as usual, rather than fix these things, vendors tend just to work around them despite there being a perfectly good fix available (SOCKS for example). File transfer in MSN Messenger now appears to work between two users who are both behind NAT routers. Currently, SIP is allegedly a bit more difficult when you're behind NAT but I've never had any major problems however, I do employ STUN rather than plain old SIP. SOCKS also gives you advantages over NAT as far as user authentication, etc, etc goes (I think). OK, you can bodge it with NAT too, but it's just that: a bodge. With SOCKS you can restrict which external services a user can access based on user id rather than source IP address.
By Seth, Tue 27th Dec 2005 @ 7:13 pm
Of course, we all know that the real solution is IPv6 :-p