Currently Being ModeratedJun 9, 2013 5:46 AM (in response to Hamish B.)
Some of the various options, and I've probably missed a couple.
- Get a gateway-firewall-NAT box (preferably one that's also VPN-server-capable) network device for the edge of your network.
- Configure port 80 and port 443 port-forwarding for any external sites.
- Configure an Apache virtual host ("site") on an alternate port.
The above works fine, though your local clients will have to specify the alternate port. Remote access requires added port forwarding or a VPN. Set-up mistakes in the configuration files can potentially mess up the production web server.
- Configure internal DNS with a DNS CNAME for the private site. Omit this in your external DNS.
- Configure Apache with the virtual host ("site").
- assume/hope/expect nobody outside your network configures their DNS for the same site, referencing your external IP.
The above works fine, though the local and any remote clients that need access will need to have the host name specified via /etc/hosts (not fond of that approach) or using their own local DNS translations, or via a VPN into the local network. Set-up mistakes can potentially mess up the production web server.
- Configure internal DNS with a DNS CNAME for the private site.
- configure Apache with the virtual host ("site").
- Edit the Apache configuration files to make the site password protected.
The above works fine, though the local and any remote clients will need the credentials. Remote clients will also need either /etc/hosts or their own local DNS modified, or a VPN into the local network Set-up mistakes can potentially mess up the production web server.
- Get a gateway-firewall box.
- Configure the production web server in a DMZ.
- Get a test server.
The above works just fine, though involves more hardware. Mistakes here usually won't mess up the production web server, short of messing up at the gateway-firewall box. Access to the test box can be controlled based on VPN or port-forwarding. Having the production server configured in a DMZ also has the benefit of (usually) containing breaches to that web server.
The usual sorts of confusions about this stuff can usually be resolved by understanding how the various pieces work:
Here's how DNS and virtual hosts interact. Here's how to set up DNS on your LAN. Here's why I prefer using a gateway firewall. There's other stuff posted there, too, including an overview of the basic concepts and components of IP networking.
And while it's true that DNS responses can specify a TCP port, but no web browser uses that.
FWIW, do not use .local as your local DNS domain for your server; don't mix DNS with multicast DNS (mDNS, Bonjour). Get your local DNS services on your LAN configured and verified and going, as a failure to have functional DNS tends to cause other services to have unexpected behaviours if/when/as you bring those services online.