GKE经policy based Cloud VPN连通本地数据库时Pod访问异常问题咨询

核心场景匹配基准 #

以下排查逻辑完全适配当前环境特征：VPC-native GKE 1.17.15-gke.800、Pod CIDR 10.0.0.0/14、Service CIDR 10.4.0.0/20、Policy-based Cloud VPN、独立VM与集群节点连通性正常、仅Pod无法访问本地数据库。

根因定位与对应解决方法 #

1. Policy-based Cloud VPN两侧路由/感兴趣流配置未覆盖GKE Pod网段 #

这是该场景下最高发的根因：

• 配置初期通常仅将VPC主网段（节点、独立VM所在网段）纳入隧道的感兴趣流匹配规则，未将Pod CIDR 10.0.0.0/14 加入双向流量匹配范围
• Policy-based VPN不会像动态路由VPN一样自动同步跨网段路由，本地数据中心侧的路由表没有针对10.0.0.0/14的回包路由，会直接丢弃来自Pod源IP的回包流量
  解决方法：
• 在本地VPN网关上修改隧道感兴趣流规则，新增匹配条目：源为10.0.0.0/14、目的为本地数据库所在网段
• 在本地路由表中新增静态路由：目标网段10.0.0.0/14，下一跳指向本地VPN隧道接口
• 若后续需要通过Service访问本地数据库，需同步将10.4.0.0/20加入两侧的路由与感兴趣流配置

2. VPC侧未配置指向Cloud VPN隧道的自定义网段路由 #

Policy-based VPN在GCP侧不会自动生成跨网段的VPC路由，默认路由仅覆盖VPC原生主网段的流量，Pod网段发往本地数据库的流量到达VPC边界时，会匹配默认公网路由而非进入VPN隧道。
解决方法：

• 在VPC网络中创建自定义静态路由：目标为本地数据库的CIDR范围，下一跳选择对应的Cloud VPN隧道接口，确保所有VPC内地址（包含Pod CIDR）的本地网段流量都被引流进入隧道
• 校验路由的应用区域，确保覆盖GKE集群节点所在的所有可用区

3. ip-masq-agent配置偏移导致Pod流量被错误SNAT #

GKE 1.17版本默认在节点上部署ip-masq-agent组件，若该组件的配置偏移，未将Pod CIDR纳入免SNAT范围：

• Pod发往本地数据库的流量会被节点自动SNAT转换为节点的主网卡IP，转换后的源IP无法匹配Policy-based VPN的感兴趣流规则，会被隧道直接丢弃
  解决方法：
• 拉取ip-masq-agent的配置校验：

  kubectl -n kube-system get configmap ip-masq-agent -o yaml
  

• 确保配置中的nonMasqueradeCIDRs列表包含Pod CIDR 10.0.0.0/14，保证Pod发往私网的流量不做SNAT转换，源IP保留为Pod自身地址
• 配置修改后等待ip-masq-agent自动同步，无需重启节点

4. 集群NetworkPolicy拦截Pod出口流量 #

网络策略仅作用于集群内的Pod流量，对节点、独立VM的流量无管控效果，因此会出现节点、VM连通正常但Pod被拦截的现象。
解决方法：

• 排查集群内的GKE原生/Calico网络策略规则，确认是否存在默认拒绝所有Pod出口流量的策略
• 为需要访问本地数据库的Pod补全对应的出口放行规则，允许目标Pod访问本地数据库的IP与端口
• 临时验证可在目标Pod所在命名空间添加临时放行规则，定位拦截点

内容的提问来源于stack exchange，提问作者Milen Tsvetkov