文章

阿里云NAT网关SNAT入方向流量异常排查

阿里云 NAT 网关 SNAT 入方向流量异常排查

一、问题背景

在阿里云公网 NAT 网关监控中，发现某个内网 IP 的 SNAT 入方向流量异常偏高。

异常内网 IP：

  • 10.111.226.250

现象：

  • 入方向带宽高
  • 出方向带宽低
  • 流量稳定持续

后续确认该 IP 是 Kubernetes 集群中的一个 Pod IP。

二、排查结论

本次 NAT 网关入方向流量高，并不是公网绕过 Ingress/Nginx 白名单访问服务。

实际链路更可能是：

Pod -> NAT 网关 -> 公网邮箱服务器
公网邮箱服务器 -> NAT 网关 -> Pod

其中：

  • 10.111.226.250 主动连接 183.47.101.192:995
  • 995 是 POP3S 邮件收取端口
  • 183.47.101.192 高度疑似 QQ 邮箱 POP3S 相关服务器

因此 NAT 网关中看到的入方向高，实际是公网邮箱服务器返回给 Pod 的数据流量。

三、完整排查流程

3.1 查看 NAT 网关 SNAT 转发实时数据排名

入口：

阿里云控制台
-> 公网 NAT 网关
-> 监控
-> SNAT 转发实时数据排名

发现内网 IP：

  • 10.111.226.250

在 SNAT 转发实时数据排名中流量最高，尤其是：

  • 入方向带宽高

并且该流量不是瞬时突发，而是稳定持续存在。

3.2 确认高流量 IP 是 Pod

通过 Kubernetes 查询：

kubectl get pod -A -o wide | grep 10.111.226.250

确认：

  • 10.111.226.250 是某个 Pod IP

这一步说明异常流量不是普通 ECS 主机流量，而是某个业务 Pod 产生的 SNAT 流量。

3.3 理解 NAT 网关入方向和出方向

阿里云 NAT 网关监控里的方向，不能简单理解成”公网访问服务”或者”服务访问公网”。

在 SNAT 场景中：

Pod/ECS -> NAT 网关 -> 公网

这是 NAT 网关的出方向流量。

公网返回：

公网 -> NAT 网关 -> Pod/ECS

这是 NAT 网关的入方向流量。

因此：

  • SNAT 入方向流量高 通常表示：内网 Pod/ECS 正在从公网接收大量返回数据

常见场景包括：

  • 下载文件
  • 拉取镜像
  • 调用外部接口返回大量数据
  • 收取邮件
  • 访问外部服务产生大响应

不等价于：

  • 公网主动打进了业务服务

3.4 查看阿里云 NAT 网关流量分析

在阿里云 NAT 网关流量分析中，继续查看高流量通信对象。

排查目标：

  • 内网 IP：10.111.226.250

查到流量最高的外部 IP，例如：

  • 183.47.101.192

然后查看外部 IP 的流量趋势。

重点对比：

  • 10.111.226.250 的 NAT 网关入方向流量趋势
  • 183.47.101.192 的流量趋势

如果二者趋势高度一致，例如：

  • 同时升高
  • 同时下降
  • 峰值时间一致
  • 持续时间一致

则可以初步判断：

  • 10.111.226.250 的高入方向流量，很可能由 183.47.101.192 返回的数据造成

3.5 抓包确认五元组

在确认 Pod IP 和外部 IP 的趋势对应后，再进行抓包。

可以在 Pod 所在节点或 debug 容器中抓包：

tcpdump -nn -i any 'host 10.111.226.250 and host 183.47.101.192 and (tcp or udp)'

或者只抓目标外部 IP 和端口：

tcpdump -nn -i any 'host 183.47.101.192 and port 995'

抓到的典型五元组：

183.47.101.192.995 -> 10.111.226.250.36008
10.111.226.250.36008 -> 183.47.101.192.995

还出现了多个本地临时端口，例如：

  • 36008
  • 48330
  • 54676

都在与 183.47.101.192:995 通信。

四、如何从五元组判断连接方向

典型连接：

10.111.226.250:36008 -> 183.47.101.192:995
183.47.101.192:995 -> 10.111.226.250:36008

其中：

  • 10.111.226.250:36008 是 Pod 的本地临时端口
  • 183.47.101.192:995 是远端固定服务端口

一般情况下，客户端会使用临时端口访问服务端固定端口。

因此可以判断：

  • 10.111.226.250 是客户端
  • 183.47.101.192:995 是服务端

也就是：

  • Pod 主动连接了 183.47.101.192:995

如果是公网主动访问业务服务，常见形态应该更像：

公网 IP:随机端口 -> 业务服务 IP:80/443/业务端口

而不是：

公网 IP:995 -> Pod IP:随机端口

五、识别 183.47.101.192:995

端口 995 对应服务：

  • POP3S
  • POP3 over SSL/TLS

常用于邮件客户端安全收取邮件。

结合排查结果：

  • 183.47.101.192:995 高度疑似 QQ 邮箱 POP3S 服务

因此本次流量很可能是：

  • Pod 中的业务程序或任务在收取 QQ 邮箱邮件

六、为什么 Ingress/Nginx 白名单挡不住

Ingress/Nginx 白名单控制的是入站访问链路：

公网用户 -> SLB/Ingress Nginx -> Service -> Pod

它限制的是：

  • 外部用户访问我的服务

但本次流量链路更像：

Pod -> NAT 网关 -> 公网邮箱服务器
公网邮箱服务器 -> NAT 网关 -> Pod

这是：

  • 出站访问 (egress)
  • SNAT 流量

所以即使 Ingress/Nginx 配置了白名单，也不会限制 Pod 主动访问公网。

七、后续验证命令

7.1 查 Pod

kubectl get pod -A -o wide | grep 10.111.226.250

记录：

  • namespace
  • pod name
  • node name
  • container name

7.2 查环境变量

kubectl exec -it -n <namespace> <pod-name> -- sh

进入容器后执行：

env | grep -Ei 'mail|email|smtp|pop|imap|qq|995|465|587'

7.3 查配置文件

grep -RniE 'mail|email|smtp|pop|imap|qq|995|465|587|183.47.101.192|pop.qq.com|smtp.qq.com' /app /etc 2>/dev/null

7.4 查应用日志

kubectl logs -n <namespace> <pod-name> --since=1h \
  | grep -Ei 'mail|email|smtp|pop|imap|qq|995|183.47.101.192|pop.qq.com'

如果是多容器 Pod：

kubectl logs -n <namespace> <pod-name> -c <container-name> --since=1h \
  | grep -Ei 'mail|email|smtp|pop|imap|qq|995|183.47.101.192|pop.qq.com'

7.5 查当前连接

ss -ntp | grep '183.47.101.192:995'

可能看到类似：

ESTAB 0 0 10.111.226.250:36008 183.47.101.192:995 users:(("java",pid=123,...))

7.6 使用 debug 容器排查

如果业务容器中没有 tcpdump、ss 等工具，可以使用：

kubectl debug -it -n <namespace> <pod-name> \
  --image=nicolaka/netshoot \
  --target=<container-name> \
  -- sh

进入后执行：

ss -ntp | grep '183.47.101.192:995'

或抓包：

tcpdump -nn -i any 'host 183.47.101.192 and port 995'

7.7 抓 SYN 包确认谁主动发起

tcpdump -nn -i any 'host 183.47.101.192 and port 995 and tcp[tcpflags] & tcp-syn != 0'

如果看到：

10.111.226.250.36008 > 183.47.101.192.995: Flags [S]

说明：

  • 10.111.226.250 主动发起连接

如果看到：

183.47.101.192.995 > 10.111.226.250.36008: Flags [S.]

这是服务端返回 SYN ACK，也符合 Pod 主动连接外部服务的 TCP 三次握手过程。

八、如果确认不是预期流量，治理方向

Ingress 白名单不适合治理这个问题。

应该从出方向访问控制入手。

可选方案：

方案作用
Kubernetes NetworkPolicy限制 Pod 出方向访问
Cilium Egress Policy更细粒度控制 Pod 出公网
阿里云安全组出方向规则从节点/ECS 维度限制公网访问
阿里云云防火墙统一管控公网出方向访问
应用配置治理删除异常邮箱配置、脚本、定时任务或第三方依赖

如果业务确实需要访问 QQ 邮箱，需要继续确认：

  • 是否为预期业务逻辑
  • 是否有死循环拉取邮件
  • 是否在下载大附件
  • 是否多个副本重复拉取
  • 是否有异常账号配置
  • 是否有第三方组件自动收取邮件

九、最终结论

本次 NAT 网关入方向流量高的完整排查链路如下：

  1. 先从 NAT 网关 SNAT 转发实时数据排名发现 10.111.226.250 入方向带宽最高。

  2. 确认 10.111.226.250 是 Pod IP，并且流量稳定持续。

  3. 查看阿里云 NAT 网关流量分析，定位到流量最高的外部 IP。

  4. 对比外部 IP 的流量趋势和该 Pod 的 NAT 网关流量趋势，发现趋势高度对应。

  5. 在此基础上进行抓包，确认五元组。

  6. 抓包发现大量：

    10.111.226.250:临时端口 <-> 183.47.101.192:995

  7. 根据端口形态判断：

    • 10.111.226.250 是客户端
    • 183.47.101.192:995 是服务端

  8. 995 是 POP3S 邮件收取端口，183.47.101.192 高度疑似 QQ 邮箱相关服务器。

  9. 因此 NAT 网关入方向高，实际是 QQ 邮箱服务器返回给 Pod 的数据流量。

  10. 该问题与 Ingress/Nginx 白名单无直接关系，因为 Ingress 白名单只限制公网入站访问，不限制 Pod 主动出公网访问。

十、关键词

  • 阿里云
  • NAT 网关
  • SNAT
  • 入方向流量
  • 出方向流量
  • Kubernetes
  • Pod
  • tcpdump
  • 五元组
  • POP3S
  • QQ 邮箱
  • Ingress 白名单
  • egress
  • NetworkPolicy
  • 云防火墙

创建时间： 2026-05-19
分类： Network Issues