Varios proyectos de Google Cloud, ¿una VPN híbrida? Decida primero
La VPC compartida, el emparejamiento y un centro de conectividad responden a preguntas de propiedad distintas. Elija el límite de red antes de desplegar una VPN por proyecto.
Cuando varios proyectos de Google Cloud necesitan acceso híbrido, el instinto es una VPN por proyecto, y casi siempre es la forma equivocada. La propiedad del proyecto y el enrutamiento de paquetes son cuestiones relacionadas pero distintas, y la arquitectura útil conserva los límites administrativos que necesita mientras da a los prefijos previstos un único camino deliberado hacia la oficina o el centro de datos. Estas comprobaciones deciden qué modelo de red quiere realmente, en el orden que evita retrabajos. Cada una puede terminar la discusión antes de tiempo, y de eso se trata.
Un límite de proyecto no exige automáticamente su propio túnel.
Compruebe si el objeto compartido es la red
Empiece con una pregunta sobre la propiedad, no sobre la conectividad: ¿puede la propiedad central de la red soportar estas cargas de trabajo? Si la respuesta es sí y la organización tiene una configuración elegible, un proyecto anfitrión posee la VPC, las subredes y la conectividad, mientras que los proyectos de servicio poseen sus recursos de aplicación. Una conexión de Cloud VPN en esa red compartida puede entonces servir los prefijos de carga de trabajo previstos, sujeta a las políticas de enrutamiento y seguridad .
Sea preciso sobre lo que hace la asociación. Adjuntar un proyecto de servicio no fusiona su VPC independiente existente con la red anfitriona, ni mueve cada recurso automáticamente. La adjunción de cargas de trabajo, los permisos, el espacio de direcciones y el DNS forman parte de la arquitectura, no son consecuencias de la configuración. Lea la asociación primero como un cambio de permisos y después como un cambio de enrutamiento, porque los equipos suelen descubrir la diferencia durante la migración.
Si la propiedad central no es aceptable para los equipos implicados, deténgase aquí y trate el resto como un diseño de emparejamiento o de centro. Forzar Shared VPC sobre un grupo que necesita ciclos de vida de red independientes produce un problema político con un nombre técnico.
Compruebe si las VPC independientes pueden seguir siéndolo
El emparejamiento conserva VPC separadas, y por eso mismo atrae a equipos que quieren sus propios planes de direcciones y su propio control de cambios. La trampa es que el emparejamiento no es transitivo: el emparejamiento A-con-B y B-con-C no crea por sí mismo enrutamiento A-con-C a través de B. Si tres proyectos deben alcanzar un destino híbrido, necesita un plan de intercambio deliberado y no una cadena de emparejamientos.
Compartir la alcanzabilidad híbrida también depende del intercambio documentado de rutas personalizadas y de los anuncios previstos de Cloud Router. Un estado de emparejamiento activo demuestra que el emparejamiento existe, no que los prefijos que importan a cada lado se hayan exportado alguna vez. Compruebe los rangos exportados en ambos lados del par, en la configuración que realiza la exportación, y compárelos con las direcciones que sus cargas de trabajo usan realmente. Una discrepancia ahí es la razón más común de que un emparejamiento parezca sano mientras un prefijo sigue inalcanzable.
Escriba el plan de direcciones antes que nada. Los rangos que no se solapan, las rutas hacia cada destino previsto y los anuncios de retorno son los tres artefactos de los que este modelo vive o muere.
Compruebe si un modelo de centro encaja con la topología
Para un diseño más grande o segmentado de otra forma, la descripción general de Google Network Connectivity Center describe los modelos de centro y de radio. Léala por lo que admite la versión actual y no por lo que implica el diagrama: qué combinaciones de VPC e híbridas, qué familias de rutas y qué políticas permite cada tipo de radio.
Compruebe la familia de direcciones de forma explícita. Los ejemplos de planificación de la mayoría de guías, incluida esta, tratan de IPv4, y una función que existe para un tipo de radio no se aplica automáticamente sin cambios a otro. Si su entorno es de doble pila, esa pregunta pertenece a la elección del modelo, no a una migración posterior.
La tabla siguiente es el resumen de los tres modelos y la pregunta que decide cada uno.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Compruebe qué no concede el enrutamiento
El intercambio de rutas no es una concesión global de confianza. La resolución de DNS, el permiso del cortafuegos y la autorización de aplicaciones siguen siendo responsabilidades propias, y cada una la configura un propietario distinto en la mayoría de las organizaciones. Un diseño que asume que la alcanzabilidad implica autorización pasará su prueba de conectividad y suspenderá su revisión de seguridad.
Confirme también la historia de DNS para cada modelo, porque los arreglos de zona y reenvío difieren entre una red compartida y redes emparejadas. Los nombres privados que se resuelven en un proyecto no siguen una ruta hacia otro.
Registre la decisión y su propietario
Centralice donde la organización quiere un propietario de red compartido; mantenga VPC separadas donde lo exija el ciclo de vida o la política. Luego elija una relación de conectividad admitida y anote cuál eligió, quién posee la red compartida y qué puede anunciar cada proyecto.
Contar proyectos y comprar una VPN para cada uno no sustituye esa decisión de propiedad. Es la misma decisión, tomada más tarde, por quien hereda la factura y la tabla de enrutamiento.