网关安全策略中IP过滤的实操配置指南

公司新上线的内部管理系统刚跑起来，就发现日志里频繁出现来自境外IP的扫描请求。运维同事没多想，直接在网关上加了一条IP过滤规则，把几个可疑段全拦了——结果第二天销售部反馈，客户从某地ISP访问时页面白屏。问题出在哪？不是规则写错了，而是漏掉了真实业务IP的例外放行。

IP过滤不是黑名单列表，而是策略组合

很多团队把网关IP过滤当成“加黑名单”来用：看到异常IP就add，越积越多，最后规则臃肿、顺序混乱、维护困难。真正有效的IP过滤，得结合业务场景分层设计。比如对外API网关，通常分三层：
• 全局拒绝（如已知恶意IP段）
• 白名单优先（如仅允许合作方IDC出口IP）
• 动态临时放行（如运维跳板机出口IP，带TTL时效）

常见网关的配置示例

以Nginx作为反向代理网关为例，在http块或server块中配置：

geo $bad_ip {
  default 0;
  192.168.34.0/24 1;
  203.124.55.123 1;
  2a01:cb08::/32 1;
}

map $bad_ip $blocked {
  1 1;
  default 0;
}

server {
  if ($blocked) {
    return 403;
  }
  # 后续proxy_pass等配置
}

注意：geo模块必须放在http顶层，不能嵌套在server里；if虽不推荐用于复杂逻辑，但做简单IP拦截是轻量且稳定的方案。

别忽略IPv6和云环境特殊性

现在新部署的系统基本都默认开启IPv6，但很多IP过滤规则只写了IPv4。某次压测中，测试工具走IPv6通道绕过所有过滤，导致接口被刷崩。另外，公有云SLB或ALB背后可能有健康检查IP池（比如阿里云SLB会用100.64.0.0/10段发探针），如果盲目封整个私有地址段，健康检查失败，后端直接被摘除。

验证比配置更重要

配完别急着reload。先用curl模拟不同来源IP测试：

# 模拟恶意IP访问（假设本机已绑定该IP）
sudo ip addr add 192.168.34.100/32 dev lo
curl -H "X-Real-IP: 192.168.34.100" http://api.example.com/health
# 应返回403

# 模拟合法客户IP
curl -H "X-Real-IP: 203.112.88.5" http://api.example.com/health
# 应返回200

线上环境建议搭配Prometheus+Grafana监控过滤命中数，当某条规则命中突增，可能意味着攻击模式变化，也可能是业务方悄悄改了出口IP没同步。

IP过滤不是一劳永逸的盾牌，而是一道需要持续校准的门禁。每天花两分钟看一眼过滤日志里的TOP10新IP，比堆一百条静态规则更管用。