内网穿透 on 寻 Mi 处

卸载了向日葵和 ToDesk，我用 Tailscale 连回了家里的电脑

Tue, 10 Mar 2026 18:25:00 +0800

我出门在外的时候，经常要连回出租屋里的台式机。

有时候是要跑一个本地才有的编译环境，有时候是要从家里那台机器上拷个文件，有时候纯粹是想用大屏幕看个东西。

最早用的是向日葵，免费版画质一般，而且经常提示"当前为免费通道，画质受限"。后来换了 ToDesk，好一些，但免费版有连接时长限制，一个月四十小时，用超了就得等。

更让我介意的是，这两个软件都要经过它们自己的服务器中转。我不知道我的屏幕画面在中间经过了什么，这让我不太舒服。

后来在论坛上看到有人提 Tailscale，说是基于 WireGuard 的组网工具，免费版给一百个设备。我试了一下，之后就再也没打开过那两个软件。

它解决的是什么问题

先说清楚它不是什么。

它不是远程桌面软件。它做的是组网，让你的设备之间能像在同一个局域网里一样互相访问。

组好网之后，你可以用任何远程桌面工具连过去，Windows 自带的 RDP、macOS 的屏幕共享、VNC、甚至 ssh -X。因为从系统的角度看，对面就是局域网里的另一台机器。

它也不是传统的 VPN。传统的 VPN 是星型结构，所有流量都经过中心服务器。Tailscale 是网状结构，两台设备之间尽量直连，服务器只负责协调和 NAT 穿透。

这个区别很重要。直连意味着低延迟，也意味着数据不经过第三方。

底层是 WireGuard

WireGuard 是这几年很火的一个 VPN 协议，已经进了 Linux 内核。它的特点是代码量小、性能好、配置简单。

Tailscale 用的是 WireGuard 做数据平面，自己做了控制平面。控制平面负责设备注册、密钥分发、NAT 穿透协调。数据平面是设备之间的 WireGuard 隧道。

所以它的流量是端到端加密的，中间没有任何人能看懂。就算是 Tailscale 自己的服务器，也只能看到谁和谁在通信，看不到内容。

这个架构比传统的 VPN 好很多，也比那些中转式的内网穿透工具好。

装

官网下载对应平台的安装包，一路下一步。

Windows、macOS、Linux、iOS、Android、甚至群晖和 OpenWrt 都有客户端。

Linux 上最方便的是官方脚本：

`1`	`curl -fsSL https://tailscale.com/install.sh \| sh`

它会自动识别发行版，配好软件源，装完就能用。

把第二台也接进来

同样的流程，装完登录同一个账号。

登录之后，两台设备之间就通了。在 A 上 ping 100.x.x.x（B 的地址）应该能通。

`1`	`tailscale status`

这个命令能看到所有设备的状态，包括是否直连、延迟多少。

1
2
3

100.64.0.1   desktop-win    mingyue@  windows  -
100.64.0.2   laptop-mac     mingyue@  macOS    active; direct 192.168.1.5:41641, tx 1234 rx 5678
100.64.0.3   vps-hk         mingyue@  linux    active; relay "hkg", tx 999 rx 888

direct 表示两台设备直连，后面的地址是实际的公网 IP 和端口。relay 表示没能直连，走了中继，延迟会高一些。

MagicDNS

Tailscale 有个功能叫 MagicDNS，它会给每台设备分配一个域名，形如 设备名.你的账号名.ts.net。

开了之后，你不需要记 IP，直接用名字访问：

1
2

ping desktop-win
ssh laptop-mac

这个在设备多了之后特别方便。IP 是会变的，名字不会。

在后台的 DNS 页面里开启。开启之后，Tailscale 会接管设备的 DNS 解析，把 *.ts.net 的查询指向自己的解析器。

这个接管可能会和你的其他 DNS 配置冲突。如果你用了 Pi-hole 或者自定义的 DNS，要注意一下。

远程桌面

组好网之后，远程桌面就简单了。

Windows 那边，先在系统设置里开启"远程桌面"，然后在另一台机器上：

`1`	`mstsc /v:desktop-win`

或者用 Microsoft Remote Desktop 客户端，地址填 desktop-win 或者 100.64.0.1。

macOS 那边，开启"屏幕共享"，然后：

`1`	`open vnc://laptop-mac`

Linux 上可以用 xrdp 或者 gnome-remote-desktop。

我平时用的是 Windows 自带的 RDP。画质可以调，延迟低，而且支持多显示器。比那些第三方软件流畅多了。

subnet router：让整个局域网都通

这是我最喜欢的功能。

Tailscale 默认只让你访问装了客户端的设备。但如果你家里有一台 NAS、一台打印机、一个树莓派，不可能每台都装客户端。

subnet router 的作用是，让一台设备充当网关，把整个局域网的路由转发出去。

在家里那台常年开着的小主机上：

echo 'net.ipv4.ip_forward=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

sudo tailscale up --advertise-routes=192.168.1.0/24

然后在后台的 Machines 页面，找到这台设备，点右边的三个点，选 “Edit route settings”，把 192.168.1.0/24 勾上。

之后你在外面，就能直接访问 192.168.1.x 下面的任何设备了。NAS、打印机、路由器管理页，全都能打开。

这个功能让我出门在外的时候，感觉像是回到了家里的局域网。

注意，--advertise-routes 要在 tailscale up 的时候传，不是单独的命令。如果之前已经 up 过了，要重新跑一次。

exit node：把流量都走家里

这个功能更激进一点。

配了 exit node 之后，你所有设备的出网流量都会经过家里那台机器出去。相当于你人在外面，但网络出口在家里。

用处有两个。

一个是访问那些限制地区的服务。比如某些流媒体只允许家庭宽带 IP 访问。

另一个是安全性。在咖啡厅的公共 Wi-Fi 上，所有流量都走加密隧道回家，不用担心被人抓包。

配置：

`1`	`sudo tailscale up --advertise-exit-node`

然后在后台勾上 “Use as exit node”。

客户端那边选择使用这个 exit node：

`1`	`sudo tailscale up --exit-node=100.64.0.1 --exit-node-allow-lan-access`

--exit-node-allow-lan-access 是让本地局域网的访问不走隧道。不加的话，你连本地打印机都会绕到家里去。

Windows 和 macOS 的客户端有图形界面，在菜单里选就行。

ACL：控制谁能访问谁

免费版也支持 ACL，用的是类似 JSON 的配置语言。

默认的 ACL 是允许所有设备互相访问。如果你只想让自己访问，别人不行，就得改。

在后台的 Access Controls 页面：

{
  "acls": [
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["*:*"]
    }
  ],
  "ssh": [
    {
      "action": "check",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot"]
    }
  ]
}

autogroup:member 是账号下的所有成员。autogroup:self 是设备的所有者自己。

上面的配置意思是，所有成员可以访问所有设备的所有端口，但 SSH 只能访问自己的设备。

如果给家里人开了子账号，可以限制他们只能访问特定设备：

{
  "acls": [
    {
      "action": "accept",
      "src": ["user1@"],
      "dst": ["nas:445,5000"]
    }
  ]
}

这样 user1 只能访问 NAS 的 SMB 和 Web 端口，别的都不行。

速度到底怎么样

我测过几次。

从公司连回家里，两台机器都在国内，走的是直连。延迟在二十到四十毫秒之间，取决于公司的网络质量。这个延迟下用 RDP 基本感觉不到卡。

从国外连回来，延迟会高一些，一百多毫秒。看视频还行，操作桌面会有点迟钝。

速度方面，家里的宽带上行是一百兆，实测通过 Tailscale 传输能跑到七八十兆。这个速度对于传文件来说够用了。

如果没打通直连，走中继的话，速度会降到十几兆，延迟也会高一些。所以看 tailscale status 里是不是 direct 很重要。

几个坑

DNS 冲突。开启 MagicDNS 之后，它会接管系统的 DNS。如果你有自定义的 DNS 服务（比如 Pi-hole），可能会冲突。可以在 tailscale up 的时候加 --accept-dns=false 关掉。

Android 上的省电策略。很多国产 ROM 会把 Tailscale 的后台进程杀掉，导致连不上。要在系统设置里给它加白名单，允许后台运行。

子网路由不生效。多半是没在后台勾选。--advertise-routes 只是宣告，还需要在管理后台批准。这一步很多人会漏。

iOS 上的 VPN 图标常亮。这是正常的，Tailscale 在 iOS 上是以 VPN 的形式工作的。电量消耗会比平时多一点，但不算严重。

多网卡环境。如果机器上有多个网卡（比如同时连了有线和无线），有时候会出现路由混乱。可以用 --netfilter-mode=off 关掉自动的防火墙规则，自己配。

免费版够不够

免费版叫 Personal，给三个用户、一百个设备。

对于个人用来说，一百个设备根本用不完。三个用户，家里人也够。

付费的 Starter 是六个美元一个月，给更多用户和高级功能（比如设备审批、日志导出）。

我觉得个人用免费版完全够。除非你是在公司里推广，需要审计日志之类的。

现在的状态

我现在的设备列表里，一台 Windows 台式机、一台 MacBook、一台 Linux 小主机、两部手机、还有一台香港的 VPS，全都接在里面。

出门在外的时候，随时能连回家里。VPS 上跑的服务也不用暴露公网，直接从 Tailscale 内网访问。

这套东西彻底替代了我之前用的那堆内网穿透工具。而且它是基于标准协议的，万一哪天 Tailscale 这个公司不行了，WireGuard 本身还在，可以自己搭一套。

这种不完全依赖某一家公司的感觉，挺好。

家里那台小主机没有公网 IP，我用 Cloudflare Tunnel 把它挂上了网

Thu, 29 Feb 2024 19:44:00 +0800

搬进新租的房子之后，第一件让我难受的事就是宽带没有公网 IP。

装机师傅上门那天我特意问了，他说现在都这样，上面统一做的 NAT，想开端口得另外找客服申请，而且就算申请下来也是动态的，重启光猫就换一个。我试着在路由器上拨号看了一下，WAN 口拿到的是 100.64.x.x，运营商级 NAT 的内网地址，彻底没戏。

问题是我家里有台常年开着的小主机，跑着几个自己写的小服务。一个是用来看照片的相册，一个是给家里人用的备忘录，还有一个是给小孩做的手工课视频站。以前在旧房子那边有公网 IP，路由器上做个端口映射，出门在外随时能打开。现在全断了。

试过的几种方案

先说被排除的。

花生壳那类内网穿透我最早试过，免费版带宽小得可怜，而且域名是一长串随机字符，发给家里人他们根本记不住。付费版按年收费，我看了一眼价格，不如直接买台有公网 IP 的 VPS。

frp 我用了差不多一年。自己在香港买了台 1 核 1G 的小机器当跳板，家里跑 frpc，外面跑 frps。能用，但有几个麻烦。跳板机的带宽是个硬瓶颈，我买的那台是 30M 峰值，实际晚上跑起来经常掉到 5M 以下，看个视频就卡。而且这台机器我得自己维护，系统更新、证书续期、被扫了还得上去看看，一年下来也是一笔精力。

后来在 V2EX 上看到有人提 Cloudflare Tunnel，我一开始以为是那种要企业套餐的付费功能，点进去看了才知道，免费版也能用，而且不限流量。这个就值得试了。

它到底是怎么工作的

原理说起来很简单。

cloudflared 这个程序装在你的内网机器上，它主动往外连 Cloudflare 的边缘节点，建立一条长连接。这条连接是出站的，所以你不需要有公网 IP，也不需要动路由器上的任何设置。外面的人访问你的域名，请求先到 Cloudflare，Cloudflare 顺着这条已经建好的隧道把请求送进来，你的机器响应之后再原路返回。

因为隧道是 cloudflared 主动发起的，中间不存在任何入站端口，家里的防火墙和运营商的封禁都不受影响。

还有个好处是，你不需要在路由器上开任何端口。以前做端口映射的时候，我总担心哪天路由器固件有漏洞被人扫到，现在这条路直接堵死了。

装起来

我的小主机是 Debian 12，直接加官方源装最省事。

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install cloudflared

装完 cloudflared --version 能出版本号就行。

接下来登录。这一步会给你一个很长的链接，你得复制到浏览器里打开：

`1`	`cloudflared tunnel login`

浏览器里会让你选一个域名授权。我的域名在 Cloudflare 上托管，选它，然后它会自动在你的 DNS 里加一条 cert.pem 用的授权。授权文件落在 ~/.cloudflared/cert.pem。

注意这个 cert 是按域名授权的，一个域名一个文件。如果你有多个域名都要用，得分别登录一次。

创建隧道和配置

`1`	`cloudflared tunnel create homelab`

它会生成一个 UUID，并且在 ~/.cloudflared/ 下面放一个同名的 json 文件，里面是隧道的凭据。这个文件是密钥，别传 GitHub 上去。

然后写配置文件，位置在 ~/.cloudflared/config.yml：

tunnel: homelab
credentials-file: /home/mingyue/.cloudflared/8f3c1a2b-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

ingress:
  - hostname: photo.mibase.top
    service: http://127.0.0.1:8081
  - hostname: note.mibase.top
    service: http://127.0.0.1:8082
  - hostname: craft.mibase.top
    service: http://127.0.0.1:8083
  - service: http_status:404

ingress 是从上往下匹配的，最后那条兜底必须写，不然配置检查会报错。

还有一个细节，如果你内网的服务绑的是 0.0.0.0，用 127.0.0.1 也没问题。但如果服务只监听 IPv6，就得写成 http://[::1]:8081。

把 DNS 指过去

1
2
3

cloudflared tunnel route dns homelab photo.mibase.top
cloudflared tunnel route dns homelab note.mibase.top
cloudflared tunnel route dns homelab craft.mibase.top

它会自动在 Cloudflare 里加 CNAME，指向 <UUID>.cfargotunnel.com，并且是橙云状态，也就是走代理。

这三条加完，DNS 那块就不用手动动了。

跑成服务

前台跑着测试没问题之后，换成 systemd 托管：

1
2

sudo cloudflared service install
sudo systemctl enable --now cloudflared

然后看状态：

1
2

sudo systemctl status cloudflared
sudo journalctl -u cloudflared -f

日志里能看到四条连接建起来的信息。Cloudflare 默认会建四条，冗余用的，一条断了另外几条顶上，切换的时候用户基本无感。

访问控制和登录验证

隧道跑通之后，第一个冒出来的念头是：这玩意儿是不是谁都能访问。

是的，默认就是公开的。所以我立刻去配了 Cloudflare Access。

在 Zero Trust 后台里，Access 下面的 Applications，新建一个 Self-hosted 应用。域名填 note.mibase.top，然后建一条策略，Action 选 Allow，Include 里选 Emails，把我自己和家里人的邮箱填进去。

配完之后再访问，会先跳到一个 Cloudflare 的登录页，输入邮箱收验证码，通过了才放行。免费版给五十个用户，够用了。

给小孩看的视频站我没加验证，那个本来就是想分享给亲戚的，加了反而麻烦。

顺手做的一件事

既然流量都过 Cloudflare 了，缓存规则也可以顺手配上。视频站的封面图我设了一年的 Edge TTL，这样重复访问基本不消耗回源带宽。

这个和博客那边是同一套思路，静态的东西缓存长一点，动态的别缓存。

和 frp 比到底差在哪

用了一个多月，我的感受是这样的。

带宽上 Cloudflare 明显强。它是全球任播，国内访问会落到就近的节点，实际测下来晚上也能跑满我家的上行。frp 那台跳板机受限于单机带宽，这点没法比。

省心程度上也是 Cloudflare 好。跳板机不用自己维护，证书它帮你签，系统补丁不用管，被打也不用管。这一点对我这种懒得折腾的人来说很重要。

但也不是没代价。

延迟会比直连高一些，毕竟多绕了一层。我在家用局域网访问，走的是本地地址，没影响；在外面访问大概多二十毫秒，日常用感觉不出来，但如果你要跑远程桌面，那点延迟是能感觉到的。

另外就是把一部分控制权交出去了。域名、证书、访问日志都在 Cloudflare 那边。真要哪天它改政策或者涨价，迁移的成本不算低。所以我一直保留着 frp 的配置没删，算是个备份方案。

还有一点，免费版对 WebSocket 的支持是有的，但长连接有时候会被掐。我那个相册里的实时同步功能就偶尔断，后来改成轮询才稳定下来。

遇到的两个坑

一个是 cloudflared 的内存占用。这东西跑久了会慢慢涨，我有一次看它吃了 400 多兆。后来加了个定时重启，每天凌晨重启一次，问题就没了。官方 issue 里也有人反馈过，看起来还没彻底修。

另一个是回源协议。我的服务是 http，如果 service 写成 https://127.0.0.1:8081，会报 TLS 握手失败。改成 http:// 就好。这个错我当时找了半天，因为日志里只写了个 502，没提 TLS。

现在的情况

三个服务稳定跑了一个多月，家里人也习惯了直接输域名访问，不再问我"那个链接是多少"。

回头看，这件事最舒服的地方不是技术多新，而是它把一件需要长期维护的事情变成了不用管的事情。以前跑 frp，我每个月至少要看一眼那台跳板机，现在这块彻底从我待办里消失了。