在偶然中，我注意到 graphite 显示的服务器网卡流量呈现出一种锯齿状的波动，这引起了我的警觉。通过检查 nginx 日志，我发现了有人在周期性地抓取我们的接口数据。这种行为让我无法容忍。
通过对访问日志进行简单的分析，我迅速锁定了可疑的 IP 段，并尝试使用 iptables 进行封禁：
shell> iptables -A INPUT -s x.y.z.0/24 -j DROP
我原本以为这样就能解决问题，然而结果却让我大失所望——似乎这些措施完全无效。难道这些“小偷”已经找到了绕过封锁的方法？这不太可能！我的直觉告诉我，这可能与 LVS 有关，但遗憾的是我对 LVS 的了解非常有限。我唯一知道的是项目使用的是 FULLNAT 模式，于是我决定从这个角度开始深入调查：
LVS FULLNAT
FULLNAT 模式的工作原理是，当用户请求通过 LVS 转发到 RS 服务器时，源 IP 会被替换为 LVS 的内网 IP，而目标 IP 则从 LVS 的 VIP 变成 RS 服务器的 IP；当 RS 服务器响应通过 LVS 发送回用户时，源 IP 从 RS 服务器的 IP 变为 LVS 的 VIP，目标 IP 从 LVS 的内网 IP 变为用户的 IP。
备注：如需了解更多关于 LVS 的详细信息，请参考「从一个开发的角度看负载均衡和LVS」一文。
然而，矛盾的是，尽管 RS 服务器看到的是 LVS 的 IP，Nginx 日志中却记录的是客户端的 IP。这是为什么呢？原来 LVS 在 FULLNAT 模式下引入了 TOA 补丁机制，通过 TCP 三次握手阶段的 options 传递用户 IP 和端口信息，从而覆盖 socket 的 IP 和端口数据。
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
换句话说，从 iptables 的角度看，RS 服务器上看到的都是 LVS 的 IP，而从 Nginx 的角度看，由于 TOA 的作用，记录的是用户的 IP。这可以通过 tcpdump 命令抓包来验证：
tcpdump
备注：如图所示，254 开头的字符串中包含了用户的 IP 和端口信息。
因此，可以得出结论：在 RS 服务器上使用 iptables 封禁用户 IP 是无效的，因为我无法操作 LVS 服务器，只能在 RS 服务器上想办法。由于 Nginx 能够获取到用户的 IP，我们可以选择在 Nginx 上解决这个问题。Nginx 提供了 Access、GEO 等多个模块供选择，这里我们选择 GEO 模块：
geo $bad {
default 0;
x.y.z.0/24 1;
}
location / {
if ($bad) {
return 403;
}
}关于 GEO 模块的使用，有许多优秀的参考资料可供查阅，这里就不再赘述。
