使用 ACL 管理权限

发表于 分类于 阅读次数：

AI翻译，仅供参考

最后验证：Jan 5, 2026

Tailscale 现在使用 grants 来保护资源访问，这是一种新一代访问控制策略语法。Grants 提供了 所有原始 ACL 功能以及额外能力。

ACL 将 无限期继续运行；Tailscale 不会从产品中移除对第一代语法的支持。但是，Tailscale 建议 迁移到 grants，并对所有新的 tailnet 策略文件配置使用 grants，因为 ACL 不会获得任何新功能。

所有套餐均提供 ACL，但在某些套餐上 某些功能可能受限。

Tailscale 的 访问控制方法遵循 最小权限和 零信任原则。有两种方法可以为您的 tailnet 定义访问控制：访问控制列表 (ACL) 和 grants。两种方法都遵循默认拒绝原则，并在 tailnet 策略文件中使用 声明式 huJSON 语法定义。

ACL 代表了在 tailnet 中管理访问的传统 网络层方法，您可以定义 一组可以访问其他设备端口的设备或用户。您创建的每个 ACL 必须定义源和目标。它们让您可以精确定义 Tailscale 网络（称为 tailnet）上的用户和设备的访问控制。

1
2
3
4
5
6
7
8
9
{
  "acls": [
    {
      "action": "accept",
      "src": [ <list-of-sources> ], // 这些源（设备或用户）
      "dst": [ <destination>:<port> ], // 可以访问这些目的设备上的定义端口
    }
  ]
}

您可以使用 视觉策略编辑器 管理您的 tailnet 策略文件。请参阅 视觉编辑器参考 以获取使用视觉编辑器的指导。

首次创建 tailnet 时，默认 tailnet 策略文件 启用 tailnet 内所有设备之间的通信。您可以修改策略文件（包括 编辑 ACL）以满足您的需求。

ACL 是默认拒绝、定向、本地强制执行的，并且不影响本地网络流量。

  • 默认拒绝。使用默认拒绝策略可防止设备之间没有明确访问权限时进行通信。但是，如果 tailnet 策略文件中没有 acls 部分，Tailscale 将应用 默认允许所有策略。
  • 方向性. 允许源连接到目标并不意味着目标可以连接到源（除非策略明确允许）。
  • 本地强制执行. 设备根据分布到您的 tailnet 中所有设备的访问规则来强制执行传入连接。规则强制执行直接在每个设备上进行，无需 Tailscale 协调服务器的进一步参与。
  • ACL 不影响设备在其本地网络上可以访问或不能访问的内容。

有关 Tailscale 访问控制方法的更多信息，请参阅 RBAC 本应如此。

如果您未定义任何访问控制策略，Tailscale 将应用 默认允许所有 ACL 策略。要拒绝所有流量，请在您的 tailnet 策略文件中使用 empty object for the acls section。

编辑ACL

您可以通过管理控制台的 访问控制 页面、用于 Tailscale ACL 的 GitOps 或 Tailscale API 来编辑您的 tailnet 的访问规则。有关更多信息，请参阅 编辑 ACL。

请参考 tailnet 策略文件语法 创建访问控制策略，或参考 示例 ACL 了解常见策略的示例。

按计划可用性

所有方案均可使用 ACL，但某些功能可能受限于特定方案。

可用性 在 所有计划中 在 Premium 和 Enterprise 计划中
访问规则… - Any 任意
- Tailscale IP Tailscale IP
- Subnet CIDR Range 子网 CIDR 范围
- Autogroups 自动组
- Groups 组
- Users 用户
- Tags 标签
- Hosts 主机
- IP sets IP 集
指定访问规则… - Ports 端口
- Protocols 协议
ACL 部分用于… - acl 访问控制列表
- groups 组
- hosts 主机
- tests 测试
- tagOwners 标签所有者
- autoApprovers
- nodeAttrs
- postures 仅包含默认设备状态属性
- ipsets IP集合		 - acl 访问控制列表
- groups 组
- hosts 主机
- tests 测试
- tagOwners 标签所有者
- autoApprovers
- postures 包含默认、自定义和第三方属性
- ipsetsIP集合

ACL

Tailscale 现在使用 grants 来保护资源访问，这是一种新一代访问控制策略语法。Grants 提供了 所有原始 ACL 功能以及额外能力。

ACL 将 无限期继续运行；Tailscale 不会从产品中移除对第一代语法的支持。但是，Tailscale 建议 迁移到 grants，并对所有新的 tailnet 策略文件配置使用 grants，因为 ACL 不会获得任何新功能。

acls 部分列出了您的 tailnet 的访问规则。每条规则允许从一组源到一组目标的访问。

访问规则可以使用 组 和 标签 来授予对预定义用户组的访问权限，并将服务角色账户分配给节点。组和标签共同使您能够构建强大的 基于角色的访问控制 (RBAC) 策略。

Tailscale 会自动将所有 ACL 转换为允许从源 IP 地址到目标 IP 地址和端口的流量的低级规则。

以下示例显示了一个包含 action、src、proto 和 dst 的访问规则。

1
2
3
4
5
6
{
  "action": "accept",
  "src": [ <list-of-sources> ],
  "proto": "tcp", // 可选
  "dst": [ <list-of-destinations> ],
}

tailnet 策略的 acl 部分支持遗留字段 users 和 ports，但最佳实践是使用 src（而不是 users）和 dst（而不是 ports）。

action 动作

Tailscale 访问规则默认拒绝访问。因此，唯一可能的 action 是 accept。accept 允许流量从源 (src) 流向目标 (dst)。

src 来源

src 字段指定规则适用的来源列表。列表中的每个元素可以是以下之一：

类型 示例 描述
任意 * 源自您 tailnet 中 Tailscale 设备、任何已批准的子网和 autogroup:shared 的所有流量。不允许源自非 Tailscale 设备（除非是已批准的路由）的流量。
用户 shreya@example.com 包括所有提供的用户的设备。
组 group:<group-name> 包括提供的组中的所有用户。
Tailscale IP 100.100.123.123 仅包含拥有指定 Tailscale IP 的设备。IPv6 地址必须遵循 [1:2:3::4]:80 格式。
子网 CIDR 范围 192.168.1.0/24 包括所提供的子网内的任何 IP 地址。
主机 my-host 在 hosts 部分中包含 Tailscale IP 地址或 CIDR。
标签 tag:production 包含所有具有所提供标签的设备。
自动分组 autogroup:<role|property> 包含具有相同属性或角色的用户、目的地或用户名的设备。
自动分组(全部) autogroup:danger-all 一个特殊的自动组，用于选择所有来源，包括您的tailnet之外的来源。

您可以选择性地包含srcPosture字段，以进一步将src设备限制为匹配一组设备姿态条件的设备。

proto 协议

proto字段是一个可选字段，您可以用它指定规则适用的协议。没有协议时，访问规则适用于所有TCP和UDP流量。

您可以将 proto 指定为 IANA IP协议编号 1-255（例如 "16"）或受支持的命名别名之一。

协议 协议 IANA 协议编号
互联网组管理协议 (IGMP) igmp 2
IPv4 封装 ipv4, ip-in-ip 4
传输控制协议 (TCP) tcp 6
外部网关协议 (EGP) egp 8
任何私有内部网关 igp 9
用户数据报协议 (UDP) udp 17
通用路由封装 (GRE) gre 47
封装安全载荷 (ESP) esp 50
认证头 (AH) ah 51
流控制传输协议 (SCTP) sctp 132

关于 proto 字段的说明：

  • 您必须使用 Tailscale 版本 v1.18.2 或更高版本才能使用 proto 字段。早期版本的 Tailscale 将会失败并阻止包含协议的访问规则。
  • 如果允许流量通过给定的 IP 地址对，那么 ICMP 也将被允许。
  • 只有 TCP、UDP 和 SCTP 流量支持指定端口。所有其他协议仅支持将 * 作为协议端口。

dst 目标

dst 字段指定规则适用的目标列表。列表中的每个元素指定一个 host 和一个或多个 ports，格式为 <host>:<ports>。

host 可以是以下任一类型：

类型 示例 描述
任意 * 包括任何目标（无限制）。
用户 shreya@example.com 包括当前以指定用户身份登录的任何设备。
组 group:<group-name> 包括提供的组中的所有用户。
Tailscale IP 地址 100.100.123.123 仅包括拥有所提供的 Tailscale IP 地址的设备。
主机 example-host-name 包括 hosts section 中的 Tailscale IP 地址。
子网 CIDR 范围 192.168.1.0/24 包括给定子网内的任何 IP 地址。
标签 tag:<tag-name> 包括具有所提供标签的任何设备。
通过 出口节点 的互联网访问 autogroup:internet 包括通过 出口节点 能够访问互联网的设备。
自有设备 autogroup:self 选择一个用户的设备。autogroup:self是一个特殊的自动组选择器，当与src选择器（autogroup:<role>、group:<name>或单个用户）结合使用时，可让用户从其自身设备访问其自身设备。
Tailnet设备 autogroup:member 包括用户作为直接成员（而非共享用户）所在的tailnet中的设备。
管理员设备 autogroup:admin 包括用户是管理员的设备。
网络管理员设备 autogroup:network-admin 包括用户是网络管理员的设备。
IT管理员设备 autogroup:it-admin 包括用户是IT管理员的设备。
计费管理员设备 autogroup:billing-admin 包括用户是计费管理员的设备。
审计员设备 autogroup:auditor 包含用户为 审计员 的设备。
拥有者设备 autogroup:owner 包含用户为 tailnet 拥有者 的设备。
IP 集 ipset:<ip-set-name> 包含 IP 集合中的所有目标。

ports 字段可以是以下任意类型：

类型 描述 示例
任意 包含任意端口号。 *
单个 包含单个端口号。 22
多个 包含两个或多个由逗号分隔的端口号。 80,443
范围 包含一系列端口号。 1000-2000

子网路由器和出口节点

ACL 不会限制路由的发现。如果设备是 子网路由器，您可以独立于子网限制对其的访问。如果设备是 出口节点，您可以独立于其公共 IP 地址限制对其的访问。

要限制对子网的访问，请确保没有 ACL 授予对这些路由的访问。您可以通过一个测试来强制执行，该测试在意外授予访问权限时失败。以下示例演示了一个测试，如果 not-allowed@example.com 被允许访问 198.51.100.7:22，则该测试会失败。

1
2
3
4
5
6
7
"tests": [
  {
    "src": "not-allowed@example.com",
    "accept": ["192.0.2.100:22"], // 允许访问 Tailscale IP
    "deny": ["198.51.100.7:22"], // 不允许访问子网
  }
],

只有具有 autogroup:internet 访问权限的设备才能使用出口节点。所有其他设备（无 autogroup:internet 访问权限）不能使用出口节点。您可以通过一个测试来强制执行此规则，该测试在有任何规则意外授予对公共地址的访问权限时失败。以下示例测试在 not-allowed@example.com 可以访问 198.51.100.8:22 时失败。

1
2
3
4
5
6
7
"tests": [
  {
    "src": "not-allowed@example.com",
    "accept": ["192.0.2.100:22"], // 允许访问 Tailscale IP
    "deny": ["198.51.100.8:22"], // 不允许访问公共 IP
  }
],

您无法使用 ACL 限制特定出口节点的使用。请参阅 问题 #1567 以获取更新。

4via6 需要 IPv6 而非 IPv4

在编写针对位于4via6子网路由器后面的资源进行访问控制规则时，请使用IPv6 CIDR或地址作为目标，而不是IPv4地址。

使用tailscale debug via获取IPv6 CIDR。

Taildrop 优先级

Taildrop允许您在已登录的设备之间共享文件，即使您使用ACL限制访问。

参考用户

用户适用于所有计划。

您可以在访问规则的源（src）和目标（dst）字段中指定用户。要指定用户，请使用以下格式之一（取决于用户登录Tailscale的方式）：

格式 描述 示例
username@example.com 如果用户使用电子邮件地址登录Tailscale，请使用此格式。 alice@example.com
username@github 如果用户使用GitHub账户登录Tailscale，请使用此格式。 alice@github
username@passkey 如果用户使用通行密钥登录 Tailscale，则使用该设置。 alice@passkey

您可以使用组来引用用户集合。组允许您定义基于角色的访问控制。有多种类型的组：

  • 自动组，引用具有相同属性的所有用户。
  • 在tailnet策略文件的groups部分中定义的组，作为特定用户列表。
  • 在身份提供程序中配置并通过用户和组配置同步的组。

Autogroups 自动组

自动组适用于所有计划。

自动组是一种特殊组，自动包含具有相同属性的用户、目的地或用户名。

允许 自动分组 描述 按计划可用性
作为 dst autogroup:internet 用于允许任何用户通过您的tailnet中的_任何_ 出口节点进行访问。 在所有 套餐 上可用
作为 dst autogroup:self 用于允许任何被认证为与源用户相同的用户进行访问。不适用于标签。 在所有 套餐 上可用
作为 src 或 dst、tagOwner 或 autoApprover autogroup:owner 用于允许tailnet 所有者进行访问。 在所有 套餐 上可用
作为 src 或 dst、tagOwner 或 autoApprover autogroup:admin 用于允许任何具有 管理员 角色的用户访问。 在所有 套餐 上可用
作为 src 或 dst、tagOwner 或 autoApprover autogroup:member 用于允许任何直接成员（包括所有受邀用户）访问 tailnet。不包括来自共享设备的用户。 在所有 套餐 上可用
作为 src 或 dst、tagOwner 或 autoApprover autogroup:tagged 用于允许任何作为 标记 设备的用户访问。 在所有 套餐 上可用
作为 src 或 dst、tagOwner 或 autoApprover autogroup:auditor 用于允许任何具有 审计员 角色的用户访问。 适用于 标准版、高级版和企业版计划
作为 src 或 dst、tagOwner 或 autoApprover autogroup:billing-admin 用于允许任何具有 计费管理员 角色的用户访问。 适用于 标准版、高级版和企业版计划
作为 src 或 dst、tagOwner 或 autoApprover autogroup:it-admin 用于允许任何具有 IT 管理员 角色的用户访问。 适用于 标准版、高级版和企业版计划
作为 src 或 dst、tagOwner 或 autoApprover autogroup:network-admin 用于允许任何具有 网络管理员 角色的用户访问。 适用于 标准版、高级版和企业版计划
作为 src 或 dst、tagOwner 或 autoApprover user:*@<domain> 用于允许其登录信息位于指定域内且是 Tailnet 直接成员（包括所有受邀用户）的任何用户进行访问。不包括来自共享设备的用户。 在所有 套餐 上可用
作为 src autogroup:shared 用于允许任何接受了你的网络的共享邀请的用户访问。这让你无需提前知道电子邮件地址即可编写规则。 在所有 套餐 上可用
作为 SSH 用户 autogroup:nonroot 用于允许 Tailscale SSH 访问除 root 之外的任何用户。 在所有 套餐 上可用
作为 SSH 用户 localpart:*@<domain> 用于允许 Tailscale SSH 访问与用户登录名的 local-part 匹配的用户。 可在 高级和企业计划 上使用

autogroup:self 仅适用于用户拥有的设备，不适用于标记的设备。你不能将 autogroup:self 与 autogroup:tagged 结合使用。

旧的自动组 autogroup:members 将继续工作，但最佳实践是改而使用 autogroup:member。你不能在同一 tailnet 策略文件中同时使用 autogroup:member 和 autogroup:members。

以下示例 ssh rule 允许所有用户以非 root 身份对其拥有的设备进行 Tailscale SSH 访问：

1
2
3
4
5
6
7
8
9
"ssh": [
  {
    // 所有用户均可 SSH 到自己的设备，但为非 root 用户
    "action": "accept",
    "src": ["autogroup:member"],
    "dst": ["autogroup:self"],
    "users": ["autogroup:nonroot"]
  },
]

在默认 ACL 中，ssh 规则使用 autogroup:self 作为 dst 字段，并且在 users 字段中使用 autogroup:nonroot。如果将该 dst 字段从 autogroup:self 更改为其他目标（例如 ACL 标签），还应考虑替换 users 字段中的 autogroup:nonroot。如果不从 users 字段中移除 autogroup:nonroot，那么任何被 src 设置允许的人都能够以 dst 设备上的任何非 root 用户身份 SSH 进入。

基于域的自动组

某些自动组包含特定的域名。例如，user:*@example.com 或 localpart:*@example.com。这些自动组包含既属于 tailnet 成员且其登录名位于自动组域中的用户。例如，如果 tailnet example.com 使用自动组 user:*@altostrat.com，该组将包含所有以 @altostrat.com 处的用户身份登录的 example.com tailnet 成员（例如 laura@altostrat.com）。

以下限制适用于自动组中使用的域：

  • 提供的域不得为已知的共享域（例如 gmail.com）。
  • 如果 tailnet 使用域别名，则必须在 ACL 中显式指定这些别名域。例如，如果 example.io 别名为 example.com，并且您希望包含来自 example.com 和 example.io 的用户，请同时使用 user:*@example.com 和 user:*@example.io。
  • 尽管表达式使用了通配符 *，但它不支持任意通配符。例如，user:b*b@example.com 不会匹配 bob@example.com。
  • 您无法对 外部邀请的用户 使用基于域的自动组。基于域的自动组仅包含电子邮件与 tailnet 的某个域（直接或通过域别名）匹配的 tailnet 成员。

Groups 组

所有计划均提供组功能。但是，您的 tailnet 支持的组数量取决于您的计划。有关更多信息，请参阅我们的 定价 页面。

groups 部分允许您创建用户组，您可以在访问规则中使用这些组（而不是显式列出用户）。对组成员身份所做的任何更改都会传播到引用该组的所有规则。

以下示例演示了创建 engineering 组和 sales 组。

1
2
3
4
5
6
7
8
9
10
"groups": {
  "group:engineering": [
    "dave@example.com",
    "laura@example.com",
  ],
  "group:sales": [
    "brad@example.com",
    "alice@example.com",
  ],
},

每个组名称必须以前缀 group: 开头。每个组成员通过其完整的电子邮件地址指定，如上文 用户部分 所述。为避免混淆组成员身份的风险，组不能包含其他组。

您可以通过编辑 tailnet 策略文件来添加或删除用户的组成员身份，如上述示例 groups 定义所示，并直接从管理控制台的 用户 页面进行操作。

从用户页面编辑用户的组成员资格

您必须是 所有者、管理员或网络管理员 才能从 用户 页面编辑用户的组成员身份。

  1. 在管理控制台中打开 用户 页面。

  2. 按名称查找用户。

  3. 选择菜单 > 编辑组成员身份。

  4. 在 编辑组成员身份 对话框中：

    1. 要添加组，请选择 添加到组，然后选择要添加的组。
    2. 要删除组，请选择要删除的组旁边的 X。

  5. 完成用户组的编辑后，选择 保存。

同步组

您可以在身份提供商中创建组，并通过 用户和组配置 将其与 Tailscale 的访问控制策略同步。

您可以在身份提供商中使用相同的人类可读组名称，在 tailnet 策略文件中引用这些组。以下示例展示了一条管理 security-team 组访问权限的访问规则。

1
2
3
4
5
6
7
8
9
10
11
12
{
  "grants": [
    {
      "src": ["group:security-team@example.com"],
      "dst": ["tag:logging"],
      "ip": ["*"]
    }
  ],
  "tagOwners": {
    "tag:logging": ["group:security-team@example.com"]
  }
}

您只能编辑在 tailnet 策略文件中定义的组。您可以使用通过跨域身份管理系统 (SCIM) 集成同步的组或 tailnet 自动组，但无法编辑它们。

参考多个设备

您可以使用标签或主机为设备组定义访问规则。标签允许您定义基于角色的访问控制，以便不同服务拥有不同的访问规则。主机允许您基于 IP 地址引用定义控制规则。

  • 标签引用非用户设备组（例如应用程序或服务器）。例如，您可能有一个标签，用于对特定数据中心内的所有服务器进行分组。
  • 主机通过 IP 地址范围（包括 tailnet 内部及外部）引用设备组。例如，您可以使用主机来寻址具有固定 IP 地址且可能无法修改的应用程序。

Tags 标签

标签适用于所有方案。

tailnet 策略文件的 tags 部分允许您创建用于对非人类设备进行分组的标签。然后，您可以使用这些标签在 ACL 中选择这些设备。

您必须在tailnet策略文件的tagOwners部分中定义标签，然后才能在ACL中使用它。要标记设备，请以设备上的标签身份进行身份验证。

Hosts 主机

主机适用于所有计划。

hosts部分允许您为IP地址或CIDR范围定义人性化的名称。

以下示例显示了两个主机定义：一个用于单个IP地址，另一个用于CIDR范围。

1
2
3
4
"hosts": {
  "example-host-1": "198.51.100.100",
  "example-network-1": "198.51.100.0/24",
},

人类友好的主机名不能包含字符 @。

Postures 姿势

所有计划均支持姿势。

postures 部分允许您定义一组设备姿势管理规则，设备必须满足这些规则才能作为特定访问规则的一部分。

以下示例展示了如何使用 postures 选择运行 node 1.40 或更高版本的 macOS 设备。

1
2
3
4
5
6
7
"postures": {
  "posture:latestMac": [
    "node:os IN ['macos']",
    "node:tsReleaseTrack == 'stable'",
    "node:tsVersion >= '1.40'",
  ],
},

每个姿势必须以前缀 posture: 开头，后跟名称、一组姿势属性及其允许的值（以字符串列表形式给出）。

有关详细信息，请参阅 设备状态管理

tagOwners 标签所有者

标签适用于所有方案。

tailnet 策略文件的 tagOwners 部分定义了可分配给设备的标签以及允许分配每个标签的用户列表。

以下示例显示了一个 tagOwners 定义，该定义：

  • 将 engineering 组设置为 webserver 标签的所有者。
  • 将 president@example.com 和 security-admins 组设置为 secure-server 标签的所有者。
  • 将 autogroup:member 自动组设置为 corp 标签的所有者。
1
2
3
4
5
6
7
8
9
10
11
12
"tagOwners": {
  "tag:webserver": [
    "group:engineering",
  ],
  "tag:secure-server": [
    "group:security-admins",
    "president@example.com",
  ],
  "tag:corp": [
    "autogroup:member",
  ],
}

每个标签名称必须以前缀 tag: 开头。标签所有者可以是用户的完整登录电子邮件地址（如上述 用户部分 所定义）、组名、自动组 或其他标签。

简写符号 [] 可用于 autogroup:admin。也就是说，以下内容是等效的：

1
2
3
"tag:monitoring": [
  "autogroup:admin",
],
1
"tag:monitoring": [],

自动组 autogroup:admin 和 autogroup:network-admin 可以分配所有标签，因此 [] 隐式地只允许 autogroup:admin 和 autogroup:network-admin 分配标签。

autoApprovers 自动审批人

自动审批者适用于所有计划。

tailnet 策略文件的 autoApprovers 部分定义了无需管理员控制台进一步批准即可执行特定操作的用户列表。Tailscale 中的某些操作需要双重选择加入：管理员必须在运行 Tailscale 的设备上和 Tailscale 管理控制台中启用这些操作。这些操作包括：

对于路由，这也允许自动审批者通告指定路由的子网。

如果发生以下情况之一，Tailscale 将停止通告路由：

  • 设备由不同的用户重新认证（该用户无法通告路由或出口节点）。
  • 通告路由的用户被暂停或删除。

为避免 Tailscale 停止通告路由的情况，请考虑使用 标签作为自动审批者。

以下示例显示了一个 autoApprovers 定义，该定义会自动批准 192.0.2.0/24 的 alice@example.com 路由、engineering 组的成员以及标记为 foo 的设备。它还会自动批准标记为 bar 的设备的出口节点公告。

1
2
3
4
5
6
"autoApprovers": {
  "routes": {
    "192.0.2.0/24": ["group:engineering", "alice@example.com", "tag:foo"],
  },
  "exitNode": ["tag:bar"],
}

路由或出口节点的自动批准者可以是用户的完整登录电子邮件地址（如上文 用户部分 中所定义）、组名称、自动组 或标签。

自动批准策略仅在 Tailscale 首次收到子网路由通告时生效。更新 tailnet 策略文件以添加或修改自动批准者不会追溯批准现有的未批准路由。要触发对现有未批准路由的自动批准，请从子网路由器中移除该路由并重新进行通告。

Tailscale SSH

Tailscale SSH tailnet 策略适用于所有计划。

tailnet 策略文件的 ssh 部分定义了可以使用 Tailscale SSH（以及 SSH 用户）的用户和设备列表。要允许连接，tailnet 策略文件必须包含允许网络访问和 SSH 访问的规则：

  1. 一条允许从源到目标在端口 22 上进行连接的访问规则。
  2. 一条 SSH 访问规则，允许从源到目标以及指定的 SSH 用户进行连接。Tailscale SSH 使用此规则向正在验证的 SSH 连接分发密钥。

以下示例展示了一个 ssh 定义，要求源、目标和 SSH 用户列表每 20 小时重新验证一次。

1
2
3
4
5
6
7
8
9
{
  "action": "check", // "accept" 或 "check"
  "src": [ <list-of-sources> ],
  "dst": [ <list-of-destinations> ],
  "users": [ <list-of-ssh-users> ],
  "checkPeriod": "20h", // 可选，仅用于 check 操作。默认值为 12h
  "acceptEnv": [ "GIT_EDITOR", "GIT_COMMITTER_*", "CUSTOM_VAR_V?" ], // 可选，允许列表环境变量，这些变量可以从客户端转发到主机
  "srcPosture": [ <list-of-posture-conditions> ], // 可选，仅当姿势条件列表适用时才允许访问
},

action 动作

指定是接受连接还是对其执行额外检查。

  • accept 接受已在 tailnet 中验证的用户的连接。
  • check 要求用户根据 checkPeriod 定期重新验证。

src 来源

指定源（连接发起的位置）。您只能将访问规则的目标 (dst) 定义为您自己、一个组、一个标签或一个自动组。您不能使用 *、其他用户、IP 地址或主机名。

在创建访问规则时，无法保证 IP 地址或主机名的所有权。作为一项安全措施，Tailscale 阻止在访问规则的 dst 字段中使用用户、IP 地址或主机名，以防止一个用户无意中访问不属于他们的设备。Tailscale 还阻止任何允许多个用户访问单个用户设备的 src 和 dst 组合。

授予对 autogroup:member 的访问权限也会授予对 外部受邀用户 的访问权限，如果目标设备与这些用户 共享，即使他们在您的 tailnet 中没有设备也是如此。

dst 目标

指定目标（连接的去向）。目标可以是标签、autogroup:self（如果源仅包含用户或组），或单个命名用户（如果源仅包含同一命名用户）。这些限制的原因是 Tailscale 不允许用户在用户拥有的设备上启动 Tailscale SSH 会话，除非源是由同一用户拥有的设备。

您不能为目标指定端口，因为唯一允许的端口是 22。您不能将 * 指定为目标。

users 用户

此策略适用于 所有计划。

指定主机上允许的用户名集合。Tailscale 仅使用主机上已存在的用户帐户。

  • 指定 autogroup:nonroot 以允许任何不是 root 的用户。
  • 指定 localpart:*@<domain> 以允许主机上其名称与用户登录名的 本地部分 匹配的用户，当且仅当用户的登录电子邮件在 <domain> 中。Tailscale 不会对本地部分进行任何特殊处理。例如，如果登录名是 dave+sshuser@example.com，Tailscale 会将其映射到 SSH 用户 dave+sshuser。此方法仅在 高级版和企业版计划 中可用。
  • 如果未指定用户，Tailscale 将使用本地主机的用户。也就是说，如果用户在本地以 alice 身份登录，然后通过 SSH 连接到另一台设备，Tailscale SSH 将尝试以用户 alice 身份登录。

checkPeriod 检查周期

此策略仅适用于 高级版和企业版计划。

当 action 为 check 时，checkPeriod 指定在需要检查之前允许连接的时间段。您可以以分钟或小时为单位指定时间。时间必须至少为一分钟，最多为 168 小时（一周）。

  • 默认检查周期为12小时。
  • 您也可以指定always以要求在每次连接时进行检查。使用always可能会导致与自动化工具（如Ansible）出现意外行为，这些工具会快速连续打开多个SSH连接。

acceptEnv 接受环境

主机必须运行Tailscale v1.76.0或更高版本才能使用acceptEnv。

指定允许列表中的环境变量名称集，客户端可以使用SendEnv或SetEnv将这些变量发送到主机。

值可以包含*和?通配符。*匹配零个或多个字符，?匹配单个字符。

acceptEnv示例

接受环境 允许 拒绝
* FOO_A FOO_B FOO_OTHER BAZ
FOO_* FOO_A FOO_B FOO_OTHER BAZ
FOO_? FOO_A FOO_B FOO_OTHER BAZ
FOO_A FOO_A FOO_B FOO_OTHER BAZ

srcPosture

srcPosture 字段是一个设备状态条件数组，可用于进一步限制网络源 (src)。例如，您可以使用 srcPosture 将访问权限限制为仅允许运行特定版本 Tailscale 客户端的设备。

评估顺序

Tailscale 使用最严格的策略优先评估 SSH 访问规则：

  • 检查策略
  • 接受策略

例如，如果您有一条访问规则，允许用户 alice@example.com 使用 accept 规则访问资源，并且另一条规则允许 group:devops（alice@example.com 所属）使用 check 规则访问资源，则 check 规则适用。

未修改其 tailnet 策略文件的 Tailnets 拥有一个默认 SSH 策略，允许用户使用检查模式访问其拥有的设备。

唯一允许的连接类型是：

  • 从用户到其自己的设备（作为任何用户，包括 root）。
  • 从用户到已标记的设备（作为任何用户，包括 root）。
  • 从已标记的设备到另一个已标记的设备（适用于任何标签）。来自已标记设备的 SSH 访问规则不能处于检查模式。
  • 从用户到已与其共享的已标记设备，前提是目标主机已配置 Tailscale 并启用 SSH，并且目标的 ACL 允许该用户通过 SSH 连接。

也就是说，允许的最宽泛策略将是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["root", "autogroup:nonroot"]
    },
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["tag:prod"],
      "users": ["root", "autogroup:nonroot"]
    },
    {
      "action": "accept",
      "src": ["tag:logging"],
      "dst": ["tag:prod"],
      "users": ["root", "autogroup:nonroot"]
    }
  ]
}

要允许用户仅通过SSH连接到自己的设备（作为非root）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot"]
    }
  ]
}

要允许 group:sre 访问生产环境中标记为 tag:prod 的设备：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
  "groups": {
    "group:sre": ["alice@example.com", "bob@example.com"]
  },
  "grants": [
    {
      "src": ["group:sre"],
      "dst": ["tag:prod"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["group:sre"],
      "dst": ["tag:prod"],
      "users": ["ubuntu", "root"]
    }
  ],
  "tagOwners": {
    // group:sre 中的用户可以应用标签 tag:prod
    "tag:prod": ["group:sre"]
  }
}

要允许 Alice 访问开发环境中标记为 tag:dev 且已共享给她的设备：

1
2
3
4
5
6
7
8
9
10
{
  "ssh": [
    {
      "action": "accept",
      "src": ["alice@example.com"],
      "dst": ["tag:dev"],
      "users": ["root", "alice"]
    },
  ]
}

将主机用户与登录电子邮件进行匹配可能很有用。例如，您可以允许 dave@example.com 作为主机用户 dave 进行身份验证。

要允许登录域 example.com 中的任何 tailnet 成员访问生产环境中标记为 tag:prod 的设备，作为与其登录电子邮件本地部分匹配的用户：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "grants": [
    {
      "src": ["user:*@example.com"],
      "dst": ["tag:prod"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["user:*@example.com"],
      "dst": ["tag:prod"],
      "users": ["localpart:*@example.com"]
    }
  ]
}

nodeAttrs 节点属性

tailnet 策略文件的 nodeAttrs 部分定义了应用于 tailnet 中特定设备的附加属性。

使用节点属性的一种方法是为 tailnet 中的不同设备设置不同的 NextDNS 配置。以下示例显示了一个 nodeAttrs 定义，该定义以属性 nextdns:abc123 和 nextdns:no-device-info 针对 my-kid@my-home.com 和 tag:server。

1
2
3
4
5
6
7
8
9
"nodeAttrs": [
  {
    "target": ["my-kid@my-home.com", "tag:server"],
    "attr": [
      "nextdns:abc123",
      "nextdns:no-device-info",
    ],
  },
],

目标

指定属性应用于哪些节点（设备）。您可以使用标签 (tag:server)、用户 (alice@example.com)、组 (group:kids) 或 * 来选择设备。

attr 属性

指定哪些属性应用于这些节点（设备）。

例如：

  • 属性 nextdns:abc123 指定了 NextDNS 配置 ID abc123。如果使用此属性，它将覆盖全局 NextDNS 配置。
  • 属性 nextdns:no-device-info 禁止向 NextDNS 发送设备元数据。

以下示例允许 tailnet 的成员在其节点上使用 Tailscale Funnel：

1
2
3
4
5
6
"nodeAttrs": [
  {
    "target": ["autogroup:member"],
    "attr":   ["funnel"],
  },
],

您可以使用 nodeAttrs 策略为特定设备启用 randomize-client-port 设置，而不是使用 网络范围策略设置。

1
2
3
4
5
6
"nodeAttrs": [
  {
    "target": ["tag:office-network", "group:sea-office"],
    "attr":   ["randomize-client-port"],
  },
],

app 应用

指定哪些应用层功能适用于这些节点（设备）。

以下示例节点属性定义为 example.com 域配置了 example-connector 标签。

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "target": ["*"],
  "app": {
    "tailscale.com/app-connectors": [
      {
        "name": "example-app",
        "connectors": ["tag:example-connector"],
        "domains": ["example.com"],
        "routes": ["192.0.2.0/24"],
      },
    ],
  },
}

特定应用程序以 <domainName>/<capabilityName> 格式定义功能的名称。示例使用 tailscale.com/app-connectors。

与每个功能关联的值是一个 JSON 对象数组，每个对象包含特定功能的配置选项。

请参阅 应用连接器的工作原理 和 使用应用连接器的最佳实践 主题。

tests 测试

测试适用于 所有计划。

tests 部分允许您编写关于访问控制策略（授权和 ACL）的断言，这些断言在每次 tailnet 策略文件更改时作为检查运行。如果断言失败，Tailscale 会拒绝更新后的 tailnet 策略文件并返回错误。错误消息指示失败的测试。

测试可确保您不会意外撤销重要权限或暴露关键系统。

tests 定义如下所示：

1
2
3
4
5
6
7
8
9
10
11
"tests": [
  {
    "src": "dave@example.com",
    "srcPostureAttrs": {
      "node:os": "windows",
    },
    "proto": "tcp",
    "accept": ["example-host-1:22", "vega:80"],
    "deny": ["192.0.2.3:443"],
  },
],

src 来源

指定要测试的用户身份，可以是用户的电子邮件地址、组、标签或映射到 IP 地址的主机。测试用例从使用所提供身份进行身份验证的设备的角度运行。

srcPostureAttrs

指定在评估访问规则中的设备状态条件时要使用的设备状态属性（作为键值对）。仅当访问规则包含设备状态条件时，才需要使用此字段。

proto 协议

指定 accept 和 deny 规则的 IP 协议，类似于 ACL 规则中的 proto 字段。省略时，测试将检查 TCP 或 UDP 访问。

测试互联网控制消息协议 (ICMP) 访问时，设置 "proto": "icmp" 并在目标中使用端口 0，因为 ICMP 不使用端口。以下示例测试用户 alice@example.com 是否可以 ping 标记为 tag:production 的设备：

1
2
3
4
5
6
7
"tests": [
  {
    "src": "alice@example.com",
    "proto": "icmp",
    "accept": ["tag:production:0"],
  },
],

accept 和 deny 目标

指定要接受或拒绝的目标。列表中的每个目标的形式为 host:port，其中 port 是单个数字端口，host 是以下之一：

类型 示例 描述
Tailscale IP 100.100.123.123 包含具有提供的 Tailscale IP 地址的设备。IPv6 地址必须遵循 [1:2:3::4]:80 格式。
主机 my-host 在 hosts 部分中包含 Tailscale IP 地址。
用户 shreya@example.com 包含以提供的用户身份登录的设备的 Tailscale IP 地址。
组 group:security@example.com 包含以提供的组的代表成员身份登录的设备的 Tailscale IP 地址。
标签 tag:production 包含具有提供的标签的设备的 Tailscale IP 地址。
服务 svc:my-service 包含与提供的服务关联的 Tailscale 虚拟 IP 地址。

您不能使用 CIDR（子网）表示法来测试子网范围。例如，192.168.1.0/24 无效。相反，您必须指定单个 IP 地址或主机名。

src 中的源和 accept 及 deny 中的目标必须引用特定实体，并且不支持 * 通配符。例如，accept 目标不能是 tags:*。

旧版 allow（而非 accept）在 ACL 中继续有效。但最佳实践是使用 accept。

sshTests SSH测试

SSH 测试适用于 所有计划。

sshTests 部分允许您编写关于 Tailscale SSH 访问规则的断言。SSH 测试的功能类似于 ACL 测试。

当 tailnet 策略文件发生更改时，SSH 测试会运行。如果断言失败，Tailscale 会拒绝更新后的 tailnet 策略文件，并附带详细说明失败测试的错误信息。

以下示例展示了一个 sshTests 定义，它对从 dave@example.com 到 example-host-1 的连接执行以下测试：

  • 如果用户是 dave，则接受该连接。
  • 如果用户是 admin，则检查该连接。
  • 如果用户是 root，则拒绝该连接。
1
2
3
4
5
6
7
8
9
10
11
12
"sshTests": [
  {
    "src": "dave@example.com",
    "dst": ["example-host-1"],
    "accept": ["dave"],
    "check": ["admin"],
    "deny": ["root"],
    "srcPostureAttrs": {
      "node:os": "windows",
    },
  },
],

src 来源

指定尝试以 SSH 身份连接的用户身份，可以是 用户的电子邮件地址、组、标签 或映射到 IP 地址的 主机。测试用例从使用所提供身份进行身份验证的设备的角度运行。

srcPostureAttrs

指定在评估访问规则中的设备状态条件时要使用的设备状态属性（作为键值对）。仅当访问规则包含设备状态条件时，才需要使用此字段。

dst 目标

指定 src 用户正在连接的一个或多个目标，可以是 用户的电子邮件地址、组、标签 或映射到 IP 地址的 主机。

accept 接受

指定在 dst 主机上无需额外检查即可禁止的一个或多个用户名。请参阅 action accept。

check 检查

指定在 src 用户通过额外检查后，在 dst 主机上禁止的一个或多个用户名。请参阅 action check。

deny 拒绝

指定在 dst 主机上（任何情况下）禁止的一个或多个用户名。

IP 集

IP 集是一种管理 IP 地址组的方式。它可以封装 IP 地址、CIDR、主机、自动组和其他 IP 集的集合。IP 集的主要好处是，它们允许您将多个网络部分分组到单个集合中，从而使您能够将访问控制策略应用于该集合，而不是单个 IP 地址、主机或子网。

请参阅 IP 集文档。

网络策略选项

网络策略选项适用于 所有计划。

除了访问规则之外，tailnet 策略文件还包含一些用于特殊目的的网络范围策略设置。大多数网络永远不需要指定这些设置。

derpMap

derpMap 部分允许您向网络添加 自定义 DERP 服务器，您的设备将根据需要将其用于中继流量。您还可以使用此部分禁用使用 Tailscale 提供的 DERP 服务器。例如，您可能希望禁用 tailnet 提供的 DERP 服务器以满足公司合规性要求。有关更多信息，请参阅 运行自定义 DERP 服务器。

disableIPv4

建议使用 disable-ipv4 节点属性，而非 disableIPv4 字段，如 CGNAT 冲突 中所述。

disableIPv4 字段（若设置为 true）会停止向您的设备分配 Tailscale IPv4 地址。禁用 IPv4 后，网络中的所有设备将仅接收 Tailscale IPv6 地址。不支持 IPv6 的设备（例如，在操作系统中禁用了 IPv6 的系统）将无法访问。此选项适用于已存在 100.64.0.0/10 运营商级 NAT 地址范围冲突的用户。

OneCGNATRoute

OneCGNATRoute 字段控制 Tailscale 客户端生成的路由。

Tailscale 客户端可以具有以下任一情况：

  • 一条大型 100.64/10 路由，以避免设备上线和离线时路由表的频繁变动。（这种变动对 macOS 上基于 Chromium 的浏览器具有破坏性。）
  • 细粒度的 /32 路由。

OneCGNATRoute 的可能取值如下：

  • 空字符串或未提供：对每个平台使用默认启发式方法。

    • 对于所有平台（macOS 除外），Tailscale 会为每个设备添加细粒度的 /32 路由。
    • 在 macOS 上（适用于 Tailscale v1.28 或更高版本），Tailscale 会添加一条 100.64/10 路由。如果其他接口也路由该范围内的 IP 地址，Tailscale 将不会使用单条 100.64/10 路由。

  • "mac-always"：macOS 客户端始终添加一条 100.64/10 路由。

  • "mac-never": macOS 客户端始终会添加细粒度的 /32 路由。

randomizeClientPort

您只应在咨询 Tailscale 支持团队后，将 randomizeClientPort 字段用作某些 防火墙设备的临时解决方案。

将 randomizeClientPort 字段设置为 true 会使设备为 WireGuard 流量使用随机端口，而非默认的静态端口 41641。