Nebula项目中通过Relay节点获取客户端真实IP的解决方案

背景介绍

在企业网络环境中，Nebula作为一款优秀的开源网络解决方案，经常被用于构建安全的网络连接。在实际部署中，经常会遇到需要通过Relay节点转发流量的场景，但由此带来的一个常见问题是：内部服务无法获取客户端的真实虚拟IP地址，只能看到Relay节点的IP。

问题分析

当使用Nebula的unsafe_routes功能时，流量会经过以下路径：

1. 客户端（如10.1.1.3）通过Nebula网络发送请求
2. 请求到达Relay节点（如10.1.1.1）
3. Relay节点通过iptables的NAT规则将流量转发到内部网络（如192.168.24.60）

在这个过程中，内部服务看到的源IP是Relay节点的内网IP（192.168.27.199），而非客户端的Nebula虚拟IP（10.1.1.3）。这是因为iptables的MASQUERADE规则修改了数据包的源地址。

解决方案

方案一：移除MASQUERADE并配置静态路由

1. 移除iptables的MASQUERADE规则

   iptables -t nat -D POSTROUTING -o ens32 -j MASQUERADE
   

2. 在所有目标主机上添加静态路由

   ip route add 10.1.1.0/24 via 192.168.27.199
   

   这条命令告诉内部网络中的主机，如何将返回流量发送回Nebula网络。

方案二：全面部署Nebula客户端

最佳实践是在所有需要互通的节点上都安装Nebula客户端，这样可以：

• 保持端到端加密
• 精确控制访问权限
• 自动维护路由信息
• 直接获取客户端的真实虚拟IP

注意事项

1. 当使用方案一时，需要确保：

   • 所有需要访问的内部主机都配置了正确的回程路由
   • 网络设备（如交换机、路由器）不会阻止这些路由

2. 避免在unsafe_routes中配置与Nebula网络重叠的路由，否则会导致错误：

   entry 1.route in tun.unsafe_routes is contained within the network attached to the certificate
   

3. 在复杂网络环境中（如使用F5或LVS负载均衡设备），方案一可能会遇到挑战，这时方案二更为可靠。

技术原理

Nebula的Relay机制本质上是建立了一个隧道，原始数据包在隧道内传输时会保留完整的源和目的IP信息。当使用MASQUERADE时，实际上是在隧道出口处对数据包进行了NAT转换，这破坏了端到端的透明性。

通过配置静态路由，我们保持了数据包的完整性，使得：

• 出站数据包保留原始源IP（10.1.1.3）
• 目标主机知道如何通过Relay节点（192.168.27.199）将响应送回Nebula网络
• Nebula网络内部的路由机制确保响应能正确到达客户端

总结

在Nebula网络架构中，获取客户端真实IP的关键在于保持数据包的端到端完整性。对于临时解决方案，可以通过精细的路由配置实现；但从长远来看，在所有节点部署Nebula客户端是最可靠和安全的做法。这不仅解决了IP可见性问题，还能提供更好的安全控制和网络性能。