How to Use Synology NAS for NAT Traversal

I have a Synology DS918+, no RAM upgrades, only the standard 4G, and it’s currently at 50% RAM on standby, with the CPU usually at 5% or less. The hard disks are 4 x 4TB RAID5 and are currently at 45%.

These are the services I use most often in Synology:

Cloud Sync: for cloud drive synchronization.
Synology Drive: Synology Drive comes with Synology’s own synchronization disk, replacing the MEGA that I’ve been using for years.
WebDAV Server: an easy protocol for all kinds of cell phones, tablets, TV boxes and other players to read video resources.
Surveillance Station: the home of the little ant camera video storage playback, live!
Docker: some commonly used self-hosted services, such as Nginx, DDNS, Bitwarden, Memos, etc., is also the core application of my intranet penetration program.

Cloud Sync

This is a built-in application that can sync NAS disk files to cloud storage services such as One Drive, and supports two-way synchronization.

Synology Drive

Before using Synology Drive, I was using MEGA, which I often use to synchronize data between multiple computers for work. Occasionally, when I send a large file to someone, since all the recent data is stored in MEGA, I can just use MEGA’s sharing function, create a sharing link, enable visitor’s permission, and the other party can download it at full speed, and it saves me the time of uploading it individually every time. It can basically be used as a backup disk at the same time. Previously, MEGA had less than 100GB of space and could only be used for synchronization.

WebDAV Server

This is my primary protocol for sharing Synology Drive content. Since intranet sharing under Windows and Android usually uses SMB protocol, and Apple series hardware uses NFS, but it is not usually used for extranet. Therefore, in order to standardize the protocol and security, and to make it easier for each software to have a consistent access experience in various network environments, I chose the WebDAV service.

With Nginx’s reverse proxy, I only need to set up a second-level domain name such as https://webdav.mydomain.com:81 in the hardware, and then I can access the movie sources or materials in the NAS in various player applications at any time.

Surveillance Station

Using Surveillance Station was purely by accident. The app is not completely free in Synology, but has two free credits, but I have enough to use it, since I only have one camera in my house. The function of the app is to interface with a camera that uses rtmp protocol to push streaming, and solve the function of live streaming, recording, and watching playback from the camera.

Don’t all home webcams nowadays have these basic features? Yes, but that kind of webcam probably has several disadvantages as follows:

Latency: since the data goes through the manufacturer’s servers, there is a high latency for both live and playback speeds compared to intranet transmission;

Privacy: I’m not really big on privacy of personal information, but the only webcam in my home may expose more than just my personal data, so I’d like it to operate locally;

Cost: Cloud storage for webcams basically costs a fee and gives very little space, the data is stored in GroupHub and I can even see footage from a year ago;

Functionality: Since it is a commercial software, the overall functionality is not worse than other home platforms, and my webcam is a first-generation ant, which originally had a single function, but after brushing, many automatic monitoring functions can be realized through this software.

Perhaps because of privacy, those who have not used a webcam in their home will wonder where the point of need for such a product really lies. For my family, the webcam placed in the living room is played back very often, and every time it is a critical time to play a role. I set the record 30 days, usually used to find things basically enough, currently occupies 176GB. through the intranet to view the playback is very silky smooth, 4 times the speed of 16 times the speed can really do like a traditional closed-circuit surveillance system.

Docker

Docker deserves its own section. Since Docker alone hosts 5 services, I’ll talk about the 3 most commonly used ones.

Bitwarden
This open source password management tool was deployed when I switched my primary browser from Chrome to Arc. Because of Arc’s riddling user synchronization, I didn’t dare to migrate my accounts and passwords over. So I decided to go with a free and easy-to-use cross-platform solution, Bitwarden.

Initially I didn’t host it myself, but used the official server, but when the software was loaded or operated, the whole operation was always stuttering due to server latency. Later I found an open source server rewritten in rust by the community (the official server consumes a lot of resources), which can be hosted on a low-cost hardware platform, and the lag problem was solved after I tried it. Currently it is the main password management tool.

Nginx proxy manager
Whenever I use Nginx, I prefer to deploy this project. Compared to native Nginx’s confusing configuration files, this project’s webui is easy to use for the average person with little to no instructions.

For those of you who don’t know Nginx, here’s a quick explanation: Nginx is usually an entry point for a domain name to point to a directory of its own website, or to another website on its own or on an intranet (a reverse proxy) when the server builds a website. It is an entry point software, along with the open source Apache and Microsoft’s IIS.

DDNS-go

This last one is important and essential when doing intranet penetration. Since the IP of your home broadband changes every time you reconnect, when we access resources at home on the public network, we can’t re-query the IP every time to connect, but rather, we can connect through the domain name, with the IP behind the domain name. This tool allows you to update the IP behind your domain name every time you disconnect and reconnect.

If you apply for a domain name that you only use at home, then you only need to update a wildcard domain name like *.mydomain.com in DDNS, so that every time you use a new second-level domain name, you can use it directly, and you don’t need to add them one by one like I did here.

Extranet Access Programs

Since my broadband has a public IP, there are many options for exposing services to the public network, if you are not sure about this, you can go back and read this article about the importance of public IP. As some of you may have guessed from the project I deployed above, I used a secondary domain name + reverse proxy + DDNS approach, and since my carrier doesn’t allow home broadband to use ports 80 and 443, I used port 81 of the public network instead of https port 443 for access.

At the same time, because nginx just proxy http traffic is more convenient, although tcp/udp traffic can also be forwarded, but not as direct as the router, this kind of traffic may increase the latency if more circles. In addition, I turned on a VPN server in the router as a backup solution for temporary access to devices on the intranet that are not publicly exposed.

The advantages of this solution are as follows:

Prioritizes the use of common open-source software or protocols, which is stable, secure, and does not require third-party tools when penetrating the intranet, especially L2TP VPN, which is natively supported by Apple’s full bucket;

The use of domain names and unified port 81 forwarding various intranet services to facilitate my memory, and the use of Nginx open source project with a UI interface is very convenient for unified management;

Some http-based intranet services, after Nginx https proxy, access to more convenient, you can avoid some browsers suggest that the page is not secure.

Take an example. Let’s say I want to expose Bitwarden service to the public network, here’s how to do it:

First, create a new container of Bitwarden in Docker of Synology, after success, for example, the address of the intranet is http://10.0.0.249:3011.

Then go to the Nginx Proxy Manager admin panel and add a reverse proxy rule so that the domain name https://bitwarden.example.com points to http://10.0.0.249:3011 on the intranet, and at the same time automatically apply for a free SSL certificate.

Finally, go to DDNSgo administration and add Bitwarden.example.com to the list, keeping the IP up-to-date at all times. After a few moments of domain name resolution, you can access it via domain name + port 81. By the way, don’t forget to map your port 81 to port 443 of the Nginx service in your router.

Some people say that the more ports you have open, the more vulnerable you are. This seems to be the case, but actually exposing only port 81 like I did and then publicizing the service through a reverse proxy is the same as exposing multiple ports. It’s just that the ports can be scanned and the domain name may be guessed by a social worker or blown up.

So it’s not the more ports you expose the less secure you are, it’s how many services you expose to the public network. The attacker is always going to get inside one of your services through the latest vulnerability in that service, or a weak password, get some information under that service, like some passwords, and then infiltrate some of your other services. Because docker or some other services, the application permissions are isolated from each other, nowadays there is rarely a situation where the service falls and the server is infiltrated, unless you like to use the same password, but also be guessed to a different entrance.

Or your router (usually a soft route with complex functions) is invaded, the attacker has the gateway privileges, through the capture of packets to unpack the packet to change the packet attack, then the entire intranet will be infiltrated.

It seems like it would be easy to be attacked, but in fact your probability of being attacked is extremely low:

An application usually does not have vulnerabilities, and even if it does, they are rarely hacked or even privacy related;

An attacker’s attack on an ordinary user is usually a faceted scan, a scan of thousands of IPs together, such as a vulnerability in an application that usually uses port 8989, which you know how to map, you do not necessarily use when exposing your service to the public network, and the version you use does not necessarily have the vulnerability;

Even if the attacker did get important permissions, the probability of the average user being spied on is extremely small, and is usually used as a botnet.

If you have a public IP address, the attacker can barely achieve this, otherwise you have no chance to expose the port to the public network. All of these types of attacks are not as likely as you downloading software from the Internet and running it. If you’re still worried about your service being attacked, doing the following suggestions will, probabilistically, virtually eliminate being mistakenly hacked:

Try to use different passwords for accounts, no matter what type of service you use;

For open source projects, choose those with a large number of users, and for commercial software, try to choose those from large vendors and keep them up to date;

For hosted applications where the configuration can be modified, try not to use the official default port numbers or paths, usernames, and so on;

That is all you need to use Synology NAS for NAT Traversal.

Posted on May 30, 2024 uninstalledly editor