Part 1 | New Toy During COVID-19
Almost a month ago, I have an idea that I need to build a mini server, learn some electronics (learn electronics component, how it works, other stuff), and IoT implementation. Since I’m an IT guy, the server part is the most interesting part. Later, an idea came to build NAS or file-sharing service. The file-sharing service must be “publicly available” and secure enough so that I (the only user) can access it anywhere. There is a lot of online platforms like Google Drive, Dropbox, Mediafire, MEGA, and another file-hosting service out there, but I interested to build my own.
Later, I bought Raspberry 4 Model B, and using the old internal HDD that I’d purchased long ago, I started building the server. Using the default OS (Raspberry Pi OS, they call it Raspbian back then), I install Samba 4 and SFTP server. Installing SMB actually, not part of the plan since Windows Explorer has third-party add-ons named Swish where you can access SFTP server directly without installing third-party apps like Filezilla. But, I found out that it would be good if I do a performance benchmark to compare SFTP and SMB protocol for my fun project later using iperf and minimize the number of software installed on my Windows.
After the server installation is successful and worked on my local computer. I need to address the challenge of how to access it in case I’m in the office or somewhere else and I need to retrieve the data from my computer. I need to access it publicly, without dedicated static public IP, secure enough and didn’t consume much resources on the server.
OpenVPN to the Rescue
I have a VPN server that I deployed in Singapore long ago. It would be nice if I can set the VPN server as the router for “not too public file-sharing service” beside the VPN purpose. Since the VPN server already supports IPv4 packet forwarding, it should be not too much configuration to support this architecture. The only thing that I need to do is activate the firewall to filter the inbound traffic.
The service is available “online”, “secure enough”, and works for me. I’m able to connect to the server, copy the files inside the HDD, act as bastion host (some people call it jumpbox) to my PC inside the house, monitoring my room, do another stuff remotely. I tried to retrieve some configuration files and packages and everything went smoothly. At that time I’m quite happy and satisfied with the implementation.
Huge files come along and the download speed is terrible. Even sloth metabolism is faster than this. We need to solve this problem, no way I’m gonna use this service with this speed. I’m not impressed and this is embarrassing.
Two days later I need to copy files from my laptop (Xiaomi Notebook Air 2019) in my boarding house to my computer at the office. I thought the process and the performance are good as the previous test.
[CHECKED] Connect to the VPN
[CHECKED] Able to ping and access the server
[CHECKED] Initiate the file transfer
[…………..] Downloading files from the server
The files that I’m going to copy are about 1GB and it consists of many files. Huge files come along and the download speed is terrible. Even sloth metabolism is faster than this. We need to solve this problem, no way I’m gonna use this service at this speed. I’m not impressed and this is embarrassing.
DDNS with ACL
With this model, I still connected to the VPN server. The difference is the Raspberry Pi didn’t need to connect to the VPN. Register Dynamic DNS (DDNS), install the DUC (Dynamic Update Client) in the Raspberry Pi, and set it up at my router. Now you have a domain name that points to your dynamic public IP server and you can forget about the dedicated public IP things.
Using this model, the performance is better than the previous model since there is less hop on the VPN side. The previous one using the VPN server 2 times, in this case only 1 and it came from the client-side only. The performance relies on the VPN and client download/upload speed.
Why do we need to connect to the VPN then?
That’s true we can skip the VPN connection to directly access the server using the new domain name, but that means the router will receive all traffic without any filtering. All traffic that sent to the domain will be received and processed by the server. A big no from the security point of view.
To overcome this, I need a dedicated IP from the client-side and register it to the router. That means every traffic sent from this dedicated IP will be received and the other will be dropped. Using this policy I easily control the traffic to my Raspberry Pi.
Have you restart your modem first?
Improvement
Now the transfer rate and reliability are better and I satisfied again with this model. But that doesn’t mean this model didn’t have a weakness whatsoever. This model still has a weakness though, not a weakness actually more likely a tradeoff. Since the filtering is done in the router to check the network packet stream to the Raspberry Pi, it will torture the router resources to do the packet inspection. The solution is to replace the router with a better one (we can replace it with the MikroTik CCR series or CISCO ISR series, but right now I didn’t feel any problem on the router resources and seems fine). There is another solutions that work right now without replacing the router though. Yep, that restart button on the modem. That button created is not for nothing, that’s the last resort solution.
Follow the series to know what kind of implementation that I’d implement to my Raspberry Pi. A lot of things like Spotify connect daemon (can you see there is a speaker 3.5mm jack attached to the Pi board?), resource monitoring and alerting system on the board, notification system in case the FUP is near (Indihome user, you rang?), and many other things.
