Tailscale follow-up: Run with QNAP & access control with ACL & Internet connection encryption

Set ACL, which is an access control function

ACL is an access control function that is required when using tailscale in an organization or sharing a machine with an external user. is.

In tailscale, the standard setting allows communication with machines belonging to the same organization, and by turning off (unchecking) "Allow Incoming Connections" in the client application, the connection to that machine is denied. It is a mechanism that can be done.

Usually, access control is possible with this function alone, but by using ACL, even more detailed control becomes possible.

For example, you could do something like this:

The above diagram is an example of a simple ACL configuration. The left side shows inside the company and the right side shows outside the company, and access to "nas01" is controlled with different access control settings for each user.

The company consists of two groups, one for the region called "tokyo" and the other for the job type called "manager", and different access rights are set for each.

Specifically, the user above can access all ports on all machines, not just nas01, as permitted by the manager group, but the user below only belongs to the tokyo group. nas01 can only be accessed through two ports, 80 and 5000.

The ACL for such group access control is described as shown in the same color in the figure.

{ "Action": "accept", "Users": ["group:manager"], "Ports": ["*:*"] }, { "Action": "accept", " Users": ["group:tokyo"], "Ports": ["nas01:80,5000"] },

"manager" is "Ports": ["*: *"]", so all ports can be accessed regardless of the machine, but "tokyo" is "Ports": ["nas01:80,5000", so only port 80 and port 5000 of nas01 can be accessed.

As you can see, tailscale's ACL allows you to divide users into groups and restrict the machines and ports that can be accessed by each group (it can also be set for each user).

Next, let's take a look at the external user control on the right side of the diagram.

Access is controlled by the description in the blue part above.

{ "Action": "accept", "Users": ["autogroup:shared"], "Ports": ["tag:public:7001"]}

< p> Here we use the concept of autogroups. As the name suggests, it is a group whose members can be dynamically configured, and the "shared" used here indicates the address of an external user who selects a machine on tailscale and shares the connection.

In this way, every time you share a machine, the user you share with will automatically be registered in the "shared" group, so you don't have to worry about rewriting the ACL every time you share with more people. .

In addition, the machine to be shared is also specified by the tag ""Ports": ["tag:public:7001"]" instead of individual machine names.

This tag can be set for each machine, and can be used by adding the following tag when starting tailscale on the machine side.

sudo tailscale up --advertise-tags=tag:public

By tagging and managing each machine like this, only internal users can use it It is possible to make a clear distinction between machines that are open to the public and machines that are open

Of course, if there are too many tags, management will be complicated, so each tag needs an owner. That is the "TagOwners" part described in red in the ACL in the above figure. In other words, only specific users within the company can set tags.

"TagOwners": {// manager allowed to tag servers as public "tag:public": [ "group:manager", ],

With these features, Tailscale allows complex access control to machines. Specifically, the following access controls are possible, and these can be combined.

For example, when creating a website, allow only "443" for customers to check the content, allow only API access for developers, allow only game ports, etc. Enjoy multiplayer and share a VPN connection using only ports that are open to specific users. One of the attractions of tailscale is that such flexible settings are possible.