# 02｜Linux 设备远程接入计划

> 目标设备：`zrh-dracarys`。本文定义客户端通过 Tailscale 与 SSH 接入 Linux 的网络与诊断计划；完成并验证的通用操作应沉淀至 `reference/远程接入/`。

## 一、目标

让新设备（Windows / macOS / Linux / 手机）加入同一个 tailnet 后，与杭州服务器 `zrh-dracarys` 建立 **UDP 直连**，而不是绕远路走 DERP 中继，并能在直连退化时自己排查和修复。

## 二、四条关键结论

1. **直连优先依赖 UDP 打洞。** 无端口映射时也可能直连，但不能保证持续稳定；当前已出现退化时，应按中继处置方案评估 Linux 侧 UDP 端口映射。
2. **打洞是懒惰的。** Tailscale 默认先走 DERP 中继，只有真正产生流量时才在后台尝试打洞。新设备装好后如果不主动发一次流量，路径不会自动升级成直连。
3. **最常见的失败原因：代理软件开了 TUN / 透明代理模式。** 这种模式会接管全部流量包括 UDP，打洞必然失败，只能退回中继。
4. **新设备必须有自己的 SSH 密钥。** 私钥永远不复制给别的设备，服务器只保存各设备的公钥。

---

## 三、历史环境基线（2026-09-30 实测，非当前状态）

| 项目 | 值 |
| --- | --- |
| 服务器 | `zrh-dracarys` / Tailscale IP `100.99.232.7` |
| 服务器公网 IP | `112.10.227.73`（光猫 WAN，光猫管理地址 `192.168.31.1`） |
| 服务器 NAT 层级 | 光猫后面，**无端口映射** |
| 当时直连端点 | `direct 112.10.227.73:13478`（UDP 临时端口，重连后会变） |
| 当时直连延迟 | `tailscale ping` **11ms** |
| `netcheck` 特征 | `UDP: true`、`MappingVariesByDestIP: true`、`IPv6: no, but OS has support` |
| 本机网卡 | `WLAN`（Intel AX201）+ `Tailscale Tunnel`，**无 TUN 网卡** |
| 当时代理方式 | SakuraCat 显式代理 `127.0.0.1:12450`，未开 TUN |
| 代理环境变量 | `HTTP_PROXY` / `HTTPS_PROXY` = `http://127.0.0.1:12450` |

---

## 四、新设备接入步骤

### 步骤 1：安装并登录

安装 Tailscale，登录与服务器相同的 tailnet 账户。新设备会被分配一个 `100.x.x.x` 地址。

### 步骤 2：确认设备已加入

```powershell
tailscale status
```

新设备应该出现在列表里。

### 步骤 3：主动触发路径发现（关键，不要跳过）

```powershell
tailscale ping 100.99.232.7
```

因为打洞是懒惰的，**必须主动发一次流量**才会去尝试建立直连。这一步做完通常几秒内出结果。

> 注意：本机 Tailscale 版本的 `tailscale ping` 只接受一个参数，不支持 `-c` 次数参数。

> 2026-10-08 更新：当前 `2024-bg-217` 到 `zrh-dracarys` 已退化为 `relay "tok"`，且 `tailscale ping` 报告过 `direct connection not established`。当前故障状态、优先恢复顺序和中继部署位置见 [Linux 设备稳定连接计划](03-Linux设备稳定连接.md)。

### 步骤 4：判定结果

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

**直连（成功）** 的输出特征：

```text
100.99.232.7   zrh-dracarys  linux  active; direct 112.10.227.73:xxxxx
pong from zrh-dracarys (100.99.232.7) via 112.10.227.73:xxxxx in 11ms
```

**中继（失败）** 的输出特征：

```text
100.99.232.7   zrh-dracarys  linux  active; relay "xxx"
pong from zrh-dracarys (100.99.232.7) via DERP(xxx) in 2xxms
```

---

## 五、判断直连是否健康的三个指标

| 命令 | 健康值 | 含义 |
| --- | --- | --- |
| `tailscale status` | 含 `direct` | 数据走点对点直连，不经中继 |
| `tailscale ping <服务器IP>` | `via <ip>:<port>`，几十毫秒内 | 打洞成功且链路通畅 |
| `tailscale netcheck` | `UDP: true` | 本机 UDP 出站可用，这是打洞的前提 |

`MappingVariesByDestIP: true` 表示 NAT 映射会随目标地址变化（对称型 NAT 特征）。Tailscale 内置了应对机制，能打洞成功，但成功率低于 cone NAT。

---

## 六、直连退化的常见原因与对策

| 现象 | 原因 | 对策 |
| --- | --- | --- |
| `netcheck` 显示 `UDP: false` | 本机网络封 UDP，或代理开了 TUN 模式接管了全部流量 | 关闭代理的 TUN / 透明代理，只保留系统显式代理；或换网络 |
| `status` 显示 `relay "xxx"` | 打洞失败，退回中继 | 走第七节诊断流程 |
| 刚连上很快又变回 `relay` | 空闲后 NAT 映射过期 | 重新 `tailscale ping` 一次即可恢复 |
| 时好时坏、反复切换 | 对称 NAT，或路由器 NAT 条目超时过短 | 换网络环境；或部署自建 DERP 做稳定兜底 |
| `IPv6: no` | 公司网未放通 IPv6 | 不影响 IPv4 直连，可忽略 |
| 新设备在手机热点 / 严格 NAT 网络上 | 网络环境不允许打洞 | 换网络，或接受中继延迟 |

---

## 七、代理软件的影响（最容易踩的坑）

### 为什么当前这台机器没受影响

SakuraCat 运行在**显式代理模式**：只在本机开一个 `127.0.0.1:12450` 的 HTTP 代理端口，程序需要走代理时自己指定。**它没有创建 TUN 虚拟网卡**，所以 UDP 流量原样通过，打洞正常。

### 怎么自查

Windows 上执行：

```powershell
Get-NetAdapter | Where-Object { $_.Status -eq 'Up' } | Select-Object Name, InterfaceDescription
```

只出现 `WLAN`（或以太网）和 `Tailscale Tunnel` 就是正常的。**如果多出 `SakuraCat` / `Mihomo` / `utun` / `Clash` / `Wintun` 之类的虚拟网卡，说明 TUN 模式开着，UDP 会被劫持，直连必然失败。**

### 环境变量要不要清掉

`HTTP_PROXY` / `HTTPS_PROXY` 这类环境变量只影响 **HTTP 请求**，Tailscale 的 UDP 打洞不经过它们，**可以保留**。它们的作用是让 HTTP 类程序（curl、git、pip、apt）走代理，两者互不干扰。

---

## 八、诊断流程（新设备连不上时照着走）

```powershell
# 1. 基础连通性：本机能上 Tailscale 吗
tailscale status

# 2. 本机 UDP 出站是否可用（关键前置条件）
tailscale netcheck

# 3. 主动触发打洞
tailscale ping 100.99.232.7

# 4. 看路径判定
tailscale status

# 5. 有没有多余虚拟网卡（TUN 劫持）
Get-NetAdapter | Where-Object { $_.Status -eq 'Up' } | Select-Object Name, InterfaceDescription
```

按结果对照：

| 步骤 2 `UDP:` | 步骤 4 路径 | 结论与下一步 |
| --- | --- | --- |
| `true` | `direct` | 直连正常，无需处理 |
| `true` | `relay` | 打洞失败，把步骤 3 的输出和步骤 5 的网卡列表一起排查 |
| `false` | `relay` | UDP 出站被阻断，先解决网络或关闭 TUN 模式 |

---

## 九、彻底无法直连时的降级方案

按优先级：

1. **同局域网直连** —— 如果新设备和服务器接在同一个路由器下，走 `192.168.31.145` 内网地址，延迟最低，完全不依赖 NAT 穿透。
2. **换网络环境** —— 换一个允许 UDP 出站的网络（家庭宽带、4G/5G 热点通常比严格企业网友好）。
3. **启用 Linux Peer Relay 或自建杭州 DERP** —— 按 [Linux 设备稳定连接计划](03-Linux设备稳定连接.md) 的优先顺序实施。两者均需光猫端口映射；Peer Relay 是当前优先的中继兜底。

走 DERP 中继的代价：当前本机经 SakuraCat 美国出口时，中继延迟在 200-500ms，远程编辑和终端交互会明显卡顿。

---

## 十、新设备登记表

每接入一台设备，建议记录一行，作为以后排查的基线：

| 设备名 | 系统 | Tailscale IP | 连接方式 | ping 延迟 | 排查结论 | 备注 |
| --- | --- | --- | --- | --- | --- | --- |
| 2024-bg-217 | Windows | `100.106.45.82` | 当前 `relay "tok"` | 约 380–470ms（波动更高） | 直连退化 | 公司网，代理显式模式；见中继处置方案 |
| zrh-dracarys | Ubuntu 24.04 | `100.99.232.7` | 服务端 | - | - | i5-10210U / 16G |
|  |  |  |  |  |  |  |

---

## 附录：常用命令速查

| 命令 | 作用 |
| --- | --- |
| `tailscale status` | 看所有节点和连接方式（`direct` / `relay` / `offline`） |
| `tailscale ping <IP>` | 触发路径发现并显示实际走法与延迟 |
| `tailscale netcheck` | 检测 UDP 可用性、最近 DERP、NAT 类型 |
| `tailscale ip -4` | 看本机 Tailscale IP |
| `ssh zrh-server` | 连接服务器（走 `~/.ssh/config` 里的别名） |
| `Get-NetAdapter \| Where-Object Status -eq 'Up'` | Windows 上排查 TUN 劫持 |

## 关联文档

- [Linux 设备稳定连接计划](03-Linux设备稳定连接.md) —— 双 NAT 下部署 Linux Peer Relay / 自建 DERP 的备用方案
- [SSH 密钥与 Root 维护规范](../reference/远程接入/SSH密钥与Root维护规范.md) —— SSH 公钥认证的通用配置流程
- [2024-bg-217 接入 Linux 记录](../reference/设备接入记录/2024-bg-217接入Linux记录.md) —— 该设备的实际配置记录