云雀通 Larktun 博客，发布零信任组网、远程访问、Headscale、移动端访问、安全 SSH 与案例实践文章。
把一款 App 做给一群不同网络环境的人用，最难的地方不是功能本身，而是"进门"这一步。
有人用云雀通的托管网络，账户密码一输就进去了。有人习惯用密钥，一串字符即是身份。还有相当一部分人，他们的网络不在云雀通上——他们运行着自己的 Tailscale 网络，或者在某个 VPS 上维护着一套自建的 Headscale 服务。
让每一个人都能用自己的方式走进来，是云雀通 iOS App 从一开始就在考虑的事。
在 iPad 和 iPhone 上访问私有网络，过去常常意味着先打开系统 VPN，再切到 SSH 工具、SFTP 工具、浏览器或远程桌面工具。每个工具都能解决一小段问题，但真正使用起来，用户需要在多个 App 之间来回切换，还要时刻确认系统 VPN 有没有接上。
云雀通正在做一件更直接的事：把组网访问能力放进一个 App 里。
当前 iPad/iOS 版本已经提交上架审核，预计很快就能和大家见面。它不依赖系统 VPN 权限，而是在 App 内部接入云雀通网络，让用户在一个界面里查看设备、测试连接、SSH 登录、SFTP 管理文件，并直接打开内网 Web 服务。
在移动端做设备组网，系统 VPN 权限几乎是绕不开的话题。
无论是云雀通，还是 Tailscale，如果希望让手机上的所有应用都能访问一张私有网络，通常都需要创建系统级 VPN 隧道。这样做能力最完整：系统流量可以被接管，DNS、路由和应用访问都能统一进入同一张网络。但它也会带来一些现实阻力：用户需要理解并授权 VPN 配置，应用可能需要额外的系统能力，某些场景下还会和公司 VPN、校园网 VPN 或其它代理工具互相抢占系统入口。
那么有没有另一种路径：不申请系统 VPN 权限，也能把设备组网能力带到手机上？
答案是有的。关键在于 tsnet。
我最近申请了一台免费的甲骨文云服务器：4 核 CPU、24G 内存，作为开发服务器来说相当宽裕。它可以跑测试服务、构建任务、数据库实验环境，也可以在需要时临时承担一些生产辅助任务。
但只要这台机器要远程 SSH，一个经典问题就会立刻出现：要不要把 22 端口暴露到公网？
我的答案很明确：不要。
有时候，一个产品的起点，并不是宏大的蓝图，而是一件很小的事。
人在外面，忽然需要发布一段程序，修一个服务，或看一眼家里的机器。手边只有一只平板、一部手机，心里却惦记着那台安静放在桌角的电脑。若能像推开家门一样，轻轻连上它，该多好。
云雀通，就是从这样一个朴素的愿望里长出来的。
这篇文章展示在单实例 headscale 中实现多租户隔离的改造结果，重点覆盖 tailnet、ACL、路由、MagicDNS、CLI 和中继策略。
当 Headscale SaaS 需要扩容、维护或做负载再平衡时，核心问题是如何让用户在迁移时尽量“无感”。本文给出一套实战方案：动态路由 + 系统层精准断链 + 自动重连。
这篇文章分享 headscale 从单体到可线性扩展集群的核心改造路径：cluster_id 分片、共享 PostgreSQL、接入控制程序（ACS）、查询隔离与 netmap 增量化。
这篇文章整理了 headscale 在 200 客户端规模下的压测方法，包括环境建议、一键脚本、抖动测试和流量抽样流程。
原文链接： headscale系列：headsale压力测试
本文记录在 headscale 中启用 MagicDNS 的配置方法，以及 extra-records.json 的实践用法，方便在客户端通过主机名访问设备而不是直接记忆 IP。