It’s recommended to read my new post: Why I Switch From Netbird to Tailscale.
Recently, I am introducing a change to the cloud infrastructure of myself. That is, installing NetBird on all my servers and change firewall configuration to ensure some essential services can only be visited by trusted devices. So, why did I this, and what’s the problem it can resolve?
Long existing problem
For a very long period of time, I am exposing my services’ ports directly to the Internet. To avoid MITM (Man-in-the-middle attack) and other kinds of security threats, I choose to use forced TLS encryption connection for my database instances and access some services use SSH tunnel instead of expose them. Moreover, I really like ufw and use it to limit SSH connection attempts. However, with the number of services goes larger and larger, I felt it’s a burden for me to manage all the certificates (although there is auto-renewal mechanism). And it obviously is far from best practice.
What’s more, I have a NAS hosted around one thousand kilometers away from me. And I use IPv6 to access it. If there is anything goes wrong with DDNS, I could not know the address of that machine. It’s a single point of failure.
NetBird
NetBird is generally a service for managing your WireGuard VPN’s secret and provide some user-friendly ways to control your network.
They provide some APIs to authenticate and issue VPN connection configuration like key pair and peers’ information. If you are interested in how it really works when a NetBird client goes online, you could see: General Flow Overview.
After setting up all clients, your network may look like this:
And every server will own a IPv4 address in 100.64.0.0/10. If both sides have public addresses or are in a same local network, they can use P2P connection. Otherwise, NetBird could offer a relay service when P2P connection is not possible. What’s more interesting, they released a new feature named network routes. Let me use a list to illustrate how it works.
- Create a route with specified CIDR of your private network and routing node.
- NetBird client will add an entry in all servers’ route table, let all traffic send to the target CIDR goes to the NetBird’s network interface.
- Traffic is redirected to the selected routing node.
- The routing node will replace the IP address of the received package with its IP address in the private network. And send the package to the target IP address.
- After received the response, things are quite similar. But the direction is opposite.
You can also disable masquerade to make your NetBird network transparent to your private network. But you should add route manually on the servers in your private network. Otherwise, the server does not know which route it can send the package back. The default gateway does not work. For more information, please check Routing Traffic to Private Networks.
*: Images are from the official NetBird document. The GitHub repository is at netbirdio/docs.
Better network
So now, I can use the Web UI to check the IP address and status of my nodes. I can also add ufw rules like this:
|
|
The 80 port could only be visited within the NetBird network. As the connection itself is encrypted, we are no longer need to use TLS. :)
I am looking forward to share more things with you, see you later.