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 项目 - 模块依赖与数据流图

Nat on 云淡风轻

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