AWS EKS Pod与外部树莓派安全通信的方案验证及NAT网关公网IP配置的安全性咨询

阿华AIGC实验室

2026-4-3

我明白你现在的困惑——好不容易打通了EKS Pod到树莓派的SSH，但用NAT网关公网IP做安全组规则总觉得心里不踏实，这很正常，咱们一步步拆解问题，先搞清楚核心原因，再聊聊这个配置的安全性，最后给你几个优化方向。

先搞清楚：为什么EKS集群CIDR在安全组里不起作用？

你遇到的第一个问题其实是EKS网络的默认行为导致的：EKS集群里的Pod默认通过NAT网关访问公网，这时候Pod对外的源IP会被替换成NAT网关的公网IP，而不是Pod所在的集群内网IP（10.50.0.0/16段）。所以你把集群CIDR加到OpenVPN服务器的安全组里，相当于允许内网IP访问，但实际请求的源是NAT的公网IP，自然匹配不上，这就是为什么加NAT IP才生效的原因。

核心问题：用NAT网关公网IP做安全组规则安全吗？

直接说结论：这个配置有一定安全风险，主要体现在两点：

攻击面过大：这个NAT网关是整个EKS集群的公网出口，所有Pod的出站流量都用这个IP。意味着你把OpenVPN服务器的端口开放给了集群里的所有Pod——如果集群里有恶意Pod、被入侵的应用，或者不小心部署了有漏洞的服务，它们都能尝试连接你的OpenVPN服务器，相当于扩大了潜在的攻击范围。
维护风险：NAT网关的公网IP不是永久固定的，如果哪天NAT网关因为故障、扩容或者其他原因被替换，IP会发生变化，这时候你的安全组规则就失效了，需要手动更新，容易引发业务中断。

优化的安全方案（按优先级/复杂度排序）

既然知道了风险，咱们可以从几个方向优化，让整个架构更安全：

1. 先纠正安全组的端口配置（最紧急的小调整）

我注意到你提到安全组里配置了SSH协议，其实这里可能有个误解：你是通过VPN隧道访问树莓派的SSH，所以OpenVPN服务器的公网安全组只需要开放OpenVPN的服务端口（通常是UDP 1194），不需要开放SSH端口。SSH流量是在VPN隧道内部传输的，不会经过OpenVPN服务器的公网网卡，所以公网安全组管不到这部分流量。先把安全组里的SSH规则去掉，只保留OpenVPN端口的规则，能先减少一部分不必要的暴露。

2. 缩小安全组的开放范围，避免给整个集群开权限

如果不想让所有Pod都能访问OpenVPN服务器，可以调整EKS的网络配置，让需要访问树莓派的特定Pod使用独立的出口IP：

用EKS的Pod ENI模式：开启后，特定Pod可以直接分配VPC的内网IP，对外访问时源IP就是这个内网IP，这时候你就可以在OpenVPN服务器的安全组里添加这些Pod所在的子网CIDR，甚至单个Pod的ENI IP，大大缩小开放范围。
配置自定义路由策略：给需要访问VPN的Pod所在的命名空间或者服务账户配置单独的路由，让它们走另一个专门的NAT网关，这个NAT网关只给这些Pod用，然后安全组里只加这个专属NAT的IP，减少暴露面。

3. 给OpenVPN服务器加双重验证

即使安全组开放了，也可以在OpenVPN层面加额外的身份验证，比如：

强制使用证书认证：OpenVPN本身支持客户端证书验证，只有持有合法证书的Pod（或者说运行OpenVPN客户端的Pod）才能建立连接，即使有人拿到了NAT IP，没有证书也连不上。
在OpenVPN服务器上配置内部防火墙规则：比如限制VPN连接后的内网流量只能到树莓派的网段，禁止访问其他不必要的IP，进一步降低风险。

4. 把OpenVPN移到EKS同区域，走内网访问

如果可能的话，把OpenVPN服务器从us-east-1移到us-east-2（和EKS同区域），然后通过VPC peering或者直接把OpenVPN服务器放到EKS所在的VPC里，这样Pod可以通过内网IP访问OpenVPN服务器，不需要走公网NAT。这时候安全组里直接加EKS的集群CIDR或者子网CIDR就可以了，完全避免公网IP暴露的问题，同时还能降低延迟。