可以记录IP的网络协议笔记

目录

• 背景：
• 解决方案1------HTTP头记录
• [解决方案2------proxy protocol协议](#解决方案2——proxy protocol协议)
• [解决方案3------加密 TCP Option](#解决方案3——加密 TCP Option)
• 总结

---

背景：

• 需求1 ------审计日志需要真实IP：

  安全审计要求记录访问服务的最终用户或设备的真实来源IP地址。这对于追踪恶意活动、排查问题、满足合规性要求至关重要。

• 需求2 ------风控需要真正IP：

  一些活动、风险管理都是需要对客户的真实IP进行筛选甄别。

解决方案1------HTTP头记录

为了实现上述目标，有一些现成的解决办法，比如在HTTP协议中加入一些参数，这些参数可以记录IP信息，比如：
X-Forwarded-For标头，记录相关源地址信息,
X-Original-To标头，用来携带目的地址的信息。

缺点：

1. 不安全，容易被篡改；

   • 头部可被篡改：如果请求在到达可信代理前经过不可信节点，攻击者可伪造 X-Forwarded-For: 1.1.1.1 ；

2. 遇到代理服务器，相关标头信息容易被篡改、覆盖。

   • 代理链中若有一个设备未正确传递该头部，信息即丢失；

为什么服务器无法发现真实IP？

以企业WEB服务拓扑图来分析：

1. 代理行为导致, 如果代理服务器使用覆盖模式（如Nginx），则后台服务器就无法获取到Client的真实IP。

2. 代理/负载均衡的普遍性： 现代Web架构中，客户端（浏览器/App）通常不直接连接最终的应用服务器（如Tomcat, Nginx, Apache）。中间会经过反向代理/负载均衡器 (如Nginx, HAProxy, F5)： 负责SSL终止、负载分发、安全防护等。

   • Web应用防火墙 (WAF)： 提供额外的安全防护层；

   • CDN节点： 缓存内容，加速访问；

   • SSL/TLS终止： HTTPS的核心是端到端加密。为了检查内容（如WAF扫描攻击）、进行负载均衡或优化性能，SSL/TLS解密通常在代理/负载均衡器/WAF/CDN处终止。代理服务器建立与客户端的加密连接，然后建立一个（通常是未加密的或新加密的）连接到后端应用服务器。

结果： 当请求到达最终的应用服务器时，服务器看到的网络连接来源IP地址是最后一个代理设备（如Nginx, F5, WAF）的IP地址，而不是原始客户端的真实IP地址。

其它知识：

篡改XFF不会影响实际的网络传输，网络传输由路由提供服务，路由决策仅依赖网络层（IP头），XFF作为应用层数据，对TCP/IP协议栈透明。

---

解决方案2------proxy protocol协议

Proxy Protocol的出现解决了上述代理丢失IP问题，它允许代理服务器在转发连接之前，将原始客户端连接的相关信息封装在特殊的协议头部中传递给目标服务器。 目标服务器可以解析该头部信息，获取客户端的真实IP和端口等连接信息。

Proxy Protocol的工作原理：

Proxy Protocol使用一种简单而有效的协议头部格式来传递连接信息 。协议头部被插入到原始客户端数据之前，以确保目标服务器能够正确解析它。

流程图：

优势：在传输层建立连接前明文传递IP

• 需双方支持，双方选择Proxy Protocol，表示将客户端信息插入到TCP Payload字段中携带至服务端；
• 仅当服务端支持解析TCP Payload字段时，Proxy Protocol参数设置才有效；

风险：未加密，内网传输可接受；

---

解决方案3------加密 TCP Option

可以简单理解为加密版proxy protocol协议，但需要在服务器端、边缘代理端都进行改造，主要是在两端加入相关功能模块和设置一个对称密钥。

流程图：

---

总结

一般Web系统用 Proxy Protocol 或 严格配置的XFF；

# Nginx代理强制覆盖XFF (安全配置)
proxy_set_header X-Forwarded-For $remote_addr;  # 覆盖而非追加

金融/政务系统选择 TCP Option加密方案；