OS X 10.6.8 direct IP translation and DNS issues

Question

This is the situation:

I have a web server on my LAN that serves up beta versions of my documentation for my free software.

This web server, via my router, responds to an external IP address. Imaginary IPs for the purpose of explanation:

• My web server is on my LAN at 192.168.10.100
• My WAN static IP is 200.100.50.25

Externally, DNS is not set up so that some name resolves to 200.100.50.25. Nor will it be. So you can't get there the usual way.

So, I provide URLs to my beta testers in this form:

http://200.100.50.25/mybetadocs/webpage.html

This works fine. My testers out in the world can get to my server and all is good. For them.

Here's the problem: on my machine, if I try to get to that URL, for instance, when I click on a link on a web page that contains it, my machine tells the router to NAT to 200.100.50.25, and that's the end of that - it goes nowhere.

The router does not appear to have any loopback capability to let it know that indeed, 200.100.50.25 is, in fact, on my LAN (although frankly, I think it should know that already, since that's its external IP and that's where I'm trying to get to. It used to work fine on my old router. But anyway.)

So what I'm looking for is a way to tell OS X here on my local machine that when I reach out to 200.100.50.25, I'm actually trying to reach 192.168.10.100 so that my web server will respond to me here on my machine, directly via the LAN.

---

Simply put, on my machine only, I need the following,...

http://200.100.50.25/mybetadocs/webpage.html

...to reach here:

http://192.168.10.100/mybetadocs/webpage.html

---

Previously, I had my users set up a hosts file entry for an imaginary servername of the form someweirdname.com, like this...

200.100.50.25 someweirdname.com

...and then put all my links up in the form...

http://someweirdname.com/mybetadocs/webpage.html

...which actually works fine, but ran into a fairly severe user problem where setting up a hosts file was completely beyond them, hence no access to the docs.

Using the IP requires nothing of the user but clicking the link, and as I said, it works fine for them. But it locks me out, which is highly inconvenient for me - I can't follow URLs out on other web servers back to various places in my beta docs without dragging out my cellphone, turning off its access to wifi, and going after those links via 4G so my router sees the request coming in from outside the LAN.

When I'm just reading my docs here, I just use someweirdname.com to get to them, and it's all relative from there, and that works fine too.

I just can't to them from other server's web pages out on the net. And for... reasons... I need to test those URLs to make sure they go where they are supposed to go.

Is there a solution for this conundrum that doesn't involve buying yet another servername, costing me yet more money to expose my local beta docs, and dealing with the resulting DNS maintainance churn?

I can live with it as it is, and have been, but I hate it.

Answer 1

Arpanet: At Work Since 1969 - editing your own hosts file is the method of choice.

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

->

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
192.168.10.100  someweirdname.com www.someweirdname.com
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0     localhost

You might have to flush the DNS cache using sudo killall -HUP mDNSResponder and sudo dscacheutil -flushcache.

Answer 2

Your only hope to me seems to make a static route on your Machine to have 200.100.50.25 routed to 192.168.10.100 but I'm guessing that won't work without some network trickery on the web server side to actually listen to the packets instead of routing them on to the router that has issues on your client.

In the interim, you might try setting up a free dynamic DNS service to associate 200.100.50.25 with a host name that will resolve for all your external testers to the IP you choose for the server.

Then you can avail yourself of the normal editing of /etc/hosts trickery to have that name resolve to your choice of internal IP rather than going to the DNS servers in general.

Basically move away from hard coding the IP address into the URL and use a name that you can override more easily.

Answer 3

It's not the ideal solution and doesn't solve any of the actual problems per se, but if all you want is to leave everything as is and have a way to test the links, you could initiate a VPN connection. At that point, you should be able to hit your public IP from outside and port forwarding will work the way you want it to.