Tailscale 自建 DERP 中继服务器
Tailscale 自建 DERP 中继服务器
第一部分：架构深度解析用
在着手部署之前，必须深刻理解 Tailscale 的连接机制以及 DERP 服务器在其中扮演的关键角色。这不仅有助于正确执行部署步骤，更能清晰地认识到为何自建 DERP 服务器是解决国内高延迟问题的有效方案。
1.1 DERP 的双重身份：连接中介与流量中继
Tailscale 的 DERP 服务器承担着两个截然不同的核心职能：一是作为连接协商的“中介”，二是作为无法直接连接时的“流量中继” 。
- 连接中介（Connection Broker）：在绝大多数情况下，当两个 Tailscale 节点尝试建立连接时，它们首先会联系各自延迟最低的 DERP 服务器。DERP 服务器此时的角色是帮助双方交换建立直接连接所需的信息，例如对方的公网 IP 地址、端口以及 NAT 类型等。这个过程使用了 Tailscale 的 DISCO 协议（Discovery Messages），交换的数据包被称为 DISCO 包 。一旦双方成功利用这些信息“打穿”各自的 NAT 并建立起直接的 WireGuard 隧道，DERP 服务器的任务便告一段落，后续的通信流量将以点对点（Peer-to-Peer）的方式直接传输。
- 流量中继（Traffic Relay）：然而，在某些复杂的网络环境下，例如设备位于“硬 NAT”（Hard NAT）或对称 NAT 之后，或者网络防火墙策略异常严格，导致无法建立直接连接时，DERP 服务器将作为最后的备选方案介入 。此时，两个节点之间的所有通信流量都会被各自的 WireGuard 协议加密后，发送到 DERP 服务器，再由 DERP 服务器转发给对方。在这个模式下，DERP 服务器扮演了数据包的中转站。值得强调的是，由于 Tailscale 的私钥永远不会离开设备，所有流经 DERP 服务器的流量都是端到端加密的。DERP 服务器仅能“盲目地”转发这些已经加密的数据包，无法解密其内容，从而保证了通信的私密性。
理解这一双重身份至关重要。对于在中国大陆的用户而言，自建 DERP 服务器不仅能为无法直接连接的设备提供一个低延迟的流量中继路径，还能为所有设备（即使是那些最终能建立直接连接的设备）提供一个快速、可靠的初始连接协商“会面点”，从而全面提升整个 Tailnet 的响应速度和连接建立成功率。
1.2 连接的生命周期：直接路径与中继路径的抉择
Tailscale 的设计哲学是优先尝试最高效的连接方式。因此，任何两个节点间的连接生命周期都遵循一个明确的逻辑：所有连接都始于中继模式，然后尽力转向直连模式 。
-
启动与协商：当节点 A 想要与节点 B 通信时，它们都会首先连接到各自选定的“归属” DERP 服务器。节点 A 通过 DERP 服务器向节点 B 发起连接请求和直接连接的详细信息请求 。
-
NAT 穿透尝试：在通过 DERP 中继初步通信的同时，两个节点会并行开始执行一系列复杂的 NAT 穿透策略，例如使用 STUN 协议探测自身的公网 IP 和端口，并尝试在各自的防火墙或路由器上“打洞” 。
-
路径选择：
-
成功：如果 NAT 穿透成功，节点 A 和 B 会建立一个直接的、点对点的 UDP 隧道。此时，它们会停止通过 DERP 服务器发送主要的数据流量，切换到这条延迟更低、吞吐量更高的直接路径 。
-
失败：如果由于网络限制（如硬 NAT）导致 NAT 穿透在多次尝试后仍然失败，连接将永久地保持在中继模式，在整个通信会话期间都依赖 DERP 服务器转发所有数据包 。
-
1.3 国内的延迟挑战：为何官方 DERP 服务器并非最优解
Tailscale 在全球部署了多个 DERP 服务器集群，包括香港、东京、新加坡等亚太地区节点，旨在为用户提供低延迟的连接服务。Tailscale 客户端会自动检测并连接到延迟最低的 DERP 服务器。然而，对于身处国内的用户，这一自动选择机制往往会遇到以下挑战：
- 物理与网络距离：尽管香港和东京在地理位置上相对较近，但数据包从中国大陆运营商网络到这些境外服务器的实际网络路径可能非常曲折，需要经过多个国际出口和复杂的路由交换，导致往返延迟（RTT）居高不下，通常在 150ms 到 300ms 甚至更高。
- 网络审查与干扰：进出中国大陆的国际网络流量会受到网络防火墙（GFW）的深度包检测和流量整形影响。这可能导致连接不稳定、丢包率增高，甚至在特定时期出现连接被阻断的情况。
- 运营商路由策略：不同运营商（如中国电信、中国联通、中国移动）的国际出口路由策略各不相同，某些路径可能在高峰时段变得异常拥堵，进一步恶化了连接质量。
因此，即使 Tailscale 客户端选择了理论上“最近”的香港 DERP 服务器，实际体验到的延迟和稳定性也远不如预期。通过在位于中国大陆境内、拥有良好网络质量的云服务器上部署一个私有 DERP 服务器，用户可以将这个关键的“中介”和“中继”节点置于自己的控制之下，并置于与自己客户端相同的网络环境中。这将使得：
- 中继延迟最小化：对于必须通过中继传输的流量，数据包只需在境内云服务商的高质量网络中流转，延迟可以从数百毫秒降低到 10-50 毫秒的水平。
- 连接协商加速：所有节点的初始连接握手都将通过这个境内的低延迟服务器进行，极大地缩短了建立连接所需的时间，提升了整个 Tailnet 的操作响应速度。
第二部分：部署前分析与服务器准备
成功的部署始于周密的准备。本节将对用户提供的服务器配置进行评估，并详细阐述部署 DERP 服务器所需的全部前提条件，包括域名、DNS、防火墙和基础安全设置。
2.1 云服务器：2核/2GiB/4Mbps
云服务器配置为 2核 CPU、2 GiB 内存、40 GiB 存储空间和 4 Mbps 公网带宽。
- CPU 与内存：2核 CPU 和 2 GiB 内存对于运行一个个人或小团队使用的 DERP 服务器来说是绰绰有余的。
derper进程本身是一个轻量级的 Go 程序，资源消耗较低。Tailscale 的性能优化研究表明，对于网络转发任务，更高的 CPU 单核主频通常比更多的核心数更重要。该配置足以处理加密流量的转发和连接协商。 - 存储空间：40 GiB 的存储空间也完全足够。DERP 服务器主要处理实时流量，几乎不产生持久化数据存储需求。
- 带宽（关键限制因素）：4 Mbps 的公网带宽是这台服务器最主要的性能瓶颈。需要明确的是，这个带宽上限将直接决定所有通过此 DERP 服务器进行中继的流量的最大吞吐量。4 Mbps 约等于 512 KB/s (4×1024/8=512)。考虑到网络协议的开销，实际可用的数据传输速率会略低于此值，大约在 450-500 KB/s 之间。
这意味着，虽然部署此服务器能够显著降低延迟（例如，SSH 远程操作会变得非常流畅），但对于需要高吞吐量的任务（例如，通过中继连接传输大文件、观看高清视频），其速度将被严格限制在 4 Mbps 以内。在第六部分中，将对此进行更详细的性能分析。
2.2 核心前提：域名、DNS 与 TLS 证书
DERP 服务是基于 HTTPS 协议构建的，这意味着它需要一个合法的域名和相应的 TLS 证书才能安全运行。在没有有效 TLS 加密的情况下，客户端将无法信任并连接到 DERP 服务器。
-
域名准备：需要拥有一个可以自行管理 DNS 的域名。如果没有，需要先注册一个（记得备案，不备案会陪封禁）。
-
DNS 配置：为 DERP 服务器选择一个子域名（例如
derp.demo.com）。然后，在域名注册商或 DNS 服务提供商的管理后台，创建一条A记录，将此子域名指向服务器的公网 IP 地址100.100.100.100。- 记录类型：
A - 主机记录/名称：
derp(或选择的其他名称) - 记录值/地址：
100.100.100.100 - TTL (Time To Live)：建议设置为较短的值（如 600 秒），以便在配置更改时能更快生效。
- 记录类型：
-
验证 DNS 解析：在创建记录后，等待几分钟让 DNS 记录在全球范围内传播。可以在本地计算机上使用
ping或dig命令来验证解析是否生效：ping derp.demo.com如果命令返回的 IP 地址是
100.100.100.100，则表示 DNS 配置正确。 -
TLS 证书规划：
derper二进制文件需要有效的 TLS 证书才能运行。虽然可以使用自签名证书，但强烈建议使用由公共证书颁发机构（CA）签发的免费证书，例如 Let’s Encrypt。这可以避免在客户端配置中添加信任自签名证书的复杂步骤。
此外，一个重要的架构约束是，DERP 协议在 TLS 内部实现了一个从 HTTP 到自定义双向二进制协议的切换。这使其与许多标准的七层（L7）HTTP 反向代理不兼容。因此，不应将 derper 服务置于标准的 HTTP 代理之后，除非该代理被明确配置为 TCP 模式（四层透传）。对于本次部署，将直接将 derper 暴露在公网 IP 上。
在继续之前，请使用下表确认所有准备工作均已完成。
表 2.1: 部署前置条件检查清单
| 项目 | 详细信息/配置值 |
|---|---|
| 云服务器已预置 | Ubuntu 24.04.3 LTS, 2C/2G/40G/4M |
| 公网 IP 地址已分配 | 100.100.100.100 |
| 域名已获取 | 例如 yourdomain.com |
DNS A 记录已创建 |
derp.demo.com -> 100.100.100.100 |
| DNS 解析已验证 | ping derp.demo.com 返回正确 IP |
| SSH 访问已验证 | 能够以 root 或 sudo 用户身份登录服务器 |
2.3 筑牢防线：防火墙与安全组配置
安全是任何网服务的基础。在部署 derper 之前，必须正确配置服务器的防火墙，仅开放必要的端口。与主要依赖出站连接的普通 Tailscale 客户端不同，DERP 服务器作为一个公共服务，必须监听并接受来自互联网的入站连接。这是一个关键的区别，也是最容易出错的环节。
根据官方文档和社区实践，一个自定义 DERP 服务器需要开放以下两个端口的入站流量：
- TCP 端口 443：这是 DERP 服务本身的主端口。客户端通过此端口使用基于 TLS 的协议与 DERP 服务器通信。
- UDP 端口 3478：这是 STUN (Session Traversal Utilities for NAT) 协议的标准端口。DERP 服务器同时运行一个 STUN 服务，帮助 Tailscale 客户端探测其自身的 NAT 类型和公网 IP 地址，这对于后续尝试建立直接连接至关重要。
使用 Ubuntu 系统内置的 ufw (Uncomplicated Firewall) 工具来配置这些规则。
-
更新软件包列表并安装 ufw (如果尚未安装):
sudo apt update sudo apt install ufw -
配置防火墙规则：
# 允许所有出站流量 (默认) sudo ufw default allow outgoing # 拒绝所有入站流量 (默认) sudo ufw default deny incoming # 允许 SSH 连接 (非常重要，否则将失去对服务器的访问权限) sudo ufw allow ssh # 或者，如果使用非标准 SSH 端口，可以指定端口号 # sudo ufw allow 22/tcp # 允许 DERP 服务端口 sudo ufw allow 443/tcp # 允许 STUN 服务端口 sudo ufw allow 3478/udp # 启用防火墙 sudo ufw enable当提示
Command may disrupt existing ssh connections. Proceed with operation (y|n)?时，输入y并回车。 -
检查防火墙状态：
sudo ufw status verbose应该能看到类似下面的输出，确认规则已生效：
Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere <
本文地址：https://www.yitenyun.com/593.html
