基于 Tailscale 实现智能代理网络通信与对话路由

基本信息

导语

在分布式系统日益复杂的背景下，如何让智能代理安全、高效地接入网络通信已成为技术落地的关键。Tailscale 提供的基于 WireGuard 的组网能力，能够为代理程序构建稳定的底层连接，确保其参与到正确的业务上下文中。本文将解析如何利用 Tailscale 的 ACL 和节点发现机制，解决代理通信中的身份验证与网络拓扑难题，帮助开发者构建更安全、可控的自动化交互流程。

评论

评价文章：Networking with agents: Put them in the right conversations with Tailscale

中心观点： 文章主张利用 Tailscale 的基于身份的零信任网络（Mesh VPN）技术，将 AI 智能体视为一等公民，通过精细化的 ACL（访问控制列表）和标签路由，解决智能体在动态、分布式环境下的安全通信与服务发现问题，从而构建更灵活的“智能体网络”。

深入评价

1. 内容深度：从“连接机器”到“连接智能”的范式转移

[事实陈述] 文章跳出了传统 VPN 仅用于“开发者远程办公”或“连接 VPC”的定式，敏锐地捕捉到了 AI Agent 架构中的核心痛点：动态性与安全性的冲突。 [你的推断] 文章的深度在于它不仅提出了“用 Tailscale 连接 Agent”，更重要的是提出了一种**“基于身份的 API 网络”**范式。传统的微服务通信往往依赖 IP 地址或 DNS，这在动态扩缩容的 Agent 环境中维护成本极高。Tailscale 利用 WireGuard 和公钥基础设施（PKI），将安全边界从“网络层”下沉到“应用/身份层”。这种论证非常严谨，它指出了 AI Agent 通信与传统 RPC 调用的本质区别：Agent 需要更像人类用户一样拥有身份，而非仅仅是后台进程。

2. 实用价值：降低分布式系统的“最后一公里”复杂度

[作者观点] 对于正在构建 Multi-Agent 系统的工程师而言，这篇文章具有极高的实战指导意义。 在实际工作中，让运行在用户笔记本上的本地 Agent 安全地访问运行在云端的 RAG（检索增强生成）数据库，通常涉及复杂的 NAT 配置、公网暴露和 API 网关设置。 [案例说明] 文章中提到的 Tag-based ACL（基于标签的访问控制） 是一个极具价值的实用技巧。例如，你可以赋予所有“数据分析类 Agent”一个 tag:agent-data 的标签，然后在 ACL 中规定只有拥有该标签的节点才能访问 PostgreSQL 数据库端口。这种声明式的安全策略极大地简化了权限管理，避免了为每个新 Agent 颁发独立 API Key 的繁琐流程。

3. 创新性：重新定义“端”的概念

[事实陈述] 文章最具创新性的观点是将 AI Agent 拟人化。 [你的推断] 过去，网络安全强调“人”与“服务”的隔离（SSO/MFA）。随着 Agent 的普及，未来的网络架构将是“人”与“Agent”以及“Agent”与“Agent”的混合交织。文章实际上提出了一个新的网络拓扑结构：Human-Agent-Mesh。这种视角的转换是开创性的，它暗示了未来的基础设施不应再区分“客户端”和“服务器”，所有节点都是对等的、可移动的智能体。

4. 可读性与逻辑性

[事实陈述] 文章结构清晰，采用了“问题-解决方案-实践”的经典技术叙事结构。 [评价] 逻辑链条完整：从 Agent 需要移动办公 -> 传统 VPN 不安全/不灵活 -> Tailscale 的 ACL 如何解决 -> 具体配置示例。不过，对于非网络背景的开发者，文中关于 ACL 语法和 Coordination（协调器）原理的部分可能略显晦涩，需要一定的网络基础知识门槛。

5. 行业影响：推动“私域 Agent”的普及

[你的推断] 这篇文章虽然是一篇技术软文，但客观上推动了 “Local-First”（本地优先） 架构在 AI 领域的发展。目前行业趋势是模型越来越大，但出于隐私考虑，很多企业希望 Agent 能在本地运行（处理敏感数据）同时调用云端工具。Tailscale 这种 P2P 的组网方式，完美契合了这一趋势，可能会成为连接本地大模型与云端服务的标准协议层。

支撑理由与反例/边界

支撑理由：

  1. 安全性内建： 相比于开放公网 API 并依赖 API Key（容易泄露），Tailscale 的零信任网络默认拒绝所有连接，只有拥有特定证书的 Agent 才能接入，提供了网络层（L3）的强隔离。
  2. 网络穿透能力： Agent 可能运行在处于 NAT 后的边缘设备或移动终端上，Tailscale 的 DERLE 中继技术能保证连接的稳定性，无需复杂的端口映射。
  3. 审计与可观测性： 通过 Tailscale 的日志，可以清晰地记录“哪个 Agent ID”在“什么时间”访问了“哪个服务”，这对于合规性要求极高的 AI 应用至关重要。

反例/边界条件：

  1. 延迟敏感场景： 对于需要极高吞吐量或极低延迟的 Agent 间通信（例如同一数据中心内的海量模型推理请求），Tailscale 引入的额外封装开销可能不如直连或 CNI（容器网络接口）高效。
  2. 状态管理与扩展性： Tailscale 解决了“连接”问题，但没有解决“服务发现”的动态状态问题。如果 Agent 是无状态的短生命周期任务（如 Serverless 容器），频繁地注册和注销 Tailscale 节点可能会带来较大的协调开销，此时传统的 Service Mesh（如 Istio）可能更合适。

争议点或不同观点

1. “大炮打蚊子”的复杂性争议： [你的推断] 许多开发者认为，对于简单的 Agent 通信，直接使用经过签名验证的

代码示例

 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
30
31
32
33
34
35
36
37
38
39

# 示例1：通过Tailscale API获取设备列表并筛选在线设备
import requests

def get_tailscale_devices(api_key, tailnet):
    """
    获取Tailscale网络中的设备列表并筛选在线设备
    :param api_key: Tailscale API密钥
    :param tailnet: 你的Tailscale网络名称
    :return: 在线设备列表
    """
    url = f"https://api.tailscale.com/api/v2/tailnet/{tailnet}/devices"
    headers = {"Authorization": f"Bearer {api_key}"}
    
    try:
        response = requests.get(url, headers=headers)
        response.raise_for_status()
        devices = response.json().get("devices", [])
        
        # 筛选在线设备
        online_devices = [
            {
                "name": device["name"],
                "addresses": device["addresses"],
                "os": device["os"]
            }
            for device in devices
            if device["online"]
        ]
        
        return online_devices
    except requests.exceptions.RequestException as e:
        print(f"API请求失败: {e}")
        return []

# 使用示例
# api_key = "your_api_key"
# tailnet = "example.com"
# devices = get_tailscale_devices(api_key, tailnet)
# print(devices)

 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
30
31

# 示例2：自动配置Tailscale ACL规则
import json

def generate_acl_rule(user_email, allowed_tags):
    """
    生成Tailscale ACL规则JSON
    :param user_email: 用户邮箱
    :param allowed_tags: 允许访问的标签列表
    :return: ACL规则字典
    """
    acl_rule = {
        "acls": [
            {
                "action": "accept",
                "users": [user_email],
                "ports": [
                    {
                        "proto": "tcp",
                        "dst": [f"{tag}:*" for tag in allowed_tags]
                    }
                ]
            }
        ]
    }
    return acl_rule

# 使用示例
# user = "user@example.com"
# tags = ["tag:production", "tag:staging"]
# acl = generate_acl_rule(user, tags)
# print(json.dumps(acl, indent=2))

 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
30
31
32

# 示例3：通过Tailscale建立安全隧道并执行远程命令
import subprocess
import time

def tailscale_ssh(device_ip, command, ssh_key_path="~/.ssh/id_rsa"):
    """
    通过Tailscale网络执行远程SSH命令
    :param device_ip: 目标设备的Tailscale IP
    :param command: 要执行的命令
    :param ssh_key_path: SSH私钥路径
    :return: 命令执行结果
    """
    try:
        # 使用SSH通过Tailscale网络连接
        full_command = f"ssh -i {ssh_key_path} -o StrictHostKeyChecking=no root@{device_ip} '{command}'"
        result = subprocess.run(
            full_command,
            shell=True,
            check=True,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            text=True
        )
        return result.stdout
    except subprocess.CalledProcessError as e:
        return f"命令执行失败: {e.stderr}"

# 使用示例
# device_ip = "100.x.x.x"  # Tailscale分配的IP
# command = "docker ps"
# output = tailscale_ssh(device_ip, command)
# print(output)

案例研究

1：某跨国电商公司的远程开发环境访问

1：某跨国电商公司的远程开发环境访问

背景: 该公司拥有一支分布在全球的开发团队，核心业务代码托管在位于AWS新加坡节点的私有Kubernetes集群中。出于安全合规要求，数据库和应用服务器仅允许内网访问，不对外暴露公网IP。

问题: 随着团队扩展，通过传统VPN进行远程办公变得极不稳定。开发人员经常面临连接断开、高延迟问题，且配置VPN客户端繁琐。此外，由于IP地址冲突，部分在家办公的开发人员无法通过VPN连接到开发环境，导致工作效率严重下降。

解决方案: 公司引入了Tailscale，利用其基于WireGuard的UDP打洞技术（NAT traversal），构建了一个覆盖所有开发人员笔记本和云端服务器的私有网络。

  1. 在AWS的VPC中部署Tailscale中继子网路由器。
  2. 为每位开发人员的笔记本电脑安装Tailscale客户端，开启“强制路由”模式，确保所有对私有IP的请求均通过Tailscale隧道传输。
  3. 利用ACL（访问控制列表）精细控制不同职级开发人员对特定服务器端口的访问权限。

效果:

  • 连接稳定性提升：开发人员不再受限于VPN服务器的并发连接数，P2P直连模式使得访问延迟降低了40%以上。
  • 安全性增强：无需在云端服务器开放任何公网端口（SSH或API端口），消除了被暴力扫描和攻击的风险，所有访问均通过基于身份的加密进行验证。
  • 运维简化：新员工入职只需安装客户端并登录Google账号即可自动获得网络访问权限，无需手动配置证书或VPN参数。

2：某SaaS初创公司的多区域数据库灾备

2：某SaaS初创公司的多区域数据库灾备

背景: 该初创公司的主要服务部署在阿里云华北区域，为了防止区域性故障导致数据丢失，他们在阿里云华东区域搭建了一套实时热备数据库。备库平时不对外提供服务，仅用于数据同步和灾难恢复。

问题: 在云厂商的公网环境下，跨地域传输数据库同步流量不仅费用高昂，而且面临数据泄露风险。如果通过专线连接，搭建成本过高且部署周期长，不符合初创公司的预算要求。此外，运维人员需要一种安全的方式在紧急情况下连接到备库进行维护。

解决方案: 使用Tailscale连接两个不同区域的VPC网络。

  1. 在两个区域的数据库子网中分别安装Tailscale的Docker容器作为节点。
  2. 配置Tailscale的网络功能，将两个云内网的私有网段通过加密隧道打通。
  3. 设置网络策略，仅允许数据库端口（如3306）在两个节点之间通信，阻断其他不必要的流量。

效果:

  • 成本优化：通过Tailscale的加密隧道传输数据，避免了云厂商昂贵的跨区域公网流量费用，且Tailscale在免费额度内提供了足够的带宽。
  • 安全隔离：数据库同步流量完全运行在私有Overlay网络中，不经过公网，实现了端到端的加密隔离。
  • 快速恢复：当主节点发生故障时，运维人员可以通过Tailscale网络立即切换到备用节点，无需重新配置防火墙或安全组，RTO（恢复时间目标）大幅缩短。

3：工业物联网设备的远程维护

3：工业物联网设备的远程维护

背景: 一家智能水表制造企业，其设备部署在全国各地的封闭小区内部网中。设备基于Linux系统运行，需要软件工程师定期进行远程调试、日志收集和固件升级。

问题: 设备位于NAT网络甚至多层NAT之后，没有公网IP地址。传统的解决方案是通过4G拨号或向客户申请端口映射，但这不仅操作复杂，还会因为网络环境变化导致连接中断。由于设备数量庞大，维护成本极高。

解决方案: 在每台水表网关中集成Tailscale客户端。

  1. 设备启动后自动连接到Tailscale的协调服务器，并注册到公司的私有网络中。
  2. 工程师在总部通过Tailscale网络，直接SSH访问设备的局域网IP地址。
  3. 结合Tailscale的API，实现当设备上线时自动触发告警通知工程师。

效果:

  • 零配置连接：无论设备处于何种复杂的网络环境（如4G路由器、小区WiFi），只要能上网，工程师即可直接访问，无需现场网络人员配合。
  • 运维效率翻倍：工程师可以像在局域网内一样直接使用SSH或Web界面管理设备，远程排查故障的平均时间从2小时缩短至10分钟。
  • 安全性可控：通过设置密钥过期时间和设备标签，确保只有授权的工程师才能访问特定的设备组，避免了因设备广域网暴露带来的安全隐患。

最佳实践

最佳实践指南

实践 1：实施最小权限访问控制

说明: Tailscale 的 ACL（访问控制列表）功能允许精细定义节点间的通信权限。最佳实践是默认拒绝所有流量，仅显式允许特定 AI Agent 所需的特定服务和端口访问。这可以防止 Agent 被入侵后攻击网络中的其他关键基础设施。

实施步骤:

  1. 在 Tailscale Admin Console 中编辑 ACL 文件。
  2. 使用 tagOwners 将 Agent 节点打上特定的标签（如 tag:agent）。
  3. 编写 ACL 规则，仅允许该标签访问特定的目标标签或端口（例如，仅允许访问 tag:database 的 5432 端口）。
  4. 定期审计 ACL 规则，移除不再需要的权限。

注意事项: 避免使用过于宽泛的规则（如 *），确保 Agent 只能“看到”并连接到其完成任务所必需的资源。

实践 2：使用 Tailnet Lock 进行密钥撤销

说明: 传统的 PKI 密钥管理在撤销密钥时往往存在延迟。Tailnet Lock 是 Tailscale 的分布式密钥管理机制，它允许在密钥泄露或 Agent 实例被终止时，立即且不可逆地撤销其访问权限，无需等待 CRL（证书撤销列表）传播。

实施步骤:

  1. 在 Tailscale 网络设置中启用 Tailnet Lock。
  2. 为每个 Agent 实例或机器人生成唯一的机器密钥。
  3. 当 Agent 任务结束或发生异常时，通过 API 或控制台立即撤销该特定节点的密钥。

注意事项: 一旦启用 Lock，撤销操作是全局且迅速的，非常适合动态伸缩的 Agent 环境。

实践 3：利用 4via6 和 DERP 优化连接稳定性

说明: AI Agent 可能部署在受限制的网络环境（如云函数、CI/CD 容器）中，这些环境通常阻止入站连接或 P2P 打洞。Tailscale 的 DERP（中继服务器）和 4via6（IPv4 隧道）功能确保 Agent 即使在严格的防火墙后也能发起出站连接并与控制平面通信。

实施步骤:

  1. 确保 Tailscale 客户端配置为默认使用 DERP 中继。
  2. 如果使用 Docker 容器运行 Agent，确保启用了 tailscale up 的 --accept-routes 和 --advertise-exit-node（如需）参数。
  3. 监控连接状态，确保 Agent 在无法建立 P2P 连接时能无缝切换到中继模式。

注意事项: 对于纯出站的 Agent，不需要配置端口转发，这大大简化了部署复杂度。

实践 4：通过 API 实现动态节点管理

说明: 在自动化工作流中，手动管理 Agent 节点是不现实的。最佳实践是利用 Tailscale API 和 Headscale（如使用开源方案）来动态创建、授权和销毁 Agent 的网络身份，使其与 CI/CD 管道或容器编排系统无缝集成。

实施步骤:

  1. 创建一个具有有限权限的 API 密钥，专门用于节点管理。
  2. 在 Agent 启动脚本中调用 API，生成临时的 OAuth 客户端或使用预共享密钥进行注册。
  3. 在 Agent 容器销毁时，通过 Webhook 或脚本自动调用 API 移除该节点。

注意事项: 确保用于管理 Agent 的 API 密钥本身受到严格保护，并存储在安全的密钥管理服务（如 HashiCorp Vault 或 AWS Secrets Manager）中。

实践 5：集中日志记录与流量审计

说明: 为了调试 Agent 行为或检测异常活动，必须记录 Agent 的连接请求和流量日志。Tailscale 支持将日志导出到 Syslog 或 S3，结合网络流量分析，可以追踪 Agent 访问了哪些“对话”（服务）。

实施步骤:

  1. 配置 Tailscale 的日志记录功能，启用 ACL 审计日志。
  2. 将日志发送到 SIEM 系统（如 Splunk 或 Elasticsearch）。
  3. 设置告警规则，当检测到来自 Agent 标签的连接被拒绝（ACL Deny）时触发通知。

注意事项: 日志中可能包含敏感元数据，需确保存储和传输过程中的加密与合规性。

实践 6：使用子网路由器而非 Exit Node 访问本地资源

说明: 如果 Agent 需要访问物理网络中的设备（如本地服务器、硬件设备），应将其配置为子网路由器，而不是 Exit Node。这能提供更精确的网络控制，避免将所有流量通过 Agent 路由，减少安全风险。

实施步骤:

  1. 在托管 Agent 的机器上，启用 IP 转发并配置 Tailscale 宣传子网路由（`tailscale up –advertise-routes=192.168.

学习要点

  • Tailscale 利用 DERP（中继服务器）技术，确保在无法建立点对点（P2P）连接时，流量仍能通过加密中继节点安全传输，从而解决复杂的网络穿透问题。
  • 通过将网络代理（如 SSH 跳板机）接入 Tailscale 虚拟局域网，用户可以安全地将内部服务暴露给特定授权节点，实现精准的流量路由与访问控制。
  • 该方案消除了传统 VPN 配置中复杂的防火墙端口开放和 NAT 转发设置，仅需在代理节点安装 Tailscale 即可实现即插即用的组网。
  • 利用 Tailscale 的 ACL（访问控制列表）功能，可以细粒度地定义哪些“代理”节点可以访问哪些目标服务，从而实现最小权限原则。
  • 这种架构允许将位于不同物理位置（如本地数据中心、云端或家庭网络）的代理节点统一管理，像操作局域网内的设备一样进行连接，无需公网 IP。
  • 所有通信流量均经过端到端加密与身份验证，利用 WireGuard 协议确保数据在通过代理转发过程中的安全性与完整性。
  • 相比于传统的 SSH 隧道或反向代理方案，Tailscale 提供了更稳定、自动化的连接维护机制，能有效处理网络切换和断线重连场景。

常见问题

1: Tailscale 是什么？它与传统的 VPN 有什么区别？

1: Tailscale 是什么？它与传统的 VPN 有什么区别？

A: Tailscale 是一种基于 WireGuard 协议的零配置网格网络（Mesh VPN）服务。它允许用户在不同的设备（如服务器、家庭电脑、移动设备）之间建立安全的点对点连接。

与传统的 VPN 相比，Tailscale 的主要区别在于：

  1. 去中心化：传统 VPN 通常采用 Hub-and-Spoke 模型，所有流量都需要经过中心服务器；而 Tailscale 创建的是网状网络，设备之间一旦建立连接，流量可以直接点对点传输，降低了延迟并提高了带宽利用率。
  2. NAT 穿透能力：Tailscale 使用一组中继服务器（DERP）来协助建立连接，能够轻松穿越各种复杂的防火墙和 NAT 设备，无需手动配置路由器端口转发。
  3. 易用性：它通过现有的身份提供商（如 Google、GitHub、Microsoft）进行身份验证，无需管理证书或复杂的密钥，安装登录即可使用。

2: 文章标题中的 “Networking with agents” 具体指什么？这里的 “Agents” 是指 AI 智能体吗？

2: 文章标题中的 “Networking with agents” 具体指什么？这里的 “Agents” 是指 AI 智能体吗？

A: 在这篇文章的语境下，“Agents” 并非特指 AI 智能体，而是指网络代理程序或中间件。

文章的核心在于探讨如何利用 Tailscale 的网络能力，将各种自动化工具、脚本、CI/CD 流程或后台服务安全地连接到特定的私有资源。这里的 “Conversations” 指的是网络连接或数据交换。因此，这句话的含义是：利用 Tailscale 为这些代理程序搭建安全的网络通道，使它们能够安全地与原本隔离的后端服务（如数据库、内部 API）进行通信，而无需将这些服务暴露到公网上。

3: Tailscale 如何保证网络通信的安全性？我是否需要开放防火墙端口？

3: Tailscale 如何保证网络通信的安全性？我是否需要开放防火墙端口？

A: Tailscale 通过多层安全机制保障通信安全，且通常不需要修改防火墙设置：

  1. 加密传输：所有 Tailscale 节点之间的流量都使用 WireGuard 进行加密，这意味着即使数据包经过互联网传输，也是密文状态。
  2. 身份验证：它依赖于您现有的身份提供商（SSO），只有被授权的用户或设备才能加入网络。
  3. 访问控制列表（ACL）：管理员可以通过配置文件精细定义哪些设备可以与哪些设备通信，实现最小权限原则。

关于防火墙：Tailscale 客户端通常使用出站连接（通常基于 UDP 和 443 端口），这使得它能够在大多数受限的网络环境（如公司防火墙或咖啡厅 Wi-Fi）中工作，而无需您手动配置入站端口转发规则。

4: 如果设备处于 NAT 后面或没有公网 IP，Tailscale 还能工作吗？

4: 如果设备处于 NAT 后面或没有公网 IP，Tailscale 还能工作吗？

A: 可以。这是 Tailscale 的核心优势之一。

Tailscale 实现了强大的 NAT 穿透功能。当两个节点位于不同的 NAT 设备后面时，Tailscale 会尝试使用多种技术（如 STUN、UDP 打洞）建立直接的点对点连接。如果由于网络条件极其严格（如对称 NAT）无法建立直连，Tailscale 的中继服务器会自动通过加密隧道转发流量。虽然中继流量速度可能比直连慢，但它保证了连接的绝对可靠性，且用户无需感知这一过程。

5: 使用 Tailscale 进行 “Networking” 是否会产生额外的费用？

5: 使用 Tailscale 进行 “Networking” 是否会产生额外的费用？

A: Tailscale 提供了分层定价模式：

  1. 个人免费版：对于个人用户，支持在多达 100 台设备上使用，且包含无限的数据流量，非常适合家庭实验室、个人开发或远程管理。
  2. 商业付费版：如果用于企业环境，需要中心化的管理仪表盘、SSO 强制实施、日志审计等功能，则需要购买商业许可证。

对于文章中提到的将 Agents 连接到特定资源的场景，如果属于个人项目或小型测试，完全可以免费使用。

6: Tailscale 与 SSH（Secure Shell）有什么关系？它能替代 SSH 吗？

6: Tailscale 与 SSH（Secure Shell）有什么关系？它能替代 SSH 吗？

A: Tailscale 本身是一个网络层工具，但它包含了一个名为 Tailscale SSH 的功能，它确实可以替代传统的 SSH 守护进程。

传统的 SSH 需要您管理公钥/私钥、配置防火墙（开放 22 端口）并警惕暴力破解攻击。而使用 Tailscale SSH：

  • 无需开放端口：您不需要将服务器的 SSH 端口暴露在公网上。
  • 基于身份的认证：您不需要将 SSH 公钥复制到服务器上，只要您的 Tailscale 账户（通过 Google/GitHub 等）被授权，您就可以直接登录。
  • 无缝集成：它利用 Tailscale 的现有网络连接，使得连接过程更加安全和简便。

7: 如何在不同操作系统（如 Linux 服务器和 Windows 笔记本）之间通过 Tailscale 传输

7: 如何在不同操作系统（如 Linux 服务器和 Windows 笔记本）之间通过 Tailscale 传输

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在 Tailscale 网络中，假设你有两台设备：一台办公笔记本电脑和一台家庭 NAS。你希望通过 Tailscale 的 MagicDNS 功能，不依赖复杂的 IP 地址，而是直接使用设备名称进行 SSH 连接。请描述配置 ACL（访问控制列表）的最小必要步骤，以确保笔记本仅能访问 NAS，而无法访问网络中的其他 tagged devices（如服务器）。

提示**: 关注 Tailscale ACL 中的 action 字段以及如何使用 src 和 dst 来限定特定的用户或设备。

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章