When I first bought a NAS for file backup and sharing, it didn’t offer much beyond just file sharing. Later, it got a light web server feature, which allowed for automatic installations of WordPress and such. A few years back, it even added the ability to upload images to Docker. For a small startup, this could be enough to run email services, back office, and a website all with one device, right? Even if you’re not running a startup, this might spark some interest if you’re a bit bored, like me…
If it’s a system used just by you at home, you can easily use the features provided by NAS without much hassle. However, if you’re looking to set up externally connected services, like running a blog, you’ll find it challenging without some basic network knowledge. Sure, you can search the internet to solve any issues you face, but when it’s time to change or expand the structure, you might find yourself back at square one. So, for those who share a similar hobby as mine, I thought I’d explain how network services work in a simpler way. More specifically,
An explanation of the network structure for accessing Docker services (websites) on your home NAS via a domain name from outside.
Let’s dive in! 🚀
First, let’s assume I have a domain. This domain name would be linked to my public IP via a nameserver service. Then, access to the service uploaded to Docker would follow the path below:
When a user enters the URL (the domain linked to the service on Docker) in their browser, it finds my public IP via the nameserver and requests the service. Since it’s a standard web service, it’ll call on port 80, right? The first thing it encounters is my router. The router then needs to connect the user’s request to the server that can fulfill it. The outside of the router is external, and the inside is internal, with these two networks existing independently. The router connects them, handling the entire setup of my internal home network. Because the networks are separate, external users can’t know or access the NAS’s internal IP. That’s where the router steps in as the mediator. 🔄
Port Forwarding: In computer networking, it is an application of network address translation (NAT) that redirects a communication request from one IP address and port number combination to another, while the packet crosses a router or firewall gateway.Wikipedia: Port Forwarding
This is the definition from Wikipedia, but simply put, it forwards the signal to the side (the server) that can handle the user’s request. Once the signal is delivered to the NAS, the NAS needs to pass the request to a specific Docker internally.
Reverse Proxy: A type of proxy server that retrieves resources on behalf of a client from one or more servers in a computer network. These resources are then returned to the client as if they originated from the web server itself. Unlike a forward proxy, which acts as an intermediary for clients to connect to arbitrary servers, a reverse proxy is an intermediary for servers to allow clients to connect to them.Wikipedia: Reverse Proxy
When the NAS forwards requests to specific Docker services internally, it uses a reverse proxy. The explanation is a bit complex, but before we dive into reverse proxies, let’s talk about forward proxies (commonly referred to simply as proxies). A forward proxy intercepts user requests and fetches the desired items. It’s like using an errand runner when you want to buy apples from store A. This way, the user doesn’t need to go to store A themselves—no need to appear on the store’s CCTV either! Proxy servers might even stock up on apples if many users request them from store A. This means you could get your apples a bit faster. CDN services also use this basic structure, even though they employ much more complex techniques.
So what is a reverse proxy? Imagine the user thinks the reverse proxy server is store A and makes a request. The proxy server knows where to buy apples (the server) and requests them, delivering to the user. It’s a simplified explanation, so if you want to learn more, I recommend searching the term in detail.
Let’s redraw the diagram.
In fact, NAS is a product name, and within it, both the reverse proxy server (service) and Docker service are running. With the latest NAS models, you practically have AWS services in the palm of your hand, even if you’re not interested… 😅
Now, let’s talk about how to set everything up step by step, starting with the router. As discussed earlier, when a domain is called, it requests through port 80 for web services, hitting the router first. The router then needs to forward the request to the reverse proxy server. To make this clearer, let’s set it up. 🛠️
- Domain: domain.com
- Public IP linked to domain: 1.1.1.1
- Internal IP of NAS: 192.168.1.2
- Reverse Proxy Server Port: 80/443
- Docker Local Port: 8081
- Docker Container Port: 80
When a user enters the domain in their browser, it reaches the router on the default port 80. The router should then forward this request via port forwarding to the reverse proxy server. You can set the port forwarding to forward port 80 to the same port on the NAS’s IP of 192.168.1.2. (Also set up port 443 for SSL use.)
It might be easier to understand if you were connecting to a dedicated server just for reverse proxy instead of a NAS. NAS provides most services as part of its operating system, DSM (DiskStation Manager), making it a bit challenging to grasp the structure. If you think of DSM as a single web service, it might be clearer. The DSM web service is accessible via ports 80 and 443. So, the router forwards requests coming in on ports 80 and 443 directly to the NAS’s ports 80 and 443. This way, the DSM reverse proxy is set up to receive those requests.
Next is setting up the reverse proxy server. If you want to use another domain, say domain2.com, the two requests will both come in on port 80 of the same public IP (1.1.1.1). These requests will be passed to the reverse proxy server. At this point, the reverse proxy server needs to check the requesting domain, not the IP, to correctly connect to the appropriate Docker service. You need to input the hostnames (domains) and ports in the settings, specifying the target host (Docker, usually entered as localhost) and Docker’s local port. Once all this is set up, the requests will be delivered to Docker’s local port, and then again to the Docker-defined container port, which will create the pages to be delivered to the user efficiently.
By setting things up this way, you can offer individual web services connected to multiple domains within the performance limits of your NAS. You can easily operate by uploading services to Docker individually, and if you want to host multiple sites on one Docker web service, you can use virtual hosts within the Docker’s web server.
Actually, this is how centers run in companies as well. If there are many users, they might need to set up more robust, independent servers. However, for general manufacturing or startup introduction pages, where simultaneous users aren’t too many, this setup should suffice. Hardware has advanced significantly, making this feasible. Of course, for information protection or risk hedge perspectives, you should consider factors like redundancy or security solutions based on business characteristics.
I hope this summary has been helpful to those using NAS. 🙏🏻
Leave a Reply