AWS NACL对EKS Kubernetes集群不生效 无法阻断特定IP访问

这类EKS场景下NACL单IP拦截失效、配置0.0.0.0/0全网段Deny却能正常拦截的问题，通常由以下原因导致：

• 流量路径导致源IP识别偏差：EKS上部署的Web服务默认通过ALB/NLB对外暴露，你访问服务时连接的是负载均衡地址而非EC2节点公网IP，此时到达节点网卡的流量源IP是负载均衡的节点IP，并非你的客户端公网IP，配置针对自身公网IP的Deny规则自然无法匹配流量；配置全网段Deny时会同时阻断负载均衡来源的流量，因此表现为全量拦截。这也是单独EC2测试正常、EKS场景失效的最核心差异点。
• NACL规则匹配顺序错误：NACL按照规则序号从小到大依次匹配，命中规则后直接执行动作、不再遍历后续规则。如果添加的单IP Deny规则序号大于已有的宽范围允许规则（比如低序号规则允许0.0.0.0/0访问80/443端口），流量会先命中允许规则被放行，永远不会触发后续的Deny规则。
• NACL关联子网不全：EKS工作节点通常分布在多可用区的多个子网中，若仅给部分子网的NACL添加单IP拦截规则，负载均衡会将流量转发到其他未配置规则的子网节点上，导致拦截失效；配置全网段Deny时若覆盖了所有关联子网，就会出现全流量阻断的效果。
• 规则配置细节错误：比如Deny规则方向误配为出站、端口范围和Web服务实际端口不匹配、IP段CIDR格式错误（如公网IP未加/32掩码导致网段范围偏差），这类配置错误在单独EC2测试SSH场景下因为端口、方向匹配所以拦截正常，换到Web服务场景就会失效。

• 验证直连节点的拦截效果：跳过负载均衡地址，直接通过EKS节点公网IP+服务NodePort访问Web服务，如果此时Deny规则生效，说明之前失效的原因是流量经过负载均衡，NACL无法获取真实客户端源IP。
• 核对NACL规则顺序：逐一检查入站规则的序号，确认单IP Deny规则的序号是否小于所有允许对应Web端口的规则序号，是否存在低序号的宽范围允许规则提前放行了流量。
• 检查NACL关联范围：列出EKS集群所有工作节点、负载均衡所在的子网，确认这些子网是否全部关联了配置拦截规则的NACL，是否存在遗漏的子网仍使用默认全允许的NACL。
• 校验规则配置细节：确认Deny规则为入站方向、协议和端口范围与Web服务一致、拦截IP的CIDR格式正确（单IP需配置为x.x.x.x/32）。
• 抓包确认真实源IP：在EKS节点上执行tcpdump port <Web服务端口> -nn抓取入站流量，查看实际发起连接的源IP地址，确认和你预期拦截的客户端IP是否一致。

• 调整NACL规则优先级：将针对恶意IP的Deny规则序号调整到所有允许规则之前（比如序号设为10-50区间，低于现有业务允许规则的序号），确保拦截规则优先匹配。
• 适配负载均衡场景的拦截逻辑：
  • 若使用NLB暴露服务，开启NLB的客户端IP保留功能后，节点侧即可看到真实客户端IP，此时NACL规则可以正常匹配拦截
  • 若使用ALB暴露服务，NACL层面无法直接识别客户端源IP，不建议在NACL做客户端IP拦截，可改用WAF、ALB关联安全组的方式实现恶意IP封禁
• 统一子网NACL配置：给所有EKS节点、负载均衡所在的子网绑定统一的NACL规则组，避免流量从漏配规则的子网绕路。
• 配置分层拦截：NACL仅作为子网边界的粗粒度拦截手段，针对Web服务的恶意IP拦截，可配合安全组、WAF、应用层访问控制规则做多层防护，避免单层配置失效导致拦截绕过。

内容的提问来源于stack exchange，提问作者Aman Deep