API de Google por VPN: enruta la VIP, no solo la subred

Entra por SSH en el servidor local, levanta el túnel y la VM privada responde; después la primera llamada a una API de Google falla sin ruta. La subred de la VM y las VIP de la API son destinos distintos, así que una ruta para una no selecciona la otra. Deben cumplirse tres condiciones antes de que una llamada privada a la API funcione. El nombre de la API debe resolverse a una VIP, el prefijo VIP debe anunciarse por el túnel y la VPC debe saber cómo enviar la respuesta de vuelta. Un ping no te dice nada de eso, y una sesión SSH que funciona hacia una máquina de la subred tampoco.

Las VIP de la API son destinos separados

Google publica VIP dedicadas para el acceso a la API desde la red local, y esas son las direcciones que tu DNS debe devolver para los nombres de la API. Ambas son prefijos pequeños y ninguna es espacio RFC 1918:

Las direcciones que parecen públicas no significan que la ruta deba salir del túnel para el internet ordinario. Los prefijos existen para que un cliente local alcance los frontales de Google por una ruta admitida en lugar de un punto de salida arbitrario. Trátalos como destinos que pertenecen al túnel, no como hosts que sondear. Una regla de cortafuegos escrita para la salida a internet suele descartarlos, y es una razón habitual por la que una llamada falla antes de empezar.

El DNS decide a qué extremo llegas

Apunta el resolutor local a los registros que Google documenta para el extremo elegido, de modo que los nombres que necesita la aplicación respondan con esa VIP. Solo googleapis.com no es un inventario: los registros de paquetes, los registros de contenedores y los conectores de migración tienen sus propios nombres documentados. La VIP restringida tampoco lleva todos los servicios, así que un nombre que se resuelve puede seguir sin soporte. Anota los dominios que la aplicación contacta realmente antes de tocar el resolutor.

Adivinar una dirección de VM de la VPC como sustituto de un nombre de servicio no es una solución, y normalmente oculta el hueco de DNS hasta que falla otro cliente.

Anuncia el prefijo VIP, conserva el resto

Con una conexión basada en BGP, el Cloud Router debe anunciar el prefijo VIP elegido para que el router local aprenda ese rango por la sesión prevista. Anunciar solo las subredes de la VPC no añade ese rango, y el router local sigue usando su ruta por defecto para esas direcciones. El prefijo de la tabla de rutas es la única prueba de que el anuncio cruzó la sesión.

Conserva los anuncios existentes mientras añades el nuevo, porque las opciones a nivel de router y a nivel de par tienen alcance distinto, y cambiar el conjunto puede retirar redes que ya funcionaban. Después comprueba el anuncio efectivo en cada sesión en lugar de en el router entero. Un prefijo ausente y un prefijo retirado se ven iguales desde el lado local, así que la vista de la sesión es lo que separa una omisión de una regresión.

El lado de la VPC necesita su propia ruta y camino de vuelta

Dentro de la VPC, el camino de la VIP debe usar la puerta de enlace de internet predeterminada como siguiente salto, y pese al nombre ese tráfico se queda dentro de la red de Google. La VPC también necesita una ruta de vuelta al origen local por la VPN, que es un objeto aparte del prefijo anunciado. Ten en cuenta los requisitos regionales de enrutamiento documentados cuando el túnel y el cliente no están en la misma región.

Comprueba el camino de vuelta de forma independiente, porque una dirección de petición que funciona puede ocultar una dirección de respuesta rota. Dos direcciones, dos rutas, y cada una falla con su propio síntoma.

Prueba la petición y luego lee el rechazo

El eco ICMP no obtiene respuesta de estas VIP, así que un ping fallido no demuestra nada y uno correcto demuestra muy poco. Desde el cliente real, examina la respuesta del nombre y la ruta seleccionada, y luego haz una petición HTTPS autorizada al servicio que te interesa. Si la petición llega al servicio y se rechaza, mira las credenciales, IAM y cualquier política de perímetro de servicio que se aplique.

El enrutamiento privado no concede autorización de API y no cambia lo que la identidad puede hacer. El éxito del transporte y una respuesta autorizada son resultados separados, y necesitas ambos. Mantén también explícito el camino IPv6, porque configurar los prefijos IPv4 no dice nada sobre un cliente que prefiere IPv6.

La guía de Google sobre Private Google Access desde la red local cubre juntos los registros DNS y los requisitos de enrutamiento, así que compara tu configuración de resolutor y de anuncio con ella y no con una publicación de foro. Después repite la misma petición y anota la respuesta y la ruta en el mismo tique.