apisix透传客户端真实IP(real-ip插件)

发布于:2025-05-16 ⋅ 阅读:(12) ⋅ 点赞:(0)

apisix透传客户端真实IP

需求和背景

当 APISIX 前端有其他反向代理(如 Nginx、HAProxy、云厂商的 LB)时,如何正确获取到真实的客户端 IP 地址。

默认情况下,APISIX 会将直接连接到它的那个代理服务器的 IP 视为客户端 IP ($remote_addr)。但真实的客户端 IP 通常被放在 X-Forwarded-For (XFF) 请求头中。

当 APISIX 位于反向代理(如负载均衡器、CDN)之后时,客户端的真实 IP 会被代理服务器的 IP 覆盖(例如,APISIX 看到的 remote_addr 是负载均衡器的 IP,而非用户的真实 IP)。

k8s 集群入口一般都需要过负载均衡,然后再到 apisix。
这时如果后台业务需要获取客户端 ip,可能拿到的是 lb 或者相关的内网 ip。

这里一般要获取真实 ip 需要做几个处理。

  1. 负载均衡上,一般支持配置获取真实 ip 参数,需要配置上。然后 lb 会把客户真实 ip 写入 x-forwarded-for 参数。
  2. apisix 上配置 real-ip 插件。作用和 nginx 的 realip 插件相同。

apisix real-ip插件

官方文档: https://apisix.apache.org/zh/docs/apisix/plugins/real-ip/

real-ip 插件是 Apache APISIX 的一个功能模块,用于通过 HTTP 请求头或查询字符串中的 IP 地址设置客户端的真实 IP,特别适用于 APISIX 位于反向代理后的场景。该插件类似于 NGINX 的 ngx_http_realip_module,但提供了更多灵活性,支持从 URI 参数、请求头或多层代理中获取真实 IP,并可通过配置可信地址和递归选项来精确控制 IP 替换逻辑。

  • 插件支持从 URI 参数(如 arg_realip)或请求头(如 X-Forwarded-For)中提取真实 IP。
  • 可配置 trusted_addresses 指定可信代理 IP 范围(支持 CIDR 表示法):
    • 只有请求的 remote_addr(直接连接的客户端 IP)在 trusted_addresses 列表中时,插件才会处理 IP 替换。
    • 避免恶意用户伪造 X-Forwarded-For 头篡改 IP,确保只有可信代理的请求能触发 IP 替换。
    • 确保只有受信任的代理(如负载均衡器、CDN)能触发 IP 替换,防止伪造攻击。
    • 不配置 trusted_addresses 或留空会完全禁用 IP 替换功能。
    • 支持单个 IP、CIDR 范围或多层代理递归处理

为什么需要 trusted_addresses?

在 Apache APISIX 的官方文档中,trusted_addresses 是 real-ip 插件的一个可选参数

当 APISIX 位于反向代理(如负载均衡器、CDN)之后时,客户端的真实 IP 会被代理服务器的 IP 覆盖(例如,APISIX 看到的 remote_addr 是负载均衡器的 IP,而非用户的真实 IP)。为了解决这个问题,代理服务器通常会在请求头(如 X-Forwarded-For)中附加用户的真实 IP。

风险:如果任何客户端都能直接访问 APISIX,并随意伪造 X-Forwarded-For 头,恶意用户可以通过篡改该头字段伪装成任意 IP,绕过安全策略(如 IP 黑名单或速率限制)。

攻击场景(无 trusted_addresses)
恶意用户直接访问 APISIX,伪造请求头

GET /api/data HTTP/1.1
Host: apisix.example.com
X-Forwarded-For: 6.6.6.6  # 伪造的 IP

APISIX 错误地将客户端 IP 识别为 6.6.6.6(实际是恶意用户的真实 IP)。

防御机制(启用 trusted_addresses)

  1. 配置只信任负载均衡器的 IP(如 203.0.113.10)
"trusted_addresses": ["203.0.113.10"]
  1. 只有通过负载均衡器的请求才会触发 IP 替换:
    负载均衡器转发请求时,remote_addr 是 203.0.113.10(可信)。
    插件读取 X-Forwarded-For 中的真实用户 IP(如 1.2.3.4)。

在理想的生产环境部署中,APISIX 的 IP 确实不应该直接暴露在公网,而是应该隐藏在反向代理(如负载均衡器、CDN、API 网关)之后,并通过安全组/防火墙严格限制访问来源。

因此,感觉这个配置不是很需要。APISIX 原本设计为内网服务,但被错误地绑定到公网 IP 或未启用认证。

防止内部威胁:

  • 攻击者可能通过内网横向移动(如入侵其他服务器后访问 APISIX)。
  • 恶意内部人员可能直接发送伪造请求。
安全架构的最佳实践
  1. 网络层隔离
    仅允许代理 IP 访问 APISIX:
# 示例:AWS Security Group 规则
允许入站 80/443 → 源IP: 负载均衡器(203.0.113.10)
拒绝其他所有流量

禁用公网绑定

# APISIX 配置中仅监听内网
listen 192.168.1.100:9080;
  1. 应用层防御(trusted_addresses)
{
  "real-ip": {
    "source": "header",
    "header": "X-Forwarded-For",
    "trusted_addresses": ["203.0.113.10", "192.168.1.0/24"]
  }
}
  1. 监控与告警
    检测异常请求(如直接访问 APISIX 的非代理 IP)。
    定期审计防火墙和代理配置。

总结
1…“APISIX 不暴露”是目标,但 trusted_addresses 是最后一道防线。
2. 安全 = 预防 + 检测 + 容错:即使你相信网络层万无一失,应用层仍需冗余保护。
3. 类比:就像你家有门锁(防火墙),但保险箱(trusted_addresses)仍需要密码。

示例场景

假设你的架构如下:

用户 → 负载均衡器(IP: 203.0.113.10) → APISIX(IP: 192.168.1.100) → 后端服务

负载均衡器会将用户真实 IP 放在 X-Forwarded-For 头中,例如:X-Forwarded-For: 1.2.3.4

配置 real-ip 插件

为了让 APISIX 信任负载均衡器的 IP(203.0.113.10),并替换客户端 IP 为 X-Forwarded-For 中的值(1.2.3.4),配置如下:

{
  "plugins": {
    "real-ip": {
      "source": "header",           // 从请求头获取 IP
      "header": "X-Forwarded-For",   // 指定头字段
      "trusted_addresses": ["203.0.113.10/32"]  // 只信任负载均衡器的 IP
    }
  }
}

递归查找(多层代理)
如果 X-Forwarded-For 包含多个 IP(如 1.2.3.4, 203.0.113.10),启用 recursive 会从右向左找到第一个非可信 IP:

{
  "source": "header",
  "header": "X-Forwarded-For",
  "trusted_addresses": ["203.0.113.10"],
  "recursive": true  // 递归查找
}

结果:客户端 IP 替换为 1.2.3.4(跳过可信的 203.0.113.10)。

apisix界面配置

在这里插入图片描述

  • source指,写入那个参数,一般是http_x_forwarded_for。
  • trusted_addresses指,set_real_ip_from,一般需要设置的内网ip地址。比如lb的内网地址,或者有内网转发的话,集群内网的ip地址。

网站公告

今日签到

点亮在社区的每一天
去签到