Segmentación y conectividad de red para aplicaciones distribuidas en Cross-Cloud Network

Last reviewed 2025-01-30 UTC

Este documento forma parte de una serie de guías de diseño de redes entre nubes.

La serie consta de las siguientes partes:

En esta parte se analiza la estructura y la conectividad de la segmentación de la red, que es la base del diseño. En este documento se explican las fases en las que debes tomar las siguientes decisiones:

  • La segmentación general de la red y la estructura del proyecto.
  • Dónde colocas tu carga de trabajo.
  • Cómo se conectan tus proyectos a redes externas on-premise y de otros proveedores de servicios en la nube, incluido el diseño de la conectividad, el enrutamiento y el cifrado.
  • Cómo se conectan internamente entre sí tus redes de VPC.
  • Cómo se conectan entre sí las subredes de tu VPC y a otras redes, incluido cómo configuras la accesibilidad de los servicios y el DNS. Google Cloud

Segmentación de red y estructura de proyectos

Durante la fase de planificación, debes elegir entre dos estructuras de proyecto:

  • Un proyecto de host de infraestructura consolidado, en el que se usa un único proyecto de host de infraestructura para gestionar todos los recursos de red de todas las aplicaciones
  • Proyectos del host segmentados, en los que se usa un proyecto del host de infraestructura junto con un proyecto del host diferente para cada aplicación

Durante la fase de planificación, te recomendamos que también decidas los dominios administrativos de tus entornos de carga de trabajo. Define el alcance de los permisos de tus administradores y desarrolladores de infraestructura según el principio de mínimos accesos y define el alcance de los recursos de las aplicaciones en diferentes proyectos de aplicaciones. Como los administradores de infraestructura deben configurar la conectividad para compartir recursos, los recursos de infraestructura se pueden gestionar en un proyecto de infraestructura. Por ejemplo, para configurar la conectividad a los recursos de infraestructura compartidos, los administradores de infraestructura pueden usar un proyecto de infraestructura para gestionar esos recursos compartidos. Al mismo tiempo, el equipo de desarrollo puede gestionar sus cargas de trabajo en un proyecto, mientras que el equipo de producción puede hacerlo en otro proyecto. Los desarrolladores usarían los recursos de infraestructura del proyecto de infraestructura para crear y gestionar recursos, servicios, balanceo de carga y políticas de enrutamiento de DNS para sus cargas de trabajo.

Además, debes decidir cuántas redes de VPC implementarás inicialmente y cómo se organizarán en tu jerarquía de recursos. Para obtener información sobre cómo elegir una jerarquía de recursos, consulta el artículo Decidir una jerarquía de recursos para tu Google Cloud zona de aterrizaje. Para obtener más información sobre cómo elegir el número de redes de VPC, consulta Decidir si se deben crear varias redes de VPC.

En el caso de la red entre nubes, te recomendamos que utilices las siguientes VPCs:

  • Una o varias VPCs de aplicaciones para alojar los recursos de las diferentes aplicaciones.
  • Una o varias VPCs de tránsito, donde se gestiona toda la conectividad externa.
  • Una o varias VPCs de acceso a servicios, que se pueden usar para consolidar la implementación del acceso privado a los servicios publicados.

En el siguiente diagrama se muestra una representación visual de la estructura de VPC recomendada que acabamos de describir. Puedes usar la estructura de VPC que se muestra en el diagrama con una estructura de proyecto consolidada o segmentada, como se describe en las secciones posteriores. En el diagrama que se muestra aquí no se indica la conectividad entre las redes VPC.

Estructura de VPC recomendada

Proyecto de host de infraestructura consolidada

Puedes usar un proyecto host de infraestructura consolidado para gestionar todos los recursos de red, como redes y subredes de VPC, hubs de Network Connectivity Center, emparejamiento entre redes de VPC y balanceadores de carga.

En el proyecto host de infraestructura se pueden crear varias VPCs compartidas de aplicaciones con sus proyectos de servicio de aplicaciones correspondientes para que coincidan con la estructura de la organización. Usa varios proyectos de servicio de aplicaciones para delegar la administración de recursos. Toda la red de todas las VPCs de aplicaciones se factura al proyecto host de infraestructura consolidada.

En esta estructura de proyecto, muchos proyectos de servicio de aplicación pueden compartir un número menor de VPCs de aplicación.

En el siguiente diagrama se muestra una representación visual del proyecto de host de infraestructura consolidado y de los varios proyectos de servicio de aplicación que se han descrito. El diagrama no muestra la conectividad entre todos los proyectos.

Proyecto host de infraestructura consolidado y varios proyectos de servicio de aplicaciones

Proyectos host segmentados

En este patrón, cada grupo de aplicaciones tiene su propio proyecto de host de aplicaciones y sus redes de VPC. Se pueden vincular varios proyectos de servicio de aplicaciones al proyecto del host. La facturación de los servicios de red se divide entre el proyecto del host de infraestructura y los proyectos del host de aplicaciones. Los cargos por infraestructura se facturan al proyecto host de la infraestructura, y los cargos de red, como los de transferencia de datos de las aplicaciones, se facturan a cada proyecto host de la aplicación.

En el siguiente diagrama se muestra una representación visual de los varios proyectos host y los varios proyectos de servicio de aplicación que se han descrito. El diagrama no muestra la conectividad entre todos los proyectos.

Varios proyectos del host y varios proyectos del servicio de aplicaciones

Colocación de cargas de trabajo

Muchas opciones de conectividad dependen de las ubicaciones regionales de tus cargas de trabajo. Para obtener orientación sobre cómo colocar cargas de trabajo, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine. Debes decidir dónde se ubicarán tus cargas de trabajo antes de elegir las ubicaciones de conectividad.

Conectividad externa e híbrida

En esta sección se describen los requisitos y las recomendaciones de las siguientes rutas de conectividad:

  • Conexiones privadas a otros proveedores de servicios en la nube
  • Conexiones privadas a centros de datos locales
  • Conectividad a Internet para cargas de trabajo, especialmente conectividad saliente

Cross-Cloud Network implica la interconexión de varias redes en la nube o redes on-premise. Las redes externas pueden ser propiedad de diferentes organizaciones y estar gestionadas por ellas. Estas redes se conectan físicamente entre sí en una o varias interfaces de red a red (NNIs). La combinación de las NNIs debe diseñarse, aprovisionarse y configurarse para ofrecer rendimiento, resiliencia, privacidad y seguridad.

Para conseguir modularidad, reutilización y la capacidad de insertar NVAs de seguridad, coloca las conexiones externas y el enrutamiento en una VPC de tránsito, que luego servirá como servicio de conectividad compartido para otras VPCs. Las políticas de enrutamiento para la resiliencia, la conmutación por error y la preferencia de ruta entre dominios se pueden configurar una vez en la VPC de tránsito y se pueden usar en muchas otras redes de VPC.

El diseño de las NNIs y la conectividad externa se utilizan más adelante para la conectividad interna y las redes de VPC.

En el siguiente diagrama se muestra una VPC de tránsito que actúa como servicio de conectividad compartido para otras VPCs, que están conectadas mediante el emparejamiento entre redes de VPC, Network Connectivity Center o una VPN de alta disponibilidad. Para simplificar la ilustración, el diagrama muestra una sola VPC de tránsito, pero puedes usar varias VPCs de tránsito para la conectividad en diferentes regiones.

VPC de tránsito usada como servicio de conectividad compartido para otras VPCs

Conexiones privadas a otros proveedores de servicios en la nube

Si tienes servicios que se ejecutan en otras redes de proveedores de servicios en la nube (CSP) a las que quieres conectarte a tu red Google Cloud , puedes hacerlo a través de Internet o mediante conexiones privadas. Recomendamos las conexiones privadas.

Al elegir las opciones, ten en cuenta el rendimiento, la privacidad, el coste y la viabilidad operativa.

Para maximizar el rendimiento y mejorar la privacidad, usa una conexión directa de alta velocidad entre redes de nubes. Las conexiones directas eliminan la necesidad de equipos de red físicos intermedios. Te recomendamos que uses Cross-Cloud Interconnect, que proporciona estas conexiones directas, así como el cifrado MACsec y una tasa de transferencia de hasta 100 Gbps por enlace.

Si no puedes usar Cross-Cloud Interconnect, puedes usar la interconexión dedicada o Partner Interconnect a través de una instalación de colocación.

Selecciona las ubicaciones en las que te conectas a los otros CSPs en función de la proximidad de la ubicación a las regiones de destino. Para seleccionar una ubicación, tenga en cuenta lo siguiente:

  • Consulta la lista de ubicaciones:
    • En el caso de Cross-Cloud Interconnect, consulta la lista de ubicaciones que están disponibles para Google Cloud y proveedores de servicios en la nube (la disponibilidad varía según el proveedor de servicios en la nube).
    • En el caso de la interconexión dedicada o Partner Interconnect, elige una ubicación de baja latencia para la instalación de colocación.
  • Evalúa la latencia entre el punto de presencia (POP) de la periferia y la región correspondiente de cada CSP.

Para maximizar la fiabilidad de tus conexiones entre nubes, te recomendamos una configuración que admita un acuerdo de nivel de servicio de tiempo de actividad del 99,99% para las cargas de trabajo de producción. Para obtener más información, consulta Alta disponibilidad de Cross-Cloud Interconnect, Establecer un 99,99% de disponibilidad en la interconexión dedicada y Establecer un 99,99% de disponibilidad en Partner Interconnect.

Si no necesitas un ancho de banda elevado entre diferentes CSPs, puedes usar túneles VPN. Este enfoque puede ayudarte a empezar y puedes cambiar a Cross-Cloud Interconnect cuando tus aplicaciones distribuidas usen más ancho de banda. Los túneles VPN también pueden alcanzar un acuerdo de nivel de servicio del 99,99 %. Para obtener más información, consulta Topologías de VPN de alta disponibilidad.

Conexiones privadas a centros de datos locales

Para conectarse a centros de datos privados, puede usar una de las siguientes opciones de conectividad híbrida:

  • Interconexión dedicada
  • Partner Interconnect
  • VPN de alta disponibilidad

Las consideraciones de enrutamiento de estas conexiones son similares a las de las conexiones privadas con otros proveedores de servicios en la nube.

En el siguiente diagrama se muestran las conexiones a redes on-premise y cómo los routers on-premise pueden conectarse a Cloud Router mediante una política de emparejamiento:

Conexiones a redes on-premise

Enrutamiento entre dominios con redes externas

Para aumentar la resiliencia y el rendimiento entre las redes, usa varias rutas para conectar las redes.

Cuando el tráfico se transfiere entre dominios de red, los dispositivos de seguridad con estado deben inspeccionarlo. Por lo tanto, es necesario que el flujo sea simétrico en el límite entre los dominios.

En las redes que transfieren datos entre varias regiones, el coste y el nivel de calidad del servicio de cada red pueden variar significativamente. Puedes decidir usar unas redes en lugar de otras en función de estas diferencias.

Configura tu política de enrutamiento entre dominios para cumplir tus requisitos de tránsito entre regiones, simetría del tráfico, rendimiento y resiliencia.

La configuración de las políticas de enrutamiento entre dominios depende de las funciones disponibles en el perímetro de cada dominio. La configuración también depende de cómo se estructuran los dominios vecinos desde el punto de vista de un sistema autónomo y de las direcciones IP (subredes) en diferentes regiones. Para mejorar la escalabilidad sin superar los límites de prefijos en los dispositivos perimetrales, te recomendamos que tu plan de direccionamiento IP dé como resultado menos prefijos agregados para cada combinación de región y dominio.

Al diseñar el enrutamiento entre regiones, ten en cuenta lo siguiente:

  • Google Cloud Las redes de VPC y Cloud Router admiten el enrutamiento global entre regiones. Otros CSPs pueden tener VPCs regionales y ámbitos de protocolo de pasarela fronteriza (BGP). Para obtener más información, consulta la documentación de tu otro proveedor de servicios en la nube.
  • Cloud Router anuncia automáticamente las rutas con preferencias de ruta predeterminadas en función de la proximidad regional. Este comportamiento de enrutamiento depende del modo de enrutamiento dinámico configurado de la VPC. Es posible que tengas que anular estas preferencias para obtener el comportamiento de enrutamiento que quieras.
  • Los distintos CSPs admiten diferentes funciones de BGP y de detección de reenvío bidireccional (BFD), y Cloud Router de Google también tiene funciones específicas de políticas de rutas, tal como se describe en el artículo Establecer sesiones de BGP.
  • Los distintos CSPs pueden usar diferentes atributos de desempate de BGP para determinar la preferencia de las rutas. Consulta la documentación de tu CSP para obtener más información.

Enrutamiento entre dominios de una sola región

Te recomendamos que empieces con el enrutamiento entre dominios de una sola región y que lo uses como base para crear conexiones entre dominios de varias regiones.

Los diseños que usan Cloud Interconnect deben tener al menos dos ubicaciones de conexión que estén en la misma región, pero en dominios de disponibilidad de borde diferentes.

Decide si quieres configurar estas conexiones duplicadas con un diseño activo/activo o activo/pasivo:

  • La configuración activo-activo usa el enrutamiento de rutas múltiples de igual coste (ECMP) para agregar el ancho de banda de ambas rutas y usarlas simultáneamente para el tráfico entre dominios. Cloud Interconnect también admite el uso de enlaces agregados con LACP para alcanzar hasta 200 Gbps de ancho de banda agregado por ruta.
  • Activo/pasivo obliga a un enlace a estar en espera, y solo recibe tráfico si se interrumpe el enlace activo.

Recomendamos un diseño activo/activo para los enlaces intrarregionales. Sin embargo, algunas topologías de redes locales combinadas con el uso de funciones de seguridad con estado pueden requerir un diseño activo/pasivo.

Cloud Router se crea en varias zonas, lo que proporciona una mayor resiliencia que un solo elemento. En el siguiente diagrama se muestra cómo convergen todas las conexiones resilientes en un único router de Cloud de una región. Este diseño puede admitir un acuerdo de nivel de servicio con una disponibilidad del 99,9% en una sola área metropolitana si se siguen las directrices para establecer una disponibilidad del 99,9 % en la interconexión dedicada.

En el siguiente diagrama se muestran dos routers on-premise conectados de forma redundante al servicio de Cloud Router gestionado en una sola región:

Las conexiones resilientes pueden usar un solo Cloud Router

Enrutamiento entre dominios multirregional

Para proporcionar conectividad de respaldo, las redes pueden emparejarse en varias zonas geográficas. Al conectar las redes de varias regiones, el acuerdo de nivel de servicio de disponibilidad puede aumentar hasta el 99,99%.

En el siguiente diagrama se muestran las arquitecturas con un acuerdo de nivel de servicio del 99,99 %. Muestra routers on-premise en dos ubicaciones diferentes conectados de forma redundante a los servicios de Cloud Router gestionados en dos regiones diferentes.

Conexiones de Cloud Interconnect en varias regiones

Además de la resiliencia, el diseño de enrutamiento multirregional debe lograr la simetría del flujo. El diseño también debe indicar la red preferida para las comunicaciones entre regiones, lo que puedes hacer con el enrutamiento hot-potato y cold-potato. Combina el enrutamiento de patata fría en un dominio con el enrutamiento de patata caliente en el dominio peer. En el caso del dominio de cold potato, recomendamos usar elGoogle Cloud dominio de red, que proporciona funciones de enrutamiento de VPC global.

La simetría de flujo no siempre es obligatoria, pero la asimetría de flujo puede provocar problemas con las funciones de seguridad con estado.

En el siguiente diagrama se muestra cómo puedes usar el enrutamiento hot potato y cold potato para especificar tu red de tránsito interregional preferida. En este caso, el tráfico de los prefijos X e Y permanece en la red de origen hasta que llega a la región más cercana al destino (enrutamiento cold potato). El tráfico de los prefijos A y B cambia a la otra red en la región de origen y, a continuación, viaja por la otra red hasta el destino (rutado hot potato).

Usar el enrutamiento de patata caliente y patata fría para especificar tu red de tránsito interregional preferida

Cifrado del tráfico entre dominios

A menos que se indique lo contrario, el tráfico no se cifra en las conexiones de Cloud Interconnect entre diferentes proveedores de servicios en la nube o entre centros de datos locales y de Google Cloud . Si tu organización requiere cifrado para este tráfico, puedes usar las siguientes funciones:

  • MACsec para Cloud Interconnect: cifra el tráfico a través de las conexiones de Cloud Interconnect entre tus routers y los routers perimetrales de Google. Para obtener más información, consulta la información general sobre MACsec para Cloud Interconnect.
  • VPN de alta disponibilidad mediante Cloud Interconnect: usa varios túneles de VPN de alta disponibilidad para poder proporcionar todo el ancho de banda de las conexiones de Cloud Interconnect subyacentes. Los túneles de VPN de alta disponibilidad están cifrados con IPsec y se implementan a través de conexiones de Cloud Interconnect que también pueden estar cifradas con MACsec. En esta configuración, las conexiones de Cloud Interconnect se configuran para permitir solo el tráfico de la VPN de alta disponibilidad. Para obtener más información, consulta la descripción general de la VPN de alta disponibilidad mediante Cloud Interconnect.

Conectividad a Internet para cargas de trabajo

Tanto para la conectividad a Internet entrante como saliente, se supone que el tráfico de respuesta sigue de forma estatal la dirección inversa de la dirección de la solicitud original.

Por lo general, las funciones que proporcionan conectividad a Internet de entrada son independientes de las funciones de salida, con la excepción de las direcciones IP externas, que proporcionan ambas direcciones simultáneamente.

Conectividad a Internet de entrada

La conectividad a Internet de entrada se centra principalmente en proporcionar endpoints públicos para los servicios alojados en la nube. Por ejemplo, la conectividad a Internet con servidores de aplicaciones web y servidores de juegos alojados enGoogle Cloud.

Las principales funciones que proporcionan conectividad a Internet entrante son los productos Cloud Load Balancing de Google. El diseño de una red de VPC es independiente de su capacidad para proporcionar conectividad a Internet entrante:

Conectividad a Internet saliente

Entre los ejemplos de conectividad a Internet saliente (en los que la solicitud inicial procede de la carga de trabajo y se dirige a un destino de Internet) se incluyen las cargas de trabajo que acceden a APIs de terceros, descargan paquetes de software y actualizaciones, y envían notificaciones push a endpoints de webhook en Internet.

Para la conectividad saliente, puedes usar Google Cloud opciones integradas, como se describe en el artículo Conectar máquinas virtuales privadas a Internet. También puede usar NVAs de NGFW centrales, como se describe en Seguridad de la red.

La forma principal de proporcionar conectividad a Internet saliente es el destino de la puerta de enlace de Internet predeterminada en la tabla de enrutamiento de la VPC, que suele ser la ruta predeterminada en las VPCs de Google. Tanto las IPs externas como Cloud NAT (el servicio NAT gestionado deGoogle Cloud) requieren una ruta que apunte a la pasarela de Internet predeterminada de la VPC. Por lo tanto, los diseños de enrutamiento de VPC que anulan la ruta predeterminada deben proporcionar conectividad saliente por otros medios. Para obtener más información, consulta la descripción general de Cloud Router.

Para proteger la conectividad saliente, Google Cloud ofrece tanto la aplicación de Cloud Next Generation Firewall como Secure Web Proxy para proporcionar un filtrado más profundo de las URLs HTTP y HTTPS. Sin embargo, en todos los casos, el tráfico sigue la ruta predeterminada hacia la puerta de enlace de Internet predeterminada o a través de una ruta predeterminada personalizada en la tabla de enrutamiento de la VPC.

Usar tus propias IPs

Puedes usar direcciones IPv4 propiedad de Google para la conectividad a Internet o usar la función Trae tu propia dirección IP (BYOIP) para usar un espacio IPv4 propiedad de tu organización. La mayoría de los Google Cloud productos que requieren una dirección IP enrutable por Internet admiten el uso de intervalos BYOIP en su lugar.

También puedes controlar la reputación del espacio de IP mediante su uso exclusivo. BYOIP ayuda a mejorar la portabilidad de la conectividad y puede ahorrar costes de direcciones IP.

Conectividad interna y redes de VPC

Con el servicio de conectividad externa e híbrida configurado, los recursos de la VPC de tránsito pueden acceder a las redes externas. El siguiente paso es hacer que esta conectividad esté disponible para los recursos alojados en otras redes de VPC.

En el siguiente diagrama se muestra la estructura general de la VPC, independientemente de cómo hayas habilitado la conectividad externa. Muestra una VPC de tránsito que finaliza las conexiones externas y aloja un router de Cloud Router en cada región. Cada router de Cloud Router recibe rutas de sus pares externos a través de las NNIs de cada región. Las VPCs de aplicaciones están conectadas a la VPC de tránsito para que puedan compartir la conectividad externa. Además, la VPC de tránsito funciona como centro de las VPCs de radio. Las VPCs de spoke pueden alojar aplicaciones, servicios o una combinación de ambos.

Estructura general de Cross-Cloud Network

Para obtener un rendimiento y una escalabilidad óptimos con los servicios de redes en la nube integrados, las VPCs deben conectarse mediante Network Connectivity Center, tal como se describe en el artículo sobre la conectividad entre VPCs con Network Connectivity Center. Network Connectivity Center ofrece lo siguiente:

  • Acceso transitivo a los endpoints de nivel 4 y nivel 7 de Private Service Connect y a sus servicios asociados
  • Acceso transitivo a redes on-premise aprendidas a través de BGP
  • Escala de redes de VPC de 250 redes por hub

Si quieres insertar dispositivos virtuales de red (NVAs) para usar cortafuegos u otras funciones de red, debes usar el emparejamiento entre redes de VPC. Los cortafuegos perimetrales pueden permanecer en redes externas. Si es necesario insertar una NVA, utiliza el patrón de conectividad entre VPCs con el emparejamiento entre redes de VPC para interconectar tus VPCs.

Configura el reenvío y el emparejamiento de DNS en la VPC de tránsito. Para obtener más información, consulta la sección sobre el diseño de la infraestructura de DNS.

En las siguientes secciones se describen los posibles diseños de conectividad híbrida que admiten la conectividad IP básica y las implementaciones de puntos de acceso a la API.

Conectividad entre VPCs con Network Connectivity Center

Recomendamos que todas las VPCs de aplicaciones, las VPCs de tránsito y las VPCs de acceso a servicios se conecten mediante radios de VPC de Network Connectivity Center.

Los puntos de acceso de los consumidores de servicios se implementan en VPCs de acceso a servicios cuando necesitan ser accesibles desde otras redes (otras VPCs o redes externas). Puedes desplegar puntos de acceso de consumidor de servicios en las VPCs de las aplicaciones si solo se debe poder acceder a estos puntos desde la VPC de la aplicación.

Si necesitas proporcionar acceso a servicios que se encuentran detrás del acceso a servicios privados, crea una VPC de acceso a servicios que esté conectada a una VPC de tránsito mediante una VPN de alta disponibilidad. A continuación, conecta la VPC de servicios gestionados a la VPC de acceso a servicios. La VPN de alta disponibilidad permite el enrutamiento transitivo desde otras redes.

El diseño es una combinación de dos tipos de conectividad:

  • Network Connectivity Center: proporciona conectividad entre VPCs de tránsito, VPCs de aplicaciones y VPCs de acceso a servicios que alojan endpoints de Private Service Connect.
  • Conexiones entre VPCs de VPN de alta disponibilidad: proporcionan conectividad transitiva para las subredes de acceso a servicios privados alojadas en VPCs de acceso a servicios. Estas VPCs de acceso a servicios no deben añadirse como radios del eje de Network Connectivity Center.

Cuando combines estos tipos de conectividad, ten en cuenta lo siguiente:

  • Redistribución de las subredes de emparejamiento entre redes de VPC y de emparejamiento de Network Connectivity Center en el enrutamiento dinámico (a la VPC de acceso a servicios a través de la VPN de alta disponibilidad y a las redes externas a través de las interconexiones híbridas)
  • Consideraciones sobre el enrutamiento multirregional
  • Propagación de rutas dinámicas en el emparejamiento entre redes de VPC y el emparejamiento de Network Connectivity Center (desde la VPC de acceso a servicios a través de una VPN de alta disponibilidad y desde redes externas a través de interconexiones híbridas)

En el siguiente diagrama se muestra una VPC de acceso a servicios que aloja subredes de acceso a servicios privados conectadas a la VPC de tránsito con una VPN de alta disponibilidad. El diagrama también muestra las VPCs de aplicaciones, las VPCs de tránsito y las VPCs de acceso a servicios que alojan los puntos finales de consumidor de Private Service Connect conectados mediante Network Connectivity Center:

Estructura general de Red multinube con radios de VPC de Network Connectivity Center

La estructura que se muestra en el diagrama anterior contiene estos componentes:

  • Red externa: un centro de datos o una oficina remota en la que tienes equipos de red. En este ejemplo se da por supuesto que las ubicaciones están conectadas entre sí mediante una red externa.
  • Red de VPC de tránsito: una red de VPC en el proyecto de hub que recibe conexiones de entornos on-premise y otros proveedores de servicios en la nube (CSPs) y, a continuación, actúa como ruta de tránsito de otras VPCs a redes on-premise y de CSPs.
  • VPCs de aplicaciones: proyectos y redes de VPC que alojan varias aplicaciones.
  • VPC de consumidor para el acceso a servicios privados: una red de VPC que aloja el acceso centralizado a través del acceso a servicios privados a los servicios que necesitan las aplicaciones de otras redes.
  • VPC de servicios gestionados: servicios proporcionados y gestionados por otras entidades, pero a los que pueden acceder las aplicaciones que se ejecutan en redes de VPC.
  • VPC de consumidor de Private Service Connect: una red de VPC que aloja puntos de acceso de Private Service Connect a servicios alojados en otras redes.

Usa Network Connectivity Center para conectar las VPCs de la aplicación a las vinculaciones de VLAN de Cloud Interconnect y a las instancias de VPN de alta disponibilidad de las VPCs de tránsito. Convierte todas las VPCs en radios del hub de Network Connectivity Center y las vinculaciones de VLAN y las VPNs de alta disponibilidad en radios híbridos del mismo hub de Network Connectivity Center. Usa la topología de malla predeterminada de Network Connectivity Center para habilitar la comunicación entre todos los radios (VPC e híbridos). Esta topología también permite la comunicación entre las VPCs de las aplicaciones que están sujetas a las políticas de Cloud NGFW. Las VPCs de servicios de consumo conectadas a través de una VPN de alta disponibilidad no deben ser radios del centro de conectividad de red. Los puntos finales de Private Service Connect se pueden implementar en radios de VPC de Network Connectivity Center y no requieren una conexión VPN de alta disponibilidad para la transitividad entre VPCs cuando se usa Network Connectivity Center.

Conectividad entre VPCs con el emparejamiento entre redes de VPC

Cuando los puntos de acceso de los consumidores de servicios publicados se implementan en una VPC de acceso a servicios, recomendamos que las VPCs de aplicaciones se conecten a la VPC de tránsito mediante el emparejamiento entre redes de VPC y que las VPCs de acceso a servicios se conecten a la VPC de tránsito a través de una VPN de alta disponibilidad.

En este diseño, la VPC de tránsito es el centro y los puntos de acceso de los consumidores para los endpoints de servicio privados se implementan en una VPC de acceso a los servicios.

El diseño es una combinación de dos tipos de conectividad:

  • Emparejamiento entre redes de VPC: proporciona conectividad entre la VPC de tránsito y las VPCs de aplicaciones.
  • Conexiones entre VPCs de VPN de alta disponibilidad: proporcionan conectividad transitiva entre las VPCs de acceso a servicios y la VPC de tránsito.

Cuando combines estas arquitecturas, ten en cuenta lo siguiente:

  • Redistribución de subredes de VPC de emparejamiento en el enrutamiento dinámico (a la VPC de acceso a servicios a través de la VPN de alta disponibilidad y a redes externas a través de conexiones híbridas)
  • Consideraciones sobre el enrutamiento multirregional
  • Propagación de rutas dinámicas al emparejamiento entre VPCs (desde la VPC de acceso a servicios a través de la VPN de alta disponibilidad y desde redes externas a través de conexiones híbridas)

En el siguiente diagrama se muestra una VPC de acceso a servicios, que está conectada a la VPC de tránsito con una VPN de alta disponibilidad, y las VPCs de aplicaciones, que están conectadas a la VPC de tránsito con el emparejamiento entre redes de VPC:

VPC de servicios centrales conectada a la VPC de tránsito con una VPN de alta disponibilidad y las VPCs de aplicaciones conectadas a la VPC de tránsito con el emparejamiento entre redes de VPC

La estructura que se muestra en el diagrama anterior contiene estos componentes:

  • Ubicación del cliente: un centro de datos o una oficina remota donde tengas equipos de red. En este ejemplo se da por supuesto que las ubicaciones están conectadas entre sí mediante una red externa.
  • Área metropolitana: área metropolitana que contiene uno o varios dominios de disponibilidad de borde de Cloud Interconnect. Cloud Interconnect se conecta a otras redes de estas áreas metropolitanas.
  • Proyecto de hub: proyecto que aloja al menos una red de VPC que actúa como hub para otras redes de VPC.
  • VPC de tránsito: una red de VPC en el proyecto de centro de conectividad que recibe conexiones de entornos on-premise y otros proveedores de servicios en la nube (CSP) y, a continuación, actúa como ruta de tránsito desde otras VPCs a redes on-premise y de CSP.
  • Proyectos host de aplicaciones y VPCs: proyectos y redes de VPC que alojan varias aplicaciones.
  • VPC de acceso a servicios: una red de VPC que aloja el acceso centralizado a los servicios que necesitan las aplicaciones de las redes de VPC de aplicaciones.
  • VPC de servicios gestionados: servicios proporcionados y gestionados por otras entidades, pero a los que pueden acceder las aplicaciones que se ejecutan en redes de VPC.

En el diseño de emparejamiento entre redes de VPC, cuando las VPCs de las aplicaciones necesiten comunicarse entre sí, puedes conectar las VPCs de las aplicaciones a un hub de Network Connectivity Center como radios de VPC. Este enfoque proporciona conectividad entre todas las VPCs del hub de Network Connectivity Center. Se pueden crear subgrupos de comunicación usando varios hubs de Network Connectivity Center. Las restricciones de comunicación necesarias entre los endpoints de un centro concreto se pueden conseguir mediante políticas de firewall.

Para proteger las cargas de trabajo de las conexiones este-oeste entre VPCs de aplicaciones, se puede usar Cloud Next Generation Firewall.

Para obtener instrucciones detalladas y planos de configuración para implementar estos tipos de conectividad, consulta el artículo Arquitectura de red de concentrador y radios.

Diseño de infraestructura de DNS

En un entorno híbrido, Cloud DNS o un proveedor externo (on-premise o CSP) pueden gestionar una búsqueda de DNS. Los servidores DNS externos son acreditados para las zonas DNS externas, y Cloud DNS es acreditado para las zonasGoogle Cloud . El reenvío de DNS debe habilitarse de forma bidireccional entreGoogle Cloud y las redes externas, y los cortafuegos deben configurarse para permitir el tráfico de resolución de DNS.

Si usas una VPC compartida para tu VPC de acceso a servicios, en la que los administradores de diferentes proyectos de servicio de aplicaciones pueden crear instancias de sus propios servicios, utiliza el enlace entre proyectos de zonas DNS. La vinculación entre proyectos permite segmentar y delegar el espacio de nombres de DNS en los administradores del proyecto de servicio.

En el caso del tránsito, cuando las redes externas se comunican con otras redes externas a través de Google Cloud, las zonas DNS externas deben configurarse para reenviar solicitudes directamente entre sí. La red entre nubes de Google proporcionaría conectividad para que se completaran las solicitudes y respuestas de DNS, pero Google Cloud DNS participa en el reenvío del tráfico de resolución de DNS entre zonas de redes externas. Las reglas de cortafuegos aplicadas en la red entre nubes deben permitir el tráfico de resolución de DNS entre las redes externas.

En el siguiente diagrama se muestra cómo se puede usar un diseño de DNS con cualquiera de las configuraciones de conectividad de VPC de tipo concentrador-rama propuestas en esta guía de diseño:

Diseño de DNS que se puede usar con patrones de conectividad de concentrador y radios

En el diagrama anterior se muestran los siguientes pasos del flujo de diseño:

  1. DNS local
    Configura tus servidores DNS locales para que sean acreditados en las zonas DNS locales. Para configurar el reenvío de DNS (para los nombres de Cloud DNS de Google), debes dirigirte a la dirección IP de reenvío entrante de Cloud DNS, que se crea mediante la configuración de la política de servidor entrante en la VPC de concentrador. Esta configuración permite que la red local resuelva los nombres de Cloud DNS de Google.
  2. VPC de tránsito: proxy de salida de DNS
    Anuncia el intervalo del proxy de salida de DNS de Google 35.199.192.0/19 a la red on‐premise mediante los Cloud Routers. Las solicitudes DNS salientes de Google a entornos on-premise proceden de este intervalo de direcciones IP.
  3. VPC de tránsito - Cloud DNS
    1. Configura una política de servidor entrante para las solicitudes DNS entrantes procedentes de entornos on-premise.
    2. Configura una zona de reenvío de Cloud DNS (para nombres DNS locales) que apunte a servidores DNS locales.
  4. VPC de acceso a servicios - Cloud DNS
    1. Configura la zona de emparejamiento de DNS de los servicios (para nombres de DNS locales) y define la VPC del hub como red de peer. La resolución de DNS de los recursos on-premise y de servicio se realiza a través de la VPC de concentrador.
    2. Configura las zonas privadas de DNS de los servicios en el proyecto host de los servicios y adjunta la VPC compartida de los servicios, la VPC compartida de la aplicación y la VPC de concentrador a la zona. De esta forma, todos los hosts (tanto locales como de todos los proyectos de servicio) pueden resolver los nombres DNS de los servicios.
  5. Proyecto de host de la aplicación: Cloud DNS
    1. Configura una zona de peering de DNS de aplicaciones para los nombres de DNS on-premise. Para ello, define la VPC de concentrador como red peer. La resolución de DNS de los hosts locales se realiza a través de la VPC de concentrador.
    2. Configura zonas privadas de DNS de aplicaciones en el proyecto host de aplicaciones y asocia la VPC de la aplicación, la VPC compartida de los servicios y la VPC de concentrador a la zona. Esta configuración permite que todos los hosts (tanto los locales como los de todos los proyectos de servicio) resuelvan los nombres de DNS de la aplicación.

Para obtener más información, consulta Arquitectura híbrida con una red de VPC de concentrador conectada a redes de VPC de radio.

Siguientes pasos

Colaboradores

Autores:

Otros colaboradores: