# 03｜Linux 设备稳定连接计划

> 更新于 2026-10-08。本文件基于 Windows 客户端 `2024-bg-217` 的实时检查结果修订。目标为让 Linux 设备 `zrh-dracarys` 获得稳定的低延迟连接；中继服务只部署在 Linux 设备上，不部署在 Windows 客户端上。

## 1. 当前结论

当前 Windows 与 Linux 的 Tailscale 链路已经从先前的 UDP 直连退化为东京 DERP 中继，且直连建立不稳定：

| 检查项 | 2026-10-08 实测 |
| --- | --- |
| Linux 设备 | `zrh-dracarys` / Tailscale IP `100.99.232.7` |
| Windows 设备 | `2024-bg-217` / Tailscale IP `100.106.45.82` |
| `tailscale status` | `zrh-dracarys ... active; relay "tok"` |
| `tailscale ping 100.99.232.7` | 经 `DERP(tok)`，多数约 380–470ms，出现 990ms 和 2.736s |
| ping 最终状态 | `direct connection not established` |
| `tailscale netcheck` | `Nearest DERP: San Francisco`，无 `Home (Hangzhou)` |
| 公网 TCP 探测 | `112.10.227.73:8443` 在 5 秒内不可达 |
| 客户端 DERP map | 仅官方 region，不含自建 region 900 |

因此，当前故障有两层：

1. Windows 公司网络与家中 Linux 设备未能稳定完成 UDP 打洞，流量回退至 `relay "tok"`。
2. 已在 Linux 上运行的自建 `derper` 尚未成为可用的客户端中继：其公网 TCP 入口不可达，且 region 900 没有被写入 Tailnet 的 `derpMap`。

先前观察到的约 11ms 直连是真实的、但不是永久状态。它会在路由器重启、运营商/NAT 映射变化、公司网络策略变化或 UDP 状态超时后退化；触发路径发现后也可能重新直连。因此不要把一次直连成功当作网络已永久打通。

## 2. 网络与现有 Linux 部署

| 项目 | 值 |
| --- | --- |
| 家中 Linux 设备 | `zrh-dracarys`，Ubuntu 24.04.5 |
| Linux 局域网地址 | `192.168.31.145` |
| 光猫/路由器 | `192.168.31.1` |
| 家中公网 IPv4 | `112.10.227.73` |
| 自建 DERP 进程 | Linux 用户 `zrh` 的 `systemd --user` 服务 `derper` |
| DERP 数据端口 | TCP `8443`（TLS） |
| DERP STUN 端口 | UDP `3478` |
| DERP region | `900` / `Home (Hangzhou)` |
| 当前可用性问题 | `Linger=no`；Linux 重启且用户未登录时，用户级 `derper` 不会自动启动 |

自建 DERP 与 Linux 上的 Tailscale 服务是两回事：`derper -socket=/var/run/tailscale/tailscaled.sock` 能让本机 derper 与本机 tailscaled 协作，但**不会自动把 region 900 下发给同一 Tailnet 的其他设备**。客户端可选 DERP 列表来自 Tailscale 协调面下发的 DERP map；自建节点必须由 Tailnet 管理员添加到 policy 的 `derpMap`。

## 3. 推荐恢复顺序

### 优先级 1：恢复原生 UDP 直连

这是延迟与吞吐量最好的方案，也最少维护。为 Linux 的 Tailscale WireGuard 监听端口建立映射：

| 名称 | 协议 | 外部端口 | 内部地址 | 内部端口 |
| --- | --- | --- | --- | --- |
| Tailscale-direct | UDP | 41641 | `192.168.31.145` | 41641 |

前提是 Linux `tailscaled` 当前确实监听该端口（默认值通常为 UDP 41641；实施前用 `ss -ulnp | grep 41641` 核实）。同时为 `192.168.31.145` 保留 DHCP 静态租约，避免映射目标漂移。

映射后在 Windows 执行：

```powershell
tailscale ping 100.99.232.7
tailscale status
```

验收条件是 `status` 显示 `direct <公网IP>:<UDP端口>`，而非 `relay "tok"`；往返延迟应恢复到十几毫秒级。若仍经 DERP，则不要假设端口映射已成功，应先检查光猫规则、Linux 监听和本机防火墙。

### 优先级 2：使用 Tailscale Peer Relay

若公司网络持续阻止直连，优先采用 Tailscale 官方的 Peer Relay，而非继续扩展自建 DERP。Peer Relay 同样部署在 `zrh-dracarys` 上，但由 Tailscale 客户端本身提供转发能力：直连失败时，客户端会优先尝试它，再回落到 DERP。

前提：两端 Tailscale 版本至少 1.86（当前 Windows 为 1.102.4，满足要求）、Tailnet 管理员可编辑 policy、以及光猫可将一个 UDP 端口转发至 Linux。例如：

```bash
# 在 Linux 上执行；端口号仅作示例，须同时在光猫映射 UDP 40000。
tailscale set --relay-server-port=40000 \
  --relay-server-static-endpoints="112.10.227.73:40000"
```

随后在 Tailnet policy 中以精确的 `src` / `dst` 添加 `tailscale.com/cap/relay` grant，只授权公司设备使用该 Linux 中继。不要用 `*` 放开整个 tailnet。验证时 `tailscale status` 应显示 `peer-relay`。

### 优先级 3：保留自建 DERP 作为备用

自建 DERP 仍可行，适合无法使用 Peer Relay 或需要传统 DERP 行为的场景，但它不是第一选择，维护成本更高。完成条件如下：

1. 光猫映射 TCP `8443` 到 `192.168.31.145:8443`；可选映射 UDP `3478` 到同一主机以提供 STUN。
2. Linux 本机确认 `derper` 存活、TCP 8443 与 UDP 3478 均在监听，并确认 `/derpStatus` 返回 200。
3. 由 Tailnet Owner/Admin/Network admin 在 policy 的 `derpMap` 添加 region 900；仅靠 `-socket` 注册不够。
4. 使用稳定域名与受信任证书更省事；若使用 IP 自签证书，DERP node 必须带由 derper 日志输出的 `CertName: sha256-raw:<证书哈希>`，用于证书固定。证书重建后该哈希也要同步更新。
5. 解决 `Linger=no`：启用 `loginctl enable-linger zrh` 或改为系统级 systemd 服务，确保 Linux 重启后中继自动恢复。

自建 DERP 生效的必要验收为：公网 TCP 8443 可达、`tailscale debug derp-map` 中出现 region 900、`tailscale netcheck` 能看到 `Home (Hangzhou)`，并且断开直连后 `tailscale status` 回退到该 region 而不是 `tok`。

## 4. 当前自建 DERP 的建议 DERPMap 结构

以下为结构示意；`CertName` 必须以 Linux derper 当前日志实际输出的值替换，不能臆填或省略：

```json
{
  "derpMap": {
    "regions": {
      "900": {
        "regionID": 900,
        "regionCode": "home-hz",
        "regionName": "Home (Hangzhou)",
        "nodes": [
          {
            "name": "900a",
            "regionID": 900,
            "hostName": "112.10.227.73",
            "ipv4": "112.10.227.73",
            "derpPort": 8443,
            "stunPort": 3478,
            "certName": "sha256-raw:<从 derper 日志复制的哈希>"
          }
        ]
      }
    }
  }
}
```

提交 policy 后，在 Windows 检查：

```powershell
tailscale debug derp-map
tailscale netcheck
```

若 900 未出现，应先检查 policy 是否由正确的管理员账户保存、字段格式是否通过控制台校验，以及客户端是否已从控制面拉取新配置。不要在 region 未下发时反复重启 derper 或客户端。

## 5. 日常监控与触发条件

以下任一情况表示直连退化，应依次检查 UDP 41641 映射、Peer Relay / 自建 DERP 的可达性：

- `tailscale status` 对 `zrh-dracarys` 显示 `relay "..."` 而非 `direct ...`。
- `tailscale ping 100.99.232.7` 出现 `direct connection not established`，或延迟稳定高于约 100ms。
- Windows `tailscale netcheck` 的最近中继变为海外节点，且无法看到已配置的 `Home (Hangzhou)`。
- 路由器、光猫、Linux 或公司网络重启/切换后，远程 SSH、VSCode Remote-SSH 明显变慢。

建议在每次网络设备变更后记录一次：

```powershell
tailscale status
tailscale ping 100.99.232.7
tailscale netcheck
```

## 6. 参考与边界

- 自定义 DERP 的可用节点来自 Tailnet policy `derpMap`，并非本机自动广播。
- 当前 Tailscale 官方建议：频繁使用高延迟 DERP 时，优先考虑 Peer Relay；它通常比自建 DERP 延迟更低、维护更简单。
- 无论使用哪种中继，端到端数据仍由 WireGuard 加密；中继只转发密文。
- 本方案不建议在 Windows 公司网络侧设置入站映射；只需保证它能够向家中公网 UDP 端口发起出站访问。