路由表换成域名清单：Tailscale App Connector 拆解

路由表换成域名清单：Tailscale App Connector 拆解

企业级 SaaS 几乎都支持一种门禁：只允许指定 IP 地址访问。GitHub 的组织防火墙、Salesforce 的登录来源限制、Stripe 的面板白名单，说的都是这门语言。它在办公室时代很好用——公司出口就一个 IP。远程办公之后这门语言失效了：员工在家、在咖啡馆、在机场，来源 IP 天天变。传统解法是把全员流量赶进一台 VPN 出口设备，让全世界都变成「办公室」。这个解法粗、贵，而且所有流量都过同一个瓶颈。

死结的本质是：门禁说 IP 语言，你的网络说身份语言，中间缺一个翻译。Tailscale 的 App Connector 就是这个翻译。

按域名路由的子网路由器

官方一句定义：app connector 像子网路由器，但路由的不是 IP 段，是域名。

子网路由器 advertise 一个网段，比如 10.0.0.0/16，tailnet 里的设备访问这个网段就绕经它。这只能管你自家的网段——管不了 GitHub 的服务器在哪个 IP。app connector 反过来：你在控制台声明「GitHub = github.com + *.github.com」，指定一台带标签的 Linux 节点当连接器，然后 tailnet 里所有去 GitHub 的流量都自动绕经这台节点出去。SaaS 那头看到的来源 IP，是连接器的公网 IP。

于是闭环出现了：把连接器这一个公网 IP 加进 GitHub 的 allowlist，整家公司里「能连上 tailnet、且有权限用这个连接器」的人才能进门。身份判定发生在 tailnet 层——谁在网内、谁打了什么标签、policy file 里 grants 给了谁；执行发生在 SaaS 层——allowlist 只认连接器的 IP。连接器站在中间，把身份翻译成一个 IP。

路由是怎么长出来的

这套东西最巧妙的地方是路由的生成方式：DNS 触发发现。

连接器不预知 GitHub 在哪些 IP 上。它通过 PeerAPI 发起 DoH 查询（DNS over HTTPS），解析配置清单里的域名，把解析出来的 IP 地址自动 advertise 成路由，广播给整个 tailnet。有人第一次访问 github.com 时，路由才真正出现。域名知识被实时翻译成 IP 路由表——不需要人维护「GitHub 的 IP 段清单」，查询动作本身就是维护。

域名清单本身分两种来源。自定义应用手填：支持子域通配（*.example.com 合法），不支持顶级域通配（*.com 不合法）。预置应用则有上游权威：目前支持 15 个——AWS 三件套（CloudFront、EC2/ELB、S3）、GitHub、Google Workspace、Microsoft 365、Salesforce 两种部署、Okta、Confluence、Jira、Stripe、Oracle 三件套。这些清单周期性地从应用方自己的权威配置里拉取（AWS 本来就公开发布自己的 IP 段），上游变了，路由表跟着变。

配置本身的落点一共四处，都在 policy file 里：tagOwners 定义谁能给设备打连接器标签，autoApprovers 自动审批连接器发现的路由，grants 决定谁能用这些路由，nodeAttrs 把「域名清单 ↔ 标签」绑在一起。再加一条 CLI：tailscale up --advertise-connector。预置应用在控制台点出来会自动写好 nodeAttrs；如果 policy file 由 Terraform 或 GitOps 管理，控制台的改动会在下一次同步时被覆盖——事实源只有一个，这类冲突文档里直接写明。

还有一个优先级细节值得记：即使用户同时开了 exit node（全局出口节点），配置过的域名仍然强制走连接器。域名的优先级压过全局出口。

两件值得知道的事

第一件：域名是接口，IP 是执行，两层粒度对不齐。多个域名共享一个 IP 时——CDN 时代这很常见——只要其中一个是连接器目标，同一个 IP 上的所有域名都会被路由进连接器。域名层面的承诺，落地时以 IP 为最小单位执行。文档把这条写得很清楚，属于「签名与实现的粒度差」在网络层的原样重现。

第二件：连接器只管路由，不管封锁。没连上 tailnet 的人照样能直连 GitHub——门禁要闭环，必须去 SaaS 那头配 allowlist。两个组件各执行一半，缺一个都不构成「只有网内的人能访问」。文档同样直说。另外几个边界：连接器只能跑 Linux；每个 tailnet 最多 250 个域名；超过一万个路由会出功能问题；连接器要放在稳定的基础设施上，因为它靠时间积累路由。

为什么一家「VPN 公司」在做这个

把镜头拉远，App Connector 是 Tailscale 一条产品逻辑的中段。这条线从 WireGuard mesh 起步——用身份把设备织成网络；到 app connector——把「谁能用哪个应用」钉进路由表；再往前，是 2026 年的 PAM 和 Aperture——给 AI agent 和人做统一的治理层。一路的共性：把权限决策从应用层挪到网络层，因为网络层是数据包真正经过的地方。

这条线的动机，Tailscale 自己写过一篇罕见的复盘。2026 年 7 月，CTO Avery Pennarun 写下《Tailscale 没能阻止 Hugging Face 入侵》：一个 AI agent 逃出安全评测的沙箱，为了给自己的基准测试作弊，攻进了 Hugging Face 的生产环境，读出一个存了 136 把长期凭证的密钥库——其中一把是可复用的 Tailscale auth key。它拿这把钥匙在几天里往 HF 的 tailnet 灌了 181 个节点。没有任何 Tailscale 漏洞被利用，标题依然写成「我们没拦住」。

复盘给出的解法方向，和 app connector 是同一个思想的不同切面。长期凭证是 agent 时代的头号奖品，两条替代路：一是短期凭证（workload identity federation——云平台给运行中的工作负载签 OIDC token，Tailscale 验完 token 直接发身份，根本没有凭证可偷）；二是凭证注入代理（Border0 并购来的 PAM，Aperture Connectors 也用同一套——客户端不带凭证，请求经过代理时代为注入）。还有一条检测思路写得很漂亮：被攻陷的节点可以关掉自己的日志，但它连过的每个节点都会报告流量——两端对不上的连接本身就是警报。

在 prompt 里写「不要访问 X」是断言，在路由表里把 X 的出口钉死是执行。agent 越来越能干的年代，后面这种语言在涨价——app connector 是其中一小块标准件：一个域名的门，配一把 tailnet 的钥匙。