文章851
标签121
分类10

多层代理获取真实 IP 的问题

在现代网络架构中,使用多层代理(如 CDN 和反向代理)是提高性能和安全性的常见做法。然而,这种架构也带来了获取用户真实 IP 地址的挑战,尤其是在 Nginx 配置中处理 X-Forwarded-For 头部时。本文将深入探讨这个问题,并提供解决方案。

什么是 X-Forwarded-For

X-Forwarded-For 是一个HTTP头部字段,用于标识原始请求的客户端 IP 地址。它在多层代理环境中非常重要,因为每个代理服务器会将其自己的 IP 地址添加到该字段中,导致最终的目标服务器需要解析这个字段以获取用户的真实 IP。

X-Forwarded-For 的格式

X-Forwarded-For 的格式通常是这样的:

X-Forwarded-For: client1, proxy1, proxy2
  • client1: 用户真实的 IP 地址。
  • proxy1: 第一个代理服务器的 IP 地址。
  • proxy2: 第二个代理服务器的 IP 地址。

获取真实 IP 的挑战

在使用 CDN 和 Nginx 等多层代理时,获取用户的真实 IP 地址面临以下问题:

  1. IP 地址被替换:在每个代理层,原始 IP 地址会被包括在 X-Forwarded-For 中,但随后的代理可能会覆盖此信息。
  2. 缺乏标准化:不同的 CDN 和代理服务可能使用不同的方式来传递真实 IP,导致解析时的混乱。
  3. 安全风险:恶意用户可以伪造 X-Forwarded-For 字段,发送虚假的 IP 地址。

Nginx 中的配置

在 Nginx 中,正确配置以提取真实 IP 是至关重要的。以下是一些常见的配置方法:

1. 配置 Nginx 以获取真实 IP

在 Nginx 配置中,你可以使用 set_real_ip_fromreal_ip_header 指令来指定可信的代理和头部字段。

http {
    # 允许的代理 IP 地址
    set_real_ip_from 192.168.1.0/24;  # 你的 CDN 或反向代理的 IP 段
    set_real_ip_from 10.0.0.0/8;      # 内网 IP 范围

    # 指定真实 IP 头部
    real_ip_header X-Forwarded-For;
}

2. 处理链式 X-Forwarded-For

在多层代理中,Nginx 可能需要解析多个 IP 地址。你可以在 Nginx 中通过以下指令配置来处理这个问题:

map $http_x_forwarded_for $real_client_ip {
    '' $remote_addr;  # 如果没有 X-Forwarded-For,则使用远程地址
    default $http_x_forwarded_for;  # 否则,使用 X-Forwarded-For
}

server {
    location / {
        set $real_ip $real_client_ip;
        # 其他配置
    }
}

示例图示

以下是一个多层代理架构的示意图,展示了如何通过 CDN 和 Nginx 获取用户的真实 IP。

+---------------------+
|      用户请求      |
|   (真实 IP: A)     |
+---------------------+
          |
          v
+---------------------+
|      CDN 代理      |
|   (添加 A 到       |
|   X-Forwarded-For) |
+---------------------+
          |
          v
+---------------------+
|      Nginx 代理    |
|   (处理请求并      |
|   提取真实 IP)     |
+---------------------+
          |
          v
+---------------------+
|      目标服务器    |
|   (接收到 A)       |
+---------------------+

解决方案与建议

1. 确保代理可信

只信任来自已知和可信的代理服务器的请求,确保不会接受伪造的 X-Forwarded-For 字段。

2. 定期审计配置

定期检查和审计 Nginx 和 CDN 的配置,确保它们能够正确处理用户的真实 IP。

3. 监控日志

在日志中记录完整的请求信息,包括 X-Forwarded-For 和解析后的真实 IP,以便进行后续分析和问题排查。

总结

多层代理环境中获取用户真实 IP 的问题,尤其是在使用 Nginx 时,涉及到复杂的配置和安全性考量。通过正确配置 Nginx,使用标准的 X-Forwarded-For 处理方法,可以有效地获取用户的真实 IP 并保持系统的安全性。

PHP 多层代理 获取真实IP 问题

多层代理 获取真实IP 问题百度一搜 一堆. 但大多都是通过 X-Forwarded-For 获取真实IP
原理就是 负载 LVS /EOB /SLB 为了让下游正常获取 客户端IP 会将 客户端IP 填充到 X-Forwarded-For 中传递给下游服务

用户真实IP, 负载, 代理服务器1-IP代理服务器2-IP

我们原来获取真实IP 直接就 逗号炸开 取第一个IP

问题来了 客户端请求头 只需要添加 X-Forwarded-For 头信息 就可以伪造IP

解决方案:

  1. 根据自己服务代理层数决定 层数 != ip 数 就丢包
    /**
     * @desc 检测异常IP
     * @return string
     * @throws
     */
    public static function checkLimitIp()
    {
        $header_data = Http::getHeader();
        foreach (array('x-real-forwarded-for', 'x-forwarded-for', 'http_x_forwarded_for', 'x-real-ip', 'http_client_ip', 'remote_addr') as $v1) {
            if (isset($header_data[$v1])) {
                $ip_list = explode(',', $header_data[$v1]);
                // todo 注意 前端 slb + nginx IP
                $ip_num = count($ip_list);
                if ($ip_num > 2) {
                    throw new ErrorException(-114);
                }
            }
        }
    }
  1. 代理层除了第一层负载外 全部都是内网IP 所以只需要倒着数 找到最后一个外网IP 就可以定位到 负载IP , 负载IP 的前面就是真实客户端IP

真实深坑. 阿里云SLB 如果是覆盖 X-Forwarded-For , 不是 追加 X-Forwarded-For 就不会存在用户伪造问题. 也许阿里大佬有自己的想法吧 . 但在业务代码中 过滤真心麻烦....

Cloudflare 智能解析到国内服务器的安全过滤坑

在使用 Cloudflare 作为网站的 CDN 和 DNS 服务时,很多用户希望通过其智能解析功能,将流量导向国内服务器。然而,这种做法可能会遇到一些安全过滤的问题。本文将探讨在使用 Cloudflare 智能解析到国内服务器时可能遇到的坑,以及如何避免这些问题。

什么是 Cloudflare 智能解析?

Cloudflare 的智能解析功能允许用户根据地理位置将流量解析到不同的服务器。这意味着用户可以根据访问者的地理位置,动态选择最优的服务器来处理请求,从而提高网站的性能和响应速度。

国内服务器的挑战

在国内部署服务器时,尤其是通过 Cloudflare 智能解析,可能会面临以下几个问题:

1. 安全过滤

国内网络对内容的监管较为严格。很多情况下,Cloudflare 的 CDN 加速可能会因为内容政策而导致请求被拦截或过滤。这可能表现为:

  • 无法访问:某些请求可能会直接被屏蔽,导致用户无法访问网站。
  • 内容丢失:某些静态资源(如图像、JavaScript 文件等)可能无法加载,影响用户体验。

2. IP 黑名单

国内某些服务提供商会将 Cloudflare 的 IP 列入黑名单,导致访问受阻。由于 Cloudflare 的 IP 地址是动态变化的,维护 IP 白名单将非常困难。

3. SSL/TLS 证书问题

使用 Cloudflare 的 SSL 功能时,可能会出现证书验证失败的问题,尤其是在国内服务器上配置 SSL/TLS 证书时。需要确保:

  • 证书链完整:确保 SSL 证书的链条完整,以避免因证书问题导致的访问失败。
  • 正确配置:确保 Cloudflare 和服务器之间的 SSL 配置一致。

如何避免这些坑?

1. 内容合规性审核

在将网站内容通过 Cloudflare 智能解析到国内服务器之前,务必对网站内容进行审核,以确保符合国内法律法规。尤其是涉及敏感内容的部分,需谨慎处理。

2. 使用国内 CDN

考虑在国内使用 CDN 服务,以避免因 Cloudflare 的 IP 被封而导致的访问问题。许多国内 CDN 提供商能与 Cloudflare 互补,形成更好的访问体验。

3. 监控和日志分析

定期监控网站的访问日志,了解是否有访问失败的请求。通过分析日志,可以发现潜在的问题并及时调整配置。

4. 选择合适的 SSL/TLS 配置

确保服务器和 Cloudflare 之间的 SSL/TLS 配置正确,使用 Cloudflare 提供的 SSL 选项(如“完全”或“严格”模式),并确保所有证书均为有效状态。

总结

使用 Cloudflare 的智能解析功能将流量导向国内服务器时,可能会遇到安全过滤和访问问题。通过对内容进行合规性审核、选择合适的 CDN、监控访问日志以及正确配置 SSL/TLS,可以有效避免这些问题,确保网站的稳定性和安全性。

DNS 查询实用程式 dig

在网络管理和故障排除中,DNS(域名系统)是一个至关重要的组成部分。dig(Domain Information Groper)是一个强大的命令行工具,用于查询 DNS 记录。本文将介绍 dig 的基本用法、常见选项以及它在 DNS 排错中的应用。

什么是 dig

dig 是一个用于查询 DNS 记录的命令行工具。它可以帮助用户获取域名的相关信息,如 A 记录、MX 记录、CNAME 记录等。相比其他 DNS 查询工具,dig 提供了更为详细且易于理解的输出。

安装 dig

在大多数 Linux 发行版中,dig 通常包含在 dnsutilsbind-utils 包中。可以通过以下命令安装:

# Ubuntu/Debian 系统
sudo apt install dnsutils

# CentOS/RHEL 系统
sudo yum install bind-utils

基本用法

使用 dig 查询 DNS 记录的基本语法为:

dig [@server] [name] [type]
  • @server: 可选,指定要查询的 DNS 服务器(默认为系统配置的 DNS 服务器)。
  • name: 要查询的域名。
  • type: 可选,指定要查询的记录类型(如 A、MX、CNAME 等)。默认为 A 记录。

例子

  1. 查询 A 记录(IPv4 地址):
dig example.com
  1. 查询 MX 记录(邮件交换服务器):
dig example.com MX
  1. 查询 CNAME 记录(别名记录):
dig www.example.com CNAME

输出解析

dig 的输出包括多个部分,主要包括:

  • QUESTION SECTION: 查询的域名和类型。
  • ANSWER SECTION: DNS 服务器返回的结果。
  • AUTHORITY SECTION: 提供该域名的权威 DNS 服务器的信息。
  • ADDITIONAL SECTION: 额外的相关信息。

示例输出

; <<>> DiG 9.16.1-Ubuntu <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.            IN  A

;; ANSWER SECTION:
example.com.     3600    IN  A   93.184.216.34

;; Query time: 50 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Sep 30 14:15:19 UTC 2023
;; MSG SIZE  rcvd: 65

常用选项

  • +short: 仅返回简短的结果,适合快速查看。
dig example.com +short
  • +trace: 追踪查询路径,从根 DNS 服务器开始。
dig example.com +trace
  • +nssearch: 查询域名的权威 DNS 服务器。
dig example.com +nssearch

在 DNS 故障排除中的应用

1. 检查 DNS 解析

通过 dig 可以快速检查 DNS 是否解析正确。例如,查询一个域名的 A 记录,确保返回的 IP 地址是预期的。

2. 检查 MX 记录

使用 dig 查询 MX 记录,可以确认邮件服务器的配置是否正确:

dig example.com MX

3. 追踪 DNS 查询路径

使用 +trace 选项,可以查看 DNS 查询的整个过程,帮助确定问题的根源:

dig example.com +trace

示例图示

+---------------------+
|      用户请求      |
|   dig example.com   |
+---------------------+
          |
          v
+---------------------+
|   递归 DNS 服务器   |
|    (如 8.8.8.8)     |
+---------------------+
          |
          v
+---------------------+
|     权威 DNS 服务器  |
|    (返回结果)       |
+---------------------+

结论

dig 是一个功能强大且灵活的命令行工具,适用于 DNS 查询和故障排除。通过使用 dig,网络管理员和开发者可以快速获取域名的 DNS 记录,诊断和解决网络问题。

Linux 多功能系统资源统计 生成工具 dstat

官方对dstat的定义为:多功能系统资源统计生成工具。

在获取的信息上有点类似于topfreeiostatvmstat等多个工具的合集,官方解释为vmstat、iostat、ifstat等工具的多功能替代品,且添加了许多额外的功能(Dstat is a versatile replacement for vmstat, iostat and ifstat. Dstat overcomes some of the limitations and adds some extra features.);其结果可以保持到csv文件,使用脚本或第三方工具对性能进行分析利用(如通过监控平台监控,也可以保持到数据库)。

在Centos 6.x系统上安装基本服务器即默认安装,而在其他操作系统可能需要手动安装。

e.g.

监控CPU、内存、swap、磁盘使用率,并输出到csv。recordTime 是每条记录的间隔时间,以 秒 为单位。recordNum 是记录数。

 $ dstat -tcms --freespace --disk-util --output /home/TempFold/status.csv recordTime recordNum

此处的输出是追加模式。

找出占用资源最高的进程和用户

--top-(io|bio|cpu|cputime|cputime-avg|mem) 通过这几个选项,可以看到具体是那个用户那个进程占用了相关系统资源,对系统调优非常有效。如查看当前占用I/O、cpu、内存等最高的进程信息可以使用
$ dstat --top-mem --top-io --top-cpu

部分dstat的插件

--disk-util :显示某一时间磁盘的忙碌状况
--freespace :显示当前磁盘空间使用率
--proc-count :显示正在运行的程序数量
--top-bio :指出块I/O最大的进程
--top-cpu :图形化显示CPU占用最大的进程
--top-io :显示正常I/O最大的进程
--top-mem :显示占用最多内存的进程

查看:

$ dstat --list

internal:
    aio, cpu, cpu24, disk, disk24, disk24old, epoch, fs, int, int24, io, ipc, load, lock, mem, net, page, page24, proc, raw, socket, swap, swapold, 
    sys, tcp, time, udp, unix, vm

/usr/share/dstat:
    battery, battery-remain, cpufreq, dbus, disk-util, fan, freespace, gpfs, gpfs-ops, helloworld, innodb-buffer, innodb-io, innodb-ops, lustre, 
    memcache-hits, mysql-io, mysql-keys, mysql5-cmds, mysql5-conn, mysql5-io, mysql5-keys, net-packets, nfs3, nfs3-ops, nfsd3, nfsd3-ops, ntp, postfix, 
    power, proc-count, rpc, rpcd, sendmail, snooze, thermal, top-bio, top-cpu, top-cputime, top-cputime-avg, top-io, top-latency, top-latency-avg, 
    top-mem, top-oom, utmp, vm-memctl, vmk-hba, vmk-int, vmk-nic, vz-cpu, vz-io, vz-ubc, wifi

参考:

http://www.cnblogs.com/vincent-hv/p/3358194.html
http://linux.cn/article-3215-1.html
http://linux.die.net/man/1/dstat
">