Google PCNE: Conectividad privada a Google y servicios administrados — Guía de estudio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Network Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Información general

La conectividad privada a Google y a los servicios administrados abarca patrones que permiten que las cargas de trabajo se comuniquen con las API de Google, las redes de productores administradas por Google y los servicios de terceros sin usar IP públicas. Los objetivos son reducir el riesgo de exfiltración de datos, simplificar el cumplimiento normativo y mejorar la previsibilidad al mantener el tráfico en rutas privadas. Los componentes fundamentales incluyen Private Google Access (y endpoints restringidos), Private Services Access (para IP privadas a servicios administrados por Google), Private Service Connect (para la publicación y el consumo de servicios privados entre productor y consumidor, incluidas las API de Google), VPC Service Controls (creación de perímetros de datos), Cloud NAT (salida privada a la Internet pública) y mapeo de DNS para la selección determinista de endpoints.

El éxito del diseño depende de tres decisiones:

Qué mecanismo de acceso privado se ajusta al servicio y al modelo de seguridad (PGA vs. PSC para las API de Google, PSA vs. PSC para servicios administrados o de socios).
Cómo debe resolver el DNS los nombres de servicio a destinos privados sin interrumpir los servicios no compatibles.
Cómo interactúan el enrutamiento y la política de perímetro para que el tráfico permanezca privado de extremo a extremo en caso de fallo o cambio.

Los modos de fallo suelen derivarse de la selección de rutas, el orden del DNS, el alcance regional de los endpoints o reglas de perímetro que deniegan llamadas de forma silenciosa. Valida cada capa: resolución de nombres, ruta, firewall, estado del endpoint y política de servicio.

Private Google Access, endpoints restringidos y selección de endpoints

Private Google Access (PGA) permite que las VM y los nodos de GKE sin IP externas alcancen las API y los servicios de Google utilizando las VIP anycast de Google a través de la puerta de enlace de Internet predeterminada de la VPC, no a través de Cloud NAT. Se habilita por subred.

Endpoints:
- private.googleapis.com (199.36.153.8/30): superficie completa de las API de Google.
- restricted.googleapis.com (199.36.153.4/30): subconjunto de API compatibles con VPC Service Controls. Usa este cuando apliques perímetros de servicio.
Enfoques de mapeo de DNS:
- Mantener los nombres públicos predeterminados y permitir que los clientes accedan al DNS público. Esto funciona si permites la salida a través de Cloud NAT, pero debilita los controles de exfiltración de datos.
- Sobrescribir nombres de host de API específicos en una zona privada de Cloud DNS para googleapis.com con CNAMEs hacia restricted.googleapis.com (o private.googleapis.com) para forzar la resolución privada por servicio. Ejemplo: crea una zona privada googleapis.com y añade storage.googleapis.com CNAME restricted.googleapis.com.
Consideraciones de enrutamiento:
- PGA requiere una ruta a la puerta de enlace de Internet predeterminada. Si envías 0.0.0.0/0 a un NGFW de terceros, añade rutas de host explícitas para que las VIP de las API de Google usen la puerta de enlace de Internet predeterminada:

undefined

Modo de fallo: Si faltan estas rutas de host, las instancias sin IP externas no pueden alcanzar las API cuando el siguiente salto (next-hop) de 0.0.0.0/0 es una instancia de firewall.
Configuración de la subred:

undefined

Ventajas y desventajas:

restricted.googleapis.com reduce el riesgo de exfiltración, pero algunas API no están disponibles.
El tráfico de PGA omite Cloud NAT, por lo que los registros de NAT no lo mostrarán. Usa VPC Flow Logs en la subred.

Para clientes on-prem, puedes proporcionar acceso privado a las API de Google ya sea anunciando 199.36.153.4/30 y/o 199.36.153.8/30 a la red on-prem a través de Cloud VPN/Interconnect con la puerta de enlace de Internet predeterminada en la VPC como siguiente salto, o exponiendo endpoints de PSC (ver más abajo) y mapeando el DNS on-prem a esos endpoints.

Acceso a servicios privados y Private Service Connect

El Acceso a servicios privados (PSA) proporciona conectividad IP privada a redes de productor gestionadas por Google que alojan servicios como Cloud SQL (IP privada) y Memorystore. Usted asigna un rango RFC1918 en su VPC para que Google lo use y establece una conexión de peering con la red del productor de servicios.

Patrón de configuración:
- Reservar un rango de direcciones para el peering de VPC:

undefined

Establecer la conexión privada:

undefined

Aprovisionar el servicio gestionado con IP privada.
Notas operativas:
- El rango debe ser lo suficientemente grande para todas las instancias y no debe superponerse con rangos existentes.
- El peering no es transitivo; el tráfico debe originarse desde la VPC en peering (los recursos locales [on-prem] pueden acceder a través de la VPC si el enrutamiento lo permite).
- Cambiar o reducir el rango más tarde causa interrupciones; planifique la capacidad.

Private Service Connect (PSC) extiende la conectividad privada a:

API de Google (el consumidor crea puntos de conexión [endpoints] con IP privadas en una subred, y el DNS asigna los nombres de las API a esas IP).
Servicios de socios y SaaS publicados mediante adjuntos de servicio (service attachments).
Sus propios servicios publicados de forma privada a otros proyectos u organizaciones mediante adjuntos de servicio.

Modelo productor-consumidor:

El productor publica un adjunto de servicio en una región, respaldado por un balanceador de carga interno. El productor puede requerir listas de admisión (allowlists) de proyectos/organizaciones de consumidores y especificar cuotas de conexión.
El consumidor crea un punto de conexión de PSC (regla de reenvío) en la misma región, apuntando al adjunto de servicio del productor. El punto de conexión obtiene una IP de la subred elegida.

Restricciones de diseño y contrapartidas:

PSC es regional; despliegue por región cerca de los consumidores. Use políticas de DNS o registros ponderados para dirigir a los clientes cercanos y proporcionar conmutación por error (failover).
No hay transitividad a través de PSC; los consumidores no pueden encadenar servicios a través de un punto de conexión.
La IP de origen no se conserva de extremo a extremo a través de PSC; diseñe los controles del lado del productor teniendo esto en cuenta (por ejemplo, confíe en la identidad o en la autorización a nivel de aplicación).

Modos de fallo comunes:

Los fallos en las comprobaciones de estado (health checks) del ILB del productor provocan que se rechacen las conexiones de PSC.
El punto de conexión del consumidor se crea en una región diferente a la del adjunto de servicio.
Una política de denegación del productor o la falta de un proyecto en la lista de admisión bloquea las conexiones.
El DNS no apunta a la IP del punto de conexión, o zonas privadas superpuestas que resuelven al destino incorrecto.

VPC Service Controls, perímetros, entrada/salida (ingress/egress) y mapeo de DNS

VPC Service Controls (VPC-SC) define perímetros de servicio alrededor de los recursos gestionados por Google para mitigar la exfiltración de datos. Dentro de un perímetro, las solicitudes a los servicios protegidos deben originarse en proyectos dentro del alcance y cumplir con cualquier nivel de acceso configurado.

Perímetros:
- Los perímetros estándar protegen los proyectos que alojan datos (por ejemplo, BigQuery, Cloud Storage).
- Los puentes de perímetro (perimeter bridges) permiten una interacción limitada entre perímetros que de otro modo estarían aislados.
- Las reglas de entrada (ingress) otorgan acceso específico desde fuera del perímetro (por ejemplo, desde proyectos de CI/CD o monitorización).
- Las reglas de salida (egress) restringen a qué servicios externos o proyectos dentro de Google Cloud se puede llamar.
Selección de punto de conexión (endpoint):
- Use restricted.googleapis.com para limitar las llamadas a la API a servicios compatibles con VPC-SC y evitar llamadas accidentales a puntos de conexión públicos que no son conscientes del perímetro.
- PSC para las API de Google ofrece un control más estricto al mantener el tráfico en IP privadas y habilitar la afinidad regional, pero aún requiere la configuración del perímetro para la autorización.
DNS y nomenclatura:
- Implemente DNS de horizonte dividido (split-horizon) con zonas privadas de Cloud DNS para que los clientes internos resuelvan los nombres de las API a destinos privados.
- Prefiera registros por servicio o CNAME a restricted.googleapis.com en lugar de usar un comodín para todo googleapis.com, lo que puede romper servicios que deben permanecer públicos.
- Para PSC, publique registros A que apunten a la IP de cada punto de conexión. Use zonas separadas por entorno para evitar el consumo accidental entre entornos.

Errores comunes:

Usar Cloud NAT para acceder a googleapis.com público puede eludir la intención de VPC-SC, a menos que las reglas del perímetro restrinjan explícitamente la salida (egress); combine NAT con DNS restringido o PSC.
Algunas API tienen múltiples nombres de host (por ejemplo, puntos de conexión JSON vs. XML); asegúrese de que su mapeo de DNS cubra todos los nombres que usan sus clientes.
Una configuración incorrecta del perímetro falla en modo cerrado (fail-closed); monitorice los registros de Access Transparency y VPC-SC para detectar denegaciones.

Patrones de salida, acceso híbrido y solución de problemas

Patrones de salida para cargas de trabajo privadas:

Solo APIs de Google: Habilite PGA y asigne el DNS a restricted.googleapis.com, o implemente PSC para las APIs de Google y asigne el DNS a las IP de los endpoints.
Internet y SaaS: Use Cloud NAT para instancias sin IP externas. Dimensione NAT para el pico de conexiones y puertos concurrentes; supervise el agotamiento de puertos.
Mezcla con un NGFW de terceros: Mantenga el NGFW como predeterminado, pero agregue rutas de host específicas a las VIP anycast de las API de Google para garantizar que PGA omita el firewall. Para destinos que no son de Google, envíe el tráfico al NGFW o a Cloud NAT según la política.

Clientes híbridos (on-prem u otras nubes):

Para consumir APIs de Google de forma privada:
- Opción A: Private Google Access para entornos on-premise anunciando 199.36.153.4/30 y/o 199.36.153.8/30 desde Cloud Router hacia el entorno on-prem con el next hop en la puerta de enlace de internet predeterminada de la VPC; asigne el DNS on-prem a restricted/private.googleapis.com según sea necesario.
- Opción B: Endpoints de PSC para las APIs de Google en su VPC; expóngalos a través de Cloud VPN/Interconnect enrutando hacia las IP de los endpoints y asignando el DNS on-prem correspondientemente.
Para alcanzar servicios administrados por Google con IP privadas (a través de PSA), establezca conectividad con la VPC (Cloud VPN/Interconnect), asegúrese de que los rangos RFC1918 no se superpongan, propague las rutas y permita las reglas de firewall.

Solución de problemas y verificación:

DNS: Haga dig o nslookup al nombre de host de la API desde un cliente y verifique que se resuelva a la dirección privada deseada (IP del endpoint de PSC) o a las VIP anycast de restricted/private. Verifique el orden de las políticas de Cloud DNS y las zonas privadas en la VPC.
Enrutamiento: Ejecute gcloud compute routes list y confirme que la ruta más específica coincida con el next hop deseado (puerta de enlace de internet predeterminada para las VIP de PGA, interna para PSC).
Firewall: Verifique que las reglas de egreso permitan TCP 443 a las IP de destino. Para productores con balanceo de carga detrás de PSC, verifique que los rangos de origen de las verificaciones de estado (health checks) estén permitidos.
PGA: Confirme que la configuración de la subred esté habilitada y que existan rutas de host para 199.36.153.4/30 y/o 199.36.153.8/30 si hay una ruta predeterminada personalizada.
PSA: Ejecute gcloud services vpc-peerings list para confirmar que el peering de servicenetworking esté ACTIVE y que el rango asignado sea correcto y no se use en otro lugar.
PSC: En el consumidor, describa el endpoint para ver el estado de la conexión; en el productor, verifique las conexiones pendientes o rechazadas y el estado del ILB. Verifique la lista de consumidores permitidos (allowlist) del adjunto de servicio (service attachment).
Cloud NAT: Use los registros y métricas de NAT para confirmar las traducciones y verifique la asignación o el agotamiento de puertos. Si una instancia tiene una IP externa, omite NAT por diseño.

Escenario de un problema práctico

Contoso Research ejecuta análisis en dos regiones (us-east1, europe-west1). La seguridad exige que ninguna VM tenga una IP pública, que las APIs de Google sean accesibles de forma privada y bajo VPC Service Controls, que los usuarios on-prem necesiten acceso privado a una instancia de Cloud SQL (IP privada) y que el SaaS de un socio se consuma de forma privada. Un NGFW de terceros es el next hop de egreso predeterminado.

Habilitar Private Google Access y endpoints restringidos

Acción: Habilite Private Google Access en todas las subredes de análisis. Cree zonas privadas de Cloud DNS para googleapis.com y agregue CNAME para las APIs requeridas (BigQuery, Pub/Sub, Cloud Storage) a restricted.googleapis.com. Agregue rutas de host para 199.36.153.4/30 a la puerta de enlace de internet predeterminada en ambas regiones.
Justificación: Asegura que el tráfico de VM a API se mantenga privado, sea compatible con VPC-SC y omita el NGFW sin crear un egreso amplio a internet.

Crear un perímetro de VPC Service Controls

Acción: Coloque los proyectos de análisis y los proyectos de datos dentro de un perímetro de servicio. Agregue niveles de acceso para las redes corporativas de Contoso según sea necesario y permita explícitamente los flujos entre proyectos requeridos a través de reglas de ingreso. Evite los puentes de perímetro (perimeter bridges) excepto cuando esté estrictamente justificado.
Justificación: Reduce el riesgo de exfiltración de datos desde servicios administrados por Google y se alinea con el uso de endpoints restringidos.

Aprovisionar Cloud SQL con Private Services Access

Acción: Asigne un /24 para PSA, conecte servicenetworking y cree una instancia de Cloud SQL con IP privada en us-east1. Propague las rutas de la VPC hacia el entorno on-prem a través de Interconnect y permita las reglas de firewall.
Justificación: Proporciona alcanzabilidad privada RFC1918 tanto desde las cargas de trabajo de la VPC como desde los clientes on-prem sin exposición pública.

Proporcionar acceso privado on-prem a las APIs de Google

Acción: Anuncie 199.36.153.4/30 desde Cloud Router hacia el entorno on-prem, con el next hop en la puerta de enlace de internet predeterminada de la VPC. En el DNS on-prem, asigne los mismos nombres de host de API a restricted.googleapis.com.
Justificación: Permite que los clientes on-prem usen la misma ruta privada restringida, garantizando una aplicación de políticas consistente y minimizando la varianza operativa.

Consumir el SaaS del socio a través de Private Service Connect

Acción: El socio comparte un adjunto de servicio (service attachment) regional. Cree endpoints de PSC en las subredes de us-east1 y europe-west1 apuntando al adjunto. Publique registros A privados (saas.partner.contoso) que apunten a cada endpoint regional; use DNS ponderado para preferir el acceso regional.
Justificación: Mantiene el tráfico SaaS en IP privadas con listas de proyectos permitidos (allowlists) aplicadas por el productor, mejora la latencia a través de la afinidad regional y evita el egreso público.

Mantener Cloud NAT para el egreso a internet que no es de Google

Acción: Implemente puertas de enlace de Cloud NAT por región, dimensionadas para los flujos pico. Asegúrese de que la ruta predeterminada siga apuntando al NGFW, excepto las rutas de host específicas para las VIP restringidas.
Justificación: Permite una salida controlada a destinos que no son de Google, al tiempo que garantiza que el tráfico de las API de Google permanezca privado y que el NGFW conserve la visibilidad central.

Validar y supervisar

Acción: Para cada tipo de cliente, verifique la resolución de DNS, la selección de ruta y la conectividad TLS. Revise los registros de VPC-SC en busca de denegaciones, los registros de NAT para el egreso que no es de Google y los estados de conexión de PSC. Agregue alertas de estado y disponibilidad para los ILB detrás del adjunto de servicio del socio y para Cloud SQL.
Justificación: Confirma que la ruta de datos coincide con la intención del diseño y saca a la luz las regresiones de forma temprana, especialmente cuando cambian el DNS, las rutas o los perímetros.

← Cloud DNS · Todos los dominios · Enrutamiento →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →