GKE, VPNs y el caso de los paquetes perdidos: una guía de enmascaramiento de IP

En entornos empresariales es habitual que aplicaciones desplegadas en Kubernetes necesiten conectarse con sistemas internos del cliente. En este caso, el reto consistía en conectar un cluster de Google Kubernetes Engine (GKE) con servicios alojados en la red on-premise mediante una VPN.

Aunque la conectividad parecía correctamente configurada, las peticiones nunca llegaban al destino. Este artículo explica el problema real, por qué ocurre en GKE y cómo resolverlo.

Preparación del entorno

El punto de partida era una arquitectura híbrida donde un cluster de GKE debía consumir servicios internos del cliente, la conexión se establecía mediante VPN y era necesario validar rutas y conectividad entre proyectos en Google Cloud.

Para ello se configuró:

• Una VPN entre Google Cloud y la red del cliente
• Enrutamiento interno entre proyectos
• Resolución DNS cruzada

Escenario de red (la arquitectura)

La arquitectura seguía un modelo estándar en Google Cloud:

Conectividad híbrida

Una VPN (Meraki) establece el túnel entre Google Cloud y el entorno on-premise.

Topología hub-and-spoke

• Proyecto Shared (Hub): centraliza la VPN y el enrutamiento
• Proyecto TST (Spoke): contiene el cluster de GKE y Cloud SQL
• Conexión entre ambos mediante Shared VPC o VPC Peering

Resolución DNS

Uso de Cloud DNS Peering Zones para que el cluster en TST pueda resolver servicios que viven en el lado del cliente a través del túnel en Shared.

El misterio: paquetes que no llegan

Una vez validado:

• El túnel VPN estaba activo
• Las rutas eran correctas
• La resolución DNS funcionaba

Las peticiones seguían fallando.

El síntoma clave: el tráfico nunca alcanzaba la red del cliente.

La trampa: identidad de los paquetes en GKE

La trampa estaba en la identidad del paquete: el tráfico se originaba con la IP del rango secundario del Pod, la cual no estaba autorizada en la infraestructura del cliente (solo lo estaba el rango principal del nodo).

Descubrimos que GKE, por defecto, no aplica enmascaramiento (masquerade) a los rangos internos RFC 1918, provocando que el tráfico saliera con una IP 'desconocida' para la VPN.

• Si el destino es una IP interna -> GKE NO enmascara la ip del pod.
• Si el destino es una IP externa -> GKE SÍ enmascara la ip con la del nodo.

Resultado: La VPN estaba en un rango que GKE consideraba "interno", pero el cliente solo conocía la IP del Nodo.

La solución: controlar el enmascaramiento de IP

Para solucionarlo, descartamos ampliar rangos en el cliente por ser una solución poco limpia.

En su lugar, implementamos el ip-masq-agent como un DaemonSet. Este agente nos permitió definir, mediante un ConfigMap, qué rangos específicos no deben enmascararse, forzando que el resto del tráfico use la IP del nodo (rango principal).

Así, las llamadas a los servicios externos fueron finalmente aceptadas por la VPN.

Implementación del ip-masq-agent

Se desplegó como DaemonSet en el cluster, junto con un ConfigMap personalizado:

kind: ConfigMap
metadata:
  name: ip-masq-agent
  namespace: kube-system
data:
  config: |
    nonMasqueradeCIDRs:
      - 10.x.x.x/y
      - 100.x.x.x/y
      - 170.x.x.x/y
    resyncInterval: 60s

Cuándo aplicar esta solución

Este enfoque es especialmente relevante cuando:

• Se trabaja con GKE en modo VPC-native
• Existen rangos secundarios para pods
• La red on-premise tiene restricciones estrictas de IP
• Se utiliza conectividad híbrida (VPN o Interconnect)

Conclusión

En entornos híbridos, no basta con que la red funcione. Es necesario entender cómo se comporta el tráfico dentro del cluster.

El enmascaramiento de IP en GKE puede parecer un detalle menor, pero puede bloquear completamente la comunicación con sistemas externos si no se gestiona correctamente.

Controlarlo de forma explícita permite alinear la infraestructura cloud con las políticas del cliente, evitar errores difíciles de diagnosticar y escalar la arquitectura sin dependencias frágiles.