Network on 云淡风轻

TINC 源码解读第三篇 - UDP 打洞

Thu, 08 Jan 2026 10:00:00 +0800

本文是 TINC 源码系列分析的第三篇，重点探讨 TINC 如何在 NAT 环境下建立 P2P 直连。通过 UDP 打洞技术，TINC 能够让位于不同 NAT 后的节点直接通信，大幅提升性能。

1. UDP 打洞概览

问题背景

在互联网上，大多数终端设备都位于 NAT（Network Address Translation）或防火墙后面。这意味着两个内网节点无法直接建立 P2P 连接——它们的内网地址在公网上不可见。传统的解决方案是使用中央服务器中继，但这会增加延迟和服务器成本。

核心概念

UDP 打洞 是一种 NAT 穿透技术，允许两个在 NAT 后面的节点建立直接的 UDP 连接。基本原理是：

两个节点都在 NAT 后
无法直接建立 P2P 连接
通过第三方（根节点）转发连接信息
两个节点同时向对方发送 UDP 包
NAT 记住出站连接，允许回复通过
建立直接的 UDP 通道

优势：

✅ 避免 TCP 中继的开销
✅ 降低延迟
✅ 减少根节点流量
✅ 提高可靠性和吞吐量

2. TINC 中的 UDP 打洞机制

节点状态位

TINC 使用位字段记录节点状态，其中 udp_confirmed 是关键标志位，表示 UDP 连接已双向确认可用：

typedef union node_status_t {
    struct {
        bool validkey: 1;           // 有有效的加密密钥
        bool waitingforkey: 1;      // 等待密钥回复
        bool visited: 1;            // Dijkstra 访问标记
        bool reachable: 1;          // 在拓扑中可达
        bool indirect: 1;           // 不可直接到达
        bool sptps: 1;              // 支持 SPTPS 握手
        bool udp_confirmed: 1;      // ★ UDP 已确认可用
        bool send_locally: 1;       // 从本地网络发送
        bool udppacket: 1;          // 最后收到 UDP 包
        bool validkey_in: 1;        // 已发送有效密钥给对方
        bool has_address: 1;        // 知道对方公网地址
        bool ping_sent: 1;          // 已发送 UDP 探针包
    };
    uint32_t value;
} node_status_t;

关键状态变量

struct node_t {
    // UDP 直连相关
    bool udp_confirmed;             // UDP 连接已确认双向
    address_cache_t *address_cache; // 最近地址缓存
    
    // 打洞探测相关
    bool ping_sent;                 // UDP 探针已发送
    struct timeval udp_ping_sent;   // 探针发送时间
    int udp_ping_rtt;              // 往返时间 (微秒)
    
    // MTU 探测
    int mtuprobes;                  // MTU 探针计数
    uint16_t mtu;                   // 当前 MTU
    uint16_t minmtu;                // 最小 MTU
    uint16_t maxmtu;                // 最大 MTU
    
    // 包大小统计
    uint32_t maxrecentlen;          // 最近最大包长
};

3. UDP 打洞流程

详细步骤

步骤 1: TCP 握手连接

Node A                  Root Server                Node B
  |                        |                          |
  |------ TCP CONNECT ---->|                          |
  |                        |<------ TCP CONNECT ------|
  |                        |                          |

步骤 2: 交换拓扑信息

Node A                  Root Server                Node B
  |                        |                          |
  |- ADD_EDGE A, Root ---->|                          |
  |                        | (Root learns A's addr)   |
  |                        |                          |
  |                        |-- ADD_EDGE B, Root ----->|
  |                        |                          |
  |<- ADD_EDGE B, Root ----|                          |
  |   (A learns B exists)  |                          |

步骤 3: 密钥交换

Node A                  Root Server                Node B
  |                        |                          |
  |-- REQ_KEY A->B ------->|                          |
  | (request B's key)      |                          |
  |                        |---- REQ_KEY A->B ------->|
  |                        |                          |
  |                        |<---- ANS_KEY B->A -------|
  |                        | (B's key)                |
  |<-- ANS_KEY B->A -------|                          |
  | (forwarded by Root)    |                          |

步骤 4: UDP 打洞 (关键阶段)

Node A (LAN: 192.168.1.100:1194)        Node B (LAN: 192.168.2.50:1194)
  |                                       |
  | A knows B's public: 203.0.113.20:5001 | B knows A's public: 203.0.113.10:5000
  |                                       |
  +-- UDP Probe (TYPE=0) ----+            |
  |   NAT A opens hole:      |            |
  |   LAN1194 <-> WAN5000    |            |
  |                          +----------->| Forward to B's LAN
  |                                       | B's NAT opened
  |                          +------ UDP Reply (TYPE=1) --+
  |                          |  NAT B: LAN1194 <-> WAN5001|
  |                          |                            |
  |<-- UDP Reply received <--+                            |
  |    From: 203.0.113.20:5001                            |
  |    NAT A allows reply (hole remains open)             |
  |                                       |
  v (Both sides confirm UDP reachable)
  
  udp_confirmed = true [SUCCESS]
  Both NAT holes established and verified
  Start direct UDP communication

步骤 5: 直接 UDP 通信

Node A                                            Node B
  |                                                |
  |-------- Encrypted VPN packet (UDP) ----------->|
  | (No longer through Root, direct forward)       |
  |                                                |
  |<------- Encrypted VPN packet (UDP) ------------|
  |                                                |
  |--------- High-speed bidirectional flow ------->|

代码流程示意

// 1. 发送 UDP 探针
void send_udp_probe_packet(node_t *n, size_t len) {
    vpn_packet_t packet;
    DATA(packet)[0] = 0;  // 探针请求类型
    
    // 发送到 n 的公网地址
    send_udppacket(n, &packet);
    
    // 标记已发送
    n->status.ping_sent = true;
    gettimeofday(&n->udp_ping_sent, NULL);
}

// 2. 接收探针回复
static void udp_probe_h(node_t *n, vpn_packet_t *packet, length_t len) {
    // 收到对方的探针回复
    
    if(!n->status.udp_confirmed) {
        n->status.udp_confirmed = true;  // ✓ 双向 UDP 已建立
        
        // 缓存这个 UDP 地址
        if(!n->address_cache) {
            n->address_cache = open_address_cache(n);
        }
        add_recent_address(n->address_cache, &n->connection->address);
    }
}

4. 地址缓存机制

缓存结构

为了避免每次都进行 DNS 查询，TINC 维护一个最近地址缓存。缓存采用 MRU（Most Recently Used）策略，保留最近 8 个已验证的 UDP 地址：

#define MAX_CACHED_ADDRESSES 8

typedef struct address_cache_t {
    node_t *node;              // 关联节点
    splay_tree_t *config_tree; // 配置树
    config_t *cfg;             // 当前配置
    
    addrinfo *ai;              // 地址信息
    addrinfo *aip;             // 当前指针
    unsigned int tried;        // 尝试计数
    
    // 最近 8 个已验证的 UDP 地址
    struct {
        unsigned int version;  // 缓存版本
        unsigned int used;     // 已使用数量
        sockaddr_t address[8]; // 地址数组 (最近优先)
    } data;
} address_cache_t;

缓存操作

添加地址：当成功通过 UDP 接收到来自某个地址的包时，将该地址加入缓存
MRU 策略：最近使用的地址移到第 0 位，其他地址向后移动
获取地址：优先尝试缓存的地址，避免 DNS 查询
重置缓存：新连接尝试时清空缓存

5. NAT 类型检测与适应

常见 NAT 类型

NAT 类型	打洞成功率	特点
Full Cone NAT	✅ 95-99%	任何外部地址都能回复
Address-Restricted Cone	✅ 70-90%	只有之前通信过的源 IP 能回复
Port-Restricted Cone	⚠️ 30-60%	只有特定的源 IP:端口能回复
Symmetric NAT	❌ 0-5%	每个目标地址分配不同源端口，无法打洞

TINC 的适应机制

TINC 在协议选项中编码节点的特性，根据选项决定通信策略：

#define OPTION_INDIRECT    0x0001  // 间接连接（已知是 Symmetric NAT）
#define OPTION_TCPONLY     0x0002  // 仅 TCP，不支持 UDP
#define OPTION_PMTU_DISCOVERY 0x0004
#define OPTION_CLAMP_MSS   0x0008

// 根据选项决定使用策略:
if(e->options & OPTION_TCPONLY) {
    // 强制使用 TCP 中继
    use_tcp_relay();
} else if(e->options & OPTION_INDIRECT) {
    // 尝试打洞，但可能需要中继
    attempt_udp_hole_punch();
} else {
    // 尽量使用 UDP 直连
    prefer_udp_direct();
}

6. UDP 数据传输优化

发送策略

TINC 发送包时会检查 UDP 连接状态，优先使用最快的路径：

static void send_udppacket(node_t *n, vpn_packet_t *origpkt) {
    if(n->status.udp_confirmed) {
        // ✓ 已确认 UDP 可用
        
        // 1. 使用缓存的 UDP 地址
        const sockaddr_t *sa = get_recent_address(n->address_cache);
        
        if(!sa) {
            // 缓存无有效地址，降级到 TCP
            goto use_tcp;
        }
        
        // 2. 加密包
        encrypt_packet(n, origpkt);
        
        // 3. 直接通过 UDP 发送
        sendto(udp_socket, pkt, len, 0, sa, salen);
        
    } else {
        // UDP 未确认，使用 TCP 中继
        use_tcp:
        send_tcppacket(n->connection, origpkt);
    }
}

接收处理

static bool receive_udppacket(node_t *n, vpn_packet_t *inpkt) {
    // 收到 UDP 包
    
    // 1. 更新最近地址缓存
    add_recent_address(n->address_cache, &peer_addr);
    
    // 2. 解密
    decrypt_packet(n, inpkt);
    
    // 3. 路由转发
    route_packet(inpkt);
    
    // 4. 如果是首次 UDP 通信
    if(!n->status.udp_confirmed) {
        n->status.udp_confirmed = true;
        logger(LOG_INFO, "UDP direct connection established with %s", n->name);
    }
    
    return true;
}

7. 超时与降级处理

超时配置

// 参数配置
timeout_t udp_probe_timeout;    // 探针超时
#define UDP_PROBE_INTERVAL 3    // 3 秒发送一次
#define UDP_PROBE_TIMEOUT 10    // 10 秒未响应即超时

// 打洞流程时间线
0s   ├─ 发送第 1 个 UDP 探针
     │  status.ping_sent = true
     │
3s   ├─ 发送第 2 个 UDP 探针
     │
6s   ├─ 发送第 3 个 UDP 探针
     │
10s  ├─ 超时检查
     │  if (now - last_udp_reply > 10s)
     │      status.udp_confirmed = false
     │      switch to TCP relay
     │
...  ├─ 继续定期发送 UDP 探针尝试重连

降级逻辑

// TCP/UDP 混合转发 - 智能选择最优路径
void send_packet_to_node(node_t *n, vpn_packet_t *pkt) {
    
    // 优先级 1: UDP 直连（最快）
    if(n->status.udp_confirmed && is_recent_success) {
        return send_udppacket(n, pkt);
    }
    
    // 优先级 2: SPTPS over UDP（新式，安全）
    if(n->status.sptps) {
        return send_sptps_udppacket(n, pkt);
    }
    
    // 优先级 3: TCP 转发（可靠，较慢）
    if(n->connection && n->connection->status.active) {
        return send_tcppacket(n->connection, pkt);
    }
    
    // 优先级 4: 通过其他节点中继（绕行）
    if(n->via && n->via != n) {
        return send_via_relay(n->via, n, pkt);
    }
    
    // 无法送达
    return false;
}

8. MTU 探测与优化

MTU 发现流程

建立 UDP 直连后，TINC 会自动探测最优 MTU 大小，避免包分片导致的性能下降。

1. 初始 MTU = 1500 (以太网标准)

2. 发送递增大小的探针包
   ├─ 1500 字节 ─→ OK ✓
   ├─ 1450 字节 ─→ OK ✓
   ├─ 1400 字节 ─→ OK ✓
   ├─ 1350 字节 ─→ ICMP Fragmented (失败)
   │
   └─ 回退: MTU = 1350 + padding

3. 最终 MTU 确定后
   └─ 所有包都限制在该大小内
   └─ 避免分片，提高性能

代码实现：

void mtu_probe_timeout_handler(void *data) {
    node_t *n = data;
    
    if(n->mtuprobes == -1) {
        // MTU 已确定，不需要探测
        return;
    }
    
    if(n->mtuprobes++ > MAX_PROBES) {
        // 探针已发送足够次数
        try_fix_mtu(n);  // 确定最终 MTU
        return;
    }
    
    // 继续发送 MTU 探针
    size_t len = n->maxmtu - n->mtuprobes * 128;
    send_udp_probe_packet(n, len);
}

9. 协议扩展 (UDP_INFO)

TINC 通过 UDP_INFO 协议消息来交换 UDP 地址信息。这个消息在元协议（Meta Protocol，基于 TCP）中传输。

UDP_INFO 消息格式

格式: UDP_INFO originator_node address_info

流程:
1. Node A → Root: "UDP_INFO myself 203.0.113.10:5000"
   (告诉 Root 我的 UDP 地址)

2. Root → Node B: "UDP_INFO nodeA 203.0.113.10:5000"
   (告诉 B, A 的 UDP 地址)

3. Node B → Root: "UDP_INFO myself 203.0.113.20:5001"

4. Root → Node A: "UDP_INFO nodeB 203.0.113.20:5001"

实现优势

内网节点无法自己检测公网地址，需要第三方帮助
UDP_INFO 机制允许节点告诉其他节点自己的公网 UDP 地址
这是打洞成功的必要条件

10. 实际场景分析

场景 A: 双方都在 Full Cone NAT 后

Node A (10.0.0.5:1194)          Node B (10.0.0.6:1194)
NAT: 203.0.113.10:5000          NAT: 203.0.113.20:5001

时间线:
0ms   A UDP 包 → Root → Root 转发给 B
      NAT A 记录: 内网 1194 ↔ 外网 5000 ↔ 203.0.113.20:5001

5ms   B 收到 A 的探针
      回复 UDP 包 → 203.0.113.10:5000
      NAT B 记录: 内网 1194 ↔ 外网 5001 ↔ 203.0.113.10:5000

10ms  A 收到 B 的回复
      udp_confirmed = true ✓
      后续所有包直接交换，不经过 Root

成功率: ✓ 100% (Full Cone NAT 最容易打洞成功)

场景 B: 一方在 Symmetric NAT 后

Node A (Symmetric NAT)          Node B (Full Cone NAT)

A 的 NAT 行为:
每次发送到不同地址时使用不同的源端口
├─ → 203.0.113.20 from 5000
├─ → 203.0.113.30 from 5001
└─ → 203.0.113.40 from 5002

问题:
Root 看到多个不同的源端口，无法告诉 B 一个确定的 UDP 地址

结果: UDP 打洞失败 ❌
降级: 使用 TCP 中继

11. 性能指标

典型延迟与吞吐量

TCP 中继路径：

延迟：100-500ms（往返）
吞吐量：50-200 Mbps

UDP 直连路径：

延迟：10-100ms（往返，取决于网络）
吞吐量：200-1000+ Mbps（接近原生网络）

吞吐量提升：UDP 直连相比 TCP 中继提升 5-10 倍

成功率统计

NAT 场景	打洞成功率	降级方案
Full Cone NAT	95-99%	TCP 中继
Restricted Cone	70-90%	TCP 中继
Port-Restricted	30-60%	TCP 中继
Symmetric NAT	0-5%	TCP 中继（必须）

12. 调试与监控

查看打洞状态

# 运行时查询
tinc -n myvpn info <node>

# 输出示例:
Node: remotenode
  Address: 203.0.113.20 port 655
  Cipher: aes-256-cbc
  Digest: sha512
  Magic: 12345678
  Status: active validkey udp_confirmed

# udp_confirmed 出现 → UDP 直连已建立 ✓

调试日志

# 启用 UDP 调试
RUST_LOG=debug tincd -n myvpn -d DEBUG

# 关键日志:
[DEBUG] Sending UDP probe to nodeB (203.0.113.20:1194)
[DEBUG] Got UDP probe reply from nodeB
[DEBUG] UDP direct connection confirmed with nodeB
[DEBUG] Caching recent address for nodeB: 203.0.113.20:1194
[DEBUG] MTU for nodeB: 1372 bytes

网络捕获

# 捕获 UDP 直连包
tcpdump -i eth0 -n 'udp port 1194' -w vpn.pcap

# 分析包内容
wireshark vpn.pcap
# 查看: 源/目标 IP:端口、包大小、发送频率

13. 常见问题与解决

问题 1: UDP 打洞失败，始终显示 TCP

诊断：

$ tinc -n myvpn info remotenode | grep -i udp

现象：无 udp_confirmed 标志

原因可能：

节点在 Symmetric NAT 后
防火墙阻止 UDP
ISP 限制 UDP
路由策略问题

解决：

确认两节点都支持 UDP
检查防火墙规则：sudo ufw allow 1194/udp
尝试 UPnP 端口映射（如支持）
确认 UDP_INFO 消息交换成功

问题 2: 间歇性 UDP 中断

现象：UDP 时而工作，时而不工作

原因：

网络波动导致超时
NAT 刷新时间过短
MTU 设置不当导致分片丢失

解决：

降低 UDP 探针超时：udp_probe_timeout = 15
增加打洞频率：udp_probe_interval = 2
调整 MTU：minmtu = 1280

问题 3: MTU 不匹配

现象：大包通过 UDP 时丢失

原因：中间网络 MTU < 节点配置的 MTU

解决：

启用 MTU 自动探测
手动配置：PMTU_SIZE 1280
启用 PMTU 发现：DF 位设置

总结

TINC 的 UDP 打洞机制展示了如何在复杂的 NAT 环境下实现高效的 P2P 通信。关键设计包括：

核心流程：

TCP 握手 + 拓扑同步
    ↓
UDP_INFO 交换公网地址
    ↓
同时发送 UDP 探针（打洞）
    ↓
建立双向 UDP 连接
    ↓
优先使用 UDP 直连
    ↓
失败自动降级到 TCP

关键特性：

✅ 自适应 NAT 类型
✅ 地址缓存优化
✅ 动态 MTU 发现
✅ 失败自动降级
✅ 支持 IPv4 和 IPv6
✅ 低延迟高吞吐量

性能提升：

连接方式	吞吐量
TCP 中继	50-200 Mbps
UDP 直连	200-1000 Mbps
提升倍数	5-10 倍

这种精心设计的适应性系统使 TINC 在各种网络环境下都能提供最优的性能，是现代 VPN 软件的最佳实践。

系列预告

第一篇：TINC 协议深度解析
第二篇：TINC 模块架构与代码组织
第三篇：UDP 打洞机制
第四篇：TINC 项目 - 模块依赖与数据流图

TINC 源码解读第一篇 - 协议深度解析

Thu, 08 Jan 2026 08:00:00 +0800

本文是 TINC 源码解读系列的第一篇，重点分析 TINC 的协议设计。TINC 采用分层架构，使用 Meta Protocol 处理控制平面，Packet Protocol 处理数据平面，SPTPS 提供额外的加密保证。

1. 协议概览

TINC 使用两个独立的协议层：

Meta Protocol - TCP 连接上的文本协议（连接建立、拓扑交换）
Packet Protocol - UDP 连接上的二进制协议（数据包转发）

协议版本

PROT_MAJOR = 17  // 主版本号（不兼容时变化）
PROT_MINOR = 7   // 次版本号（向后兼容）

2. Meta 协议 - 控制平面

消息类型枚举

Meta Protocol 定义了 20 多种消息类型，按功能分类：

// 认证阶段
ID              // 连接标识
METAKEY         // 元数据密钥交换
CHALLENGE       // 密码挑战
CHAL_REPLY      // 挑战回复
ACK             // 确认

// 连接管理
STATUS          // 状态信息
ERROR           // 错误消息
TERMREQ         // 终止请求

// 保活
PING            // 心跳 Ping
PONG            // 心跳 Pong

// 拓扑交换
ADD_SUBNET      // 添加子网
DEL_SUBNET      // 删除子网
ADD_EDGE        // 添加边/链路
DEL_EDGE        // 删除边/链路

// 密钥交换
KEY_CHANGED     // 密钥已更改
REQ_KEY         // 请求加密密钥
ANS_KEY         // 应答加密密钥

// 数据转发
PACKET          // TCP 转发数据包

// Tinc 1.1+ 扩展
REQ_PUBKEY      // 请求公钥
ANS_PUBKEY      // 应答公钥
SPTPS_PACKET    // SPTPS 加密包
UDP_INFO        // UDP 地址信息
MTU_INFO        // MTU 信息

核心消息格式

ID 消息 - 连接起点

格式: ID name version

示例: 0 mynode 17.7

含义:
├─ 0        - 消息类型标识
├─ mynode   - 节点名称
└─ 17.7     - 协议版本 (MAJOR.MINOR)

METAKEY 消息 - 加密参数协商

格式: METAKEY cipher digest keylength [加密的密钥]

示例: 1 aes-256-cbc sha512 32 [128字节加密数据]

含义:
├─ 1              - 消息类型
├─ aes-256-cbc    - 对称加密算法
├─ sha512         - HMAC 摘要算法
└─ 32             - 密钥长度（字节）

特点:
└─ 加密密钥使用对方的公钥进行 RSA 加密

CHALLENGE 消息 - 身份验证

格式: CHALLENGE <hash>

验证过程:
1. 接收方生成随机 challenge (16 字节)
2. 计算 hash = HMAC-SHA256(challenge, shared_key)
3. 发送 CHALLENGE hash
4. 发起方计算相同的 hash
5. 验证 hash 相等

ADD_EDGE 消息 - 拓扑通告

格式: ADD_EDGE node_from node_to address port weight options

示例: ADD_EDGE nodeA nodeB 192.168.1.100 655 100 0

解析:
├─ ADD_EDGE        - 消息类型
├─ nodeA           - 源节点
├─ nodeB           - 目标节点
├─ 192.168.1.100   - 目标地址（实际网络地址）
├─ 655             - UDP 端口
├─ 100             - 权重（用于 Dijkstra）
└─ 0               - 选项标志

选项标志:
├─ 0x0001: OPTION_INDIRECT   (间接连接)
├─ 0x0002: OPTION_TCPONLY    (仅 TCP)
├─ 0x0004: OPTION_PMTU_DISCOVERY
└─ 0x0008: OPTION_CLAMP_MSS

ADD_SUBNET 消息 - 子网通告

格式: ADD_SUBNET owner_node network/prefixlength

IPv4 示例: ADD_SUBNET node1 192.168.1.0/24
IPv6 示例: ADD_SUBNET node1 2001:db8::/32
MAC  示例: ADD_SUBNET node1 ff:ff:ff:ff:ff:ff

用途:
└─ 通告该节点负责路由的子网地址

REQ_KEY 和 ANS_KEY - 数据加密密钥交换

REQ_KEY 格式: REQ_KEY originator destination
含义: originator 请求与 destination 的通信密钥

ANS_KEY 格式: ANS_KEY from to cipher_id digest_id key mac_length
示例: ANS_KEY nodeB nodeA 1 3 4ae0b0a82d6e0078 16

解析:
├─ nodeB         - 密钥所有者
├─ nodeA         - 请求方
├─ 1             - 对称加密算法 ID
├─ 3             - HMAC 摘要算法 ID
├─ 4ae0...78     - 128 位加密密钥
└─ 16            - MAC 长度

PING 和 PONG - 保活消息

PING 格式: PING [随机数]
PONG 格式: PONG [随机数]

用途:
├─ 检测连接是否仍然活跃
├─ 防止连接因不活动而被关闭
├─ 检测单向连接失败
└─ 通过随机数防止已知明文攻击

3. Meta 协议握手流程

完整的连接建立过程

发起方                      响应方
─────────────────────────────────────

TCP 连接 ─────────────→

                  ← 接受连接

发送 ID ──────────→
                  
                  ✓ 验证版本

                  ← 发送 ID

✓ 验证版本

发送 METAKEY ─────→
(加密的元密钥)

                  ✓ 解密元密钥

                  ← 发送 METAKEY

✓ 解密元密钥

从此以后，所有通信使用
协商的加密密钥加密

发送 CHALLENGE ────→
(hash = HMAC(...))

                  ✓ 验证 hash

                  ← CHAL_REPLY

✓ 双向认证成功

发送 ACK ─────────→

                  ← ACK

✓ 连接完全建立

握手状态机

[TCP Connected]
    ↓
[ID Exchanged]
├─ 校验版本号
├─ 确定协议版本
└─ 准备加密
    ↓
[METAKEY Exchanged]
├─ 选择加密算法
├─ 交换元数据密钥
└─ 开始加密通信
    ↓
[CHALLENGE Issued]
├─ 单向认证
├─ 验证对方公钥
└─ 生成共享密钥
    ↓
[CHAL_REPLY Received]
├─ 双向认证完成
├─ 确认对方身份
└─ 建立信任
    ↓
[ACK Sent/Received]
├─ 连接活跃
├─ 准备数据交换
└─ 拓扑同步
    ↓
[ACTIVE]
├─ 双向 PING/PONG
├─ 转发 ADD_EDGE
├─ 转发 ADD_SUBNET
├─ 转发 REQ_KEY/ANS_KEY
└─ 转发数据包

4. Packet Protocol - 数据平面

UDP 数据包格式

加密前的包结构

Byte:  0-3         4-...           ...      ...+16
      +----------+---------------+--------+--------+
      | seqno    | payload       | padding| MAC    |
      | (32 bit) | (VPN data)    |        |(256bit)|
      +----------+---------------+--------+--------+
      +-----------------------------------+--------+
              Covered by HMAC

加密后的完整 UDP 包

+-------------------------------------------------+
| UDP Header (20 bytes)                           |
| +--- Source IP                                  |
| +--- Dest IP                                    |
| +--- Source Port (1194 or configured)           |
| +--- Dest Port                                  |
+-------------------------------------------------+
| Encrypted Payload (variable length)             |
| +--- Nonce/IV (optional)                        |
| +--- Ciphertext:                                |
| |    +--- seqno (sequence number)               |
| |    +--- VPN data (virtual network packet)     |
| |    +--- HMAC (message authentication code)    |
| +--- Authentication Tag (AEAD encryption)       |
+-------------------------------------------------+

VPN 数据包结构

虚拟网络上传输的是标准 Ethernet Frame：

+----------+----------+----------+---------+-----+
| Dest MAC | Src MAC  | EtherType| Payload | CRC |
| (6 Byte) | (6 Byte) | (2 Byte) |(var len)| (4) |
+----------+----------+----------+---------+-----+

EtherType:
+-- 0x0800: IPv4
+-- 0x86DD: IPv6
+-- 0x0806: ARP

支持的加密算法

对称加密:
├─ ChaCha20-Poly1305  (推荐，AEAD)
├─ AES-256-GCM        (AEAD)
├─ AES-256-CBC        (需要 HMAC)
└─ null cipher        (调试用，无加密)

消息摘要:
├─ SHA512             (推荐)
├─ SHA256
├─ SHA1
└─ MD5 (遗留，不安全)

密钥长度:
├─ 256 bit (标准)
└─ 128 bit (弱密钥，不推荐)

5. SPTPS 协议 - 安全的点对点通信

SPTPS 设计目的

SPTPS（Simple Peer-to-Peer Security）是一个轻量级的加密层，用于在 UDP 上建立直接的加密通道，不需要依赖 Meta Protocol 的握手。

与 Meta Protocol 的区别：

Meta Protocol: 文本协议，TCP，用于控制平面
SPTPS: 二进制协议，UDP，用于数据平面持久化会话

SPTPS 记录类型

#define SPTPS_HANDSHAKE 128   // 密钥交换和认证
#define SPTPS_ALERT 129       // 警告或错误消息
#define SPTPS_CLOSE 130       // 应用程序关闭连接

SPTPS 握手状态

typedef enum sptps_state_t {
    SPTPS_KEX = 1,           // 等待第一个密钥交换记录
    SPTPS_SECONDARY_KEX = 2, // 准备接收二次密钥交换
    SPTPS_SIG = 3,           // 等待签名记录
    SPTPS_ACK = 4,           // 等待确认记录
} sptps_state_t;

SPTPS 密钥交换结构

struct sptps_kex_t {
    uint8_t version;           // 版本号
    uint8_t nonce[32];         // 随机数
    uint8_t pubkey[32];        // 临时 ECDH 公钥 (Curve25519)
}
// 总大小: 65 字节

SPTPS 握手流程

Initiator                   Responder
─────────────────────────────────────

生成临时密钥对
(Curve25519 ECDH)

发送 HANDSHAKE ────────────→
  payload: kex1
  (version, nonce, pubkey)

                           收到 kex1
                           生成临时密钥对
                           计算共享密钥

                           ← 发送 HANDSHAKE
                             payload: kex2

收到 kex2
计算共享密钥

验证: ECDH(A_priv, B_pub)
    == ECDH(B_priv, A_pub) ✓

使用 PRF 派生会话密钥

发送签名记录 ───────────────→
  签署握手数据

                           验证签名

                           ← 发送 ACK 记录

验证 ACK
握手完成 ✓

双向 AEAD 加密通信开始

密钥派生

Shared_Secret = ECDH(my_private_key, peer_public_key)

Session_Keys = PRF-SHA512(
    Shared_Secret,
    label = "SPTPS key expansion" 
          + initiator_pubkey 
          + responder_pubkey
)

派生密钥 (共 64 字节):
├─ Key_A (32 字节): Initiator → Responder
├─ Key_B (32 字节): Responder → Initiator
└─ 每个方向使用不同密钥 (前向保密)

6. 身份验证与安全机制

签名与验证

每个节点都有持久的 ECDSA/EdDSA 密钥对：

公钥位置: hosts 目录 ($TINC_HOME/hosts/nodename)
私钥位置: 配置目录 ($TINC_HOME/rsa_key.priv, ed25519_key.priv)

认证流程:
1. 交换 ID → 校验版本
2. 交换 METAKEY → 协商加密算法
3. 计算 challenge hash
4. 发送 CHALLENGE + CHAL_REPLY
5. 验证签名：数据已被对方的私钥签署
6. 发送 ACK

验证公钥:
├─ 从 hosts 目录读取对方的公钥
├─ 验证签名: Verify(signature, data, peer_pubkey)
├─ 若验证失败，拒绝连接
└─ 若验证成功，建立信任

重放保护

Meta Protocol 重放保护：

├─ past_request_tree 跟踪已处理的请求
├─ 相同请求在一定时间内被忽略
└─ 防止攻击者重复发送拓扑更新

数据包重放保护：

├─ 序列号 (seqno): 递增计数器
├─ 验证 seqno > last_seqno
├─ 丢弃重复包
└─ 使用滑动窗口防止乱序问题

7. 拓扑同步协议

完整的拓扑交换过程

当两个节点建立连接后，会进行完整的拓扑交换：

Node A ──────TCP──────→ Node B

1. 身份验证完成
   (ID, METAKEY, CHALLENGE, ACK)

2. Node A 发送其知道的拓扑:
   
   ADD_EDGE nodeA nodeC 10.0.0.3 655 50 0
   ADD_EDGE nodeA nodeD 10.0.0.4 655 100 0
   ADD_SUBNET nodeA 172.16.1.0/24
   ADD_SUBNET nodeC 172.16.2.0/24

3. Node B 发送其知道的拓扑:
   
   ADD_EDGE nodeB nodeE 10.0.0.5 655 50 0
   ADD_SUBNET nodeB 172.16.4.0/24
   ADD_SUBNET nodeE 172.16.5.0/24

4. 每当拓扑变化时：
   └─ 通过 ADD_EDGE/ADD_SUBNET 发布增量更新

5. 当边或节点失败时：
   └─ 广播 DEL_EDGE/DEL_SUBNET

拓扑维护机制

变化检测:
├─ 新节点加入 → ADD_EDGE + ADD_SUBNET
├─ 节点离开 → DEL_EDGE + DEL_SUBNET
├─ 链路权重变化 → ADD_EDGE (新权重)
└─ 密钥更新 → KEY_CHANGED

广播机制:
├─ 每个连接都转发其收到的拓扑消息
├─ 防环：记录消息源，不回复给源
└─ 定期同步：每个连接建立时交换完整拓扑

8. 协议扩展 (Tinc 1.1+)

新增消息类型

REQ_PUBKEY / ANS_PUBKEY

格式: REQ_PUBKEY from to [timestamp]
      ANS_PUBKEY from to [key_data]

用途:
├─ 请求/应答节点的公钥
├─ 用于拓展的密钥交换
└─ 支持在线密钥更新

UDP_INFO

格式: UDP_INFO originator address:port

用途:
├─ 通告节点可用的 UDP 地址
├─ 支持多地址（IPv4, IPv6）
└─ 加速 UDP 直连建立

MTU_INFO

格式: MTU_INFO node mtu

用途:
├─ 通告路径的最大传输单元
├─ 支持 PMTU 发现
└─ 优化包大小

SPTPS_PACKET

用途:
├─ 使用 SPTPS 加密的 TCP 包
├─ 在 meta 协议上层的加密
└─ 增强安全性

9. 安全性分析

已实现的安全特性

特性	实现	说明
前向保密 (PFS)	✓	ECDH 临时密钥，会话独立
数据完整性	✓	HMAC/AEAD 认证
数据机密性	✓	对称加密 (AES/ChaCha20)
重放保护	✓	序列号 + 滑动窗口
身份认证	✓	ECDSA/EdDSA 签名
密钥交换	✓	ECDH (P-256/Curve25519)
已知明文保护	✓	Ping/Pong 随机值

潜在的风险和对策

风险	严重度	现状
密钥重用	中	支持密钥轮换 (KEY_CHANGED)
时钟偏差	低	支持时钟偏差检测
实现漏洞	高	定期安全审计
算法选择	低	支持现代算法 (ChaCha20)
密钥缓存	中	支持定期过期

10. 连接到完整通信的时间线

时间   事件
──────────────────────────────────────────────
0ms    TCP 连接建立
       ↓
10ms   交换 ID (版本协商)
       ↓
20ms   交换 METAKEY (加密参数)
       ↓
30ms   发送 CHALLENGE (单向认证)
       ↓
40ms   接收 CHAL_REPLY (双向认证)
       ↓
50ms   从此以后所有通信加密
       ↓
60ms   交换 ADD_EDGE (拓扑)
       ↓
100ms  交换 ADD_SUBNET (子网)
       ↓
150ms  定期 PING/PONG (保活)
       ↓
∞      数据转发 & 拓扑维护

11. 协议调试

启用协议日志

# 启用详细的协议调试输出
tincd -n myvpn -d DEBUG

# 典型输出示例:
[DEBUG] Sending ID to node1: "0 mynode 17.7"
[DEBUG] Sending METAKEY to node1: cipher=1 digest=3 maclength=16
[DEBUG] Sending CHALLENGE to node1
[DEBUG] Sending ACK to node1
[DEBUG] Sending ADD_EDGE node1 node2 192.168.1.2 655 100 0
[DEBUG] Sending ADD_SUBNET node2 172.16.2.0/24
[DEBUG] Sending PING to node1
[DEBUG] Received PONG from node1

网络包捕获

# 捕获 Meta Protocol (TCP 655)
tcpdump -i eth0 -n tcp port 655

# 捕获 Packet Protocol (UDP 1194)
tcpdump -i eth0 -n udp port 1194

# 使用 Wireshark 分析
wireshark -i eth0

总结

TINC 协议是一个分层的、设计精良的 VPN 协议体系：

核心设计

Meta Protocol (控制平面)：

TCP 文本协议，用于控制和管理
握手、认证、拓扑交换
可靠但相对低频

Packet Protocol (数据平面)：

UDP 二进制协议，用于数据转发
高效、低延迟
支持快速加密/解密

SPTPS (加密层)：

额外的 UDP 加密层
前向保密和轻量级握手
支持直接 P2P 加密通信

安全特性

✅ 现代密钥交换 (ECDH)
✅ 强力数字签名 (ECDSA/EdDSA)
✅ 前向保密 (PFS)
✅ 重放保护
✅ 完整性认证 (HMAC/AEAD)
✅ 灵活的算法选择

性能考虑

Meta Protocol 低频交互，控制开销小
Packet Protocol 用 UDP，转发延迟低
数据密钥缓存，避免频繁协商
支持直接 P2P（避免中继）

这种精心设计的两层协议架构使 TINC 成为一个既可靠又高效的 VPN 解决方案，是现代 VPN 软件的最佳实践。

系列预告

第一篇：TINC 协议深度解析
第二篇：TINC 模块架构与代码组织
第三篇：UDP 打洞机制
第四篇：TINC 项目 - 模块依赖与数据流图

Network on 云淡风轻

TINC 源码解读 第三篇 - UDP 打洞

1. UDP 打洞概览

问题背景

核心概念

2. TINC 中的 UDP 打洞机制

节点状态位

关键状态变量

3. UDP 打洞流程

详细步骤

步骤 1: TCP 握手连接

步骤 2: 交换拓扑信息

步骤 3: 密钥交换

步骤 4: UDP 打洞 (关键阶段)

步骤 5: 直接 UDP 通信

代码流程示意

4. 地址缓存机制

缓存结构

缓存操作

5. NAT 类型检测与适应

常见 NAT 类型

TINC 的适应机制

6. UDP 数据传输优化

发送策略

接收处理

7. 超时与降级处理

超时配置

降级逻辑

8. MTU 探测与优化

MTU 发现流程

9. 协议扩展 (UDP_INFO)

UDP_INFO 消息格式

实现优势

10. 实际场景分析

场景 A: 双方都在 Full Cone NAT 后

场景 B: 一方在 Symmetric NAT 后

11. 性能指标

典型延迟与吞吐量

成功率统计

12. 调试与监控

查看打洞状态

调试日志

网络捕获

13. 常见问题与解决

问题 1: UDP 打洞失败，始终显示 TCP

问题 2: 间歇性 UDP 中断

问题 3: MTU 不匹配

总结

系列预告

TINC 源码解读 第一篇 - 协议深度解析

1. 协议概览

协议版本

2. Meta 协议 - 控制平面

消息类型枚举

核心消息格式

ID 消息 - 连接起点

METAKEY 消息 - 加密参数协商

CHALLENGE 消息 - 身份验证

ADD_EDGE 消息 - 拓扑通告

ADD_SUBNET 消息 - 子网通告

REQ_KEY 和 ANS_KEY - 数据加密密钥交换

PING 和 PONG - 保活消息

3. Meta 协议握手流程

完整的连接建立过程

握手状态机

4. Packet Protocol - 数据平面

UDP 数据包格式

加密前的包结构

加密后的完整 UDP 包

VPN 数据包结构

支持的加密算法

5. SPTPS 协议 - 安全的点对点通信

SPTPS 设计目的

SPTPS 记录类型

SPTPS 握手状态

SPTPS 密钥交换结构

SPTPS 握手流程

密钥派生

6. 身份验证与安全机制

签名与验证

TINC 源码解读第三篇 - UDP 打洞

TINC 源码解读第一篇 - 协议深度解析