Nebula VPN 中 advertise_addrs 配置的常见误区与正确实践

问题背景

在使用 Nebula 网络工具 构建 overlay 网络时，许多用户会遇到一个看似简单却容易配置错误的问题：客户端能够与 lighthouse（灯塔服务器）正常通信，但客户端之间却无法建立连接。这种情况特别容易出现在混合网络环境中（如同时包含 NAT 设备和公网服务器）。

典型错误配置分析

从实际案例中可以看到，用户经常错误地将 overlay 网络的 IP 地址（如 10.250.0.x）配置到 advertise_addrs 参数中。这是一个典型的理解偏差：

1. 错误理解：认为 advertise_addrs 是用于通告网络内的虚拟 IP
2. 正确理解：该参数实际用于通告节点在底层网络的可路由地址（即公网 IP 或内网可达 IP）

参数详解

advertise_addrs 的正确用途

advertise_addrs 参数用于指定节点可以被其他节点访问的物理网络地址，格式为 ip:port。主要应用场景包括：

• 节点位于 NAT 后且有端口转发时
• 节点有多个网络出口路径时
• 需要覆盖 Nebula 自动发现的地址时

常见配置误区

1. 将 overlay IP 填入参数：如将 10.250.0.1 这样的内网 IP 填入
2. 混淆监听端口：未正确区分底层网络监听端口和 overlay 网络通信
3. 过度配置：在不必要的节点上配置该参数

正确配置实践

Lighthouse 服务器配置

作为中心节点，通常不需要配置 advertise_addrs，除非有特殊网络架构需求：

lighthouse:
  am_lighthouse: true
listen:
  host: 0.0.0.0
  port: 4443  # 确保防火墙开放此端口

公网节点配置

对于有固定公网 IP 的节点（如案例中的 worker 服务器）：

punchy:
  punch: true
advertise_addrs:
  - "公网IP:监听端口"  # 如 "203.0.113.10:4242"

NAT 后客户端配置

位于 NAT 后的客户端（如笔记本电脑）：

static_host_map:
  "10.250.0.1": ["lighthouse公网IP:端口"]
lighthouse:
  hosts:
    - "10.250.0.1"
punchy:
  punch: true  # 应启用以穿透NAT

排错技巧

当遇到节点间通信问题时，可以按照以下步骤检查：

1. 验证基础连接：确保所有节点都能访问 lighthouse
2. 检查日志级别：设置 level: debug 获取详细连接信息
3. 验证地址通告：在日志中确认节点正确获取了对端的物理地址
4. 测试端口连通性：使用 telnet 或 nc 验证底层网络可达性

高级应用场景

对于大型网络部署，还可以考虑：

1. 多路径网络：为节点配置多个 advertise_addrs 实现冗余
2. 端口动态分配：使用 0 作为端口号自动继承 listen.port
3. 混合网络环境：结合 static_host_map 和 advertise_addrs 实现复杂网络拓扑

总结

正确理解和使用 advertise_addrs 参数是构建稳定 Nebula 网络的关键。记住这个基本原则：该参数通告的是节点在底层物理网络中的可达地址，而非 overlay 网络的虚拟 IP。通过合理配置，可以轻松实现包括 NAT 穿透在内的各种复杂网络场景。