Patrones de redes híbridas de Google Cloud - Parte 2

Introducción

Las empresas no migrarán todas sus cargas de trabajo locales a la nube de una sola vez. Tiene más sentido migrar a la nube porciones de cargas de trabajo a la vez, allí donde se puedan cosechar los máximos beneficios de la migración a la nube. Por tanto, seguirá necesitando una forma de que sus sistemas locales se comuniquen con sus recursos en la nube recién desplegados.

Existen múltiples patrones de red que pueden aprovecharse para diseñar la conectividad híbrida en Google Cloud. El diseño de la conectividad híbrida depende de factores como:

• Número de redes VPC utilizadas para las cargas de trabajo
• Necesidad de inspección del tráfico de capa 7 mediante dispositivos virtuales de red (NVA)
• Acceso a los servicios gestionados por Google que utilizan el Acceso a Servicios Privados

Esta será una serie de blogs de varias partes en la que cubriré diferentes topologías de red disponibles en Google Cloud, que atienden a varios casos de uso de conectividad híbrida. Este primer blog se centrará en la conectividad híbrida a una VPC única o compartida en Google Cloud. En blogs posteriores, hablaré de la conectividad híbrida a múltiples redes VPC (o VPC compartidas) en Google Cloud y de la conectividad híbrida mediante dispositivos.

Cuando tenga un gran número de redes VPC de carga de trabajo, puede que necesite una arquitectura hub-and-spoke que soporte un gran número de redes VPC. Esto implica conectar varias redes de VPC de carga de trabajo a una VPC central de tránsito que tenga conectividad con entornos locales y otras nubes. Cubriré Hub-and-Spoke con VPC Peering a Spokes, Hub-and-Spoke con HA-VPN a Spokes, y conectividad híbrida usando appliances y VPC Peering a Spokes.

 

Conectividad híbrida a VPC única (o VPC compartida)

1. Interconexión con las instalaciones

a) Interconexión en la nube

Configure la interconexión dedicada o la interconexión de socios a la nube de Google. Conéctese a dos dominios de disponibilidad Edge (EAD) en el mismo Metro para alcanzar un SLA del 99,99%. Puede conectar sus Cloud Interconnects a varias regiones dentro de la misma VPC compartida.

2) Conexión VLAN

Una VLAN adjunta conecta su interconexión en un punto de presencia (PoP) de Google a un router de nube en una región especificada de Google Cloud.

3) Enrutador en la nube

Un Cloud Router intercambia rutas dinámicas (BGP) entre sus redes VPC y los routers locales. Puede configurar el enrutamiento dinámico entre sus routers locales y un Cloud Router en una región determinada. Cada Cloud Router se implementa mediante dos tareas de software que proporcionan dos interfaces de alta disponibilidad. Configure el enrutamiento BGP a cada una de las interfaces del enrutador Cloud.

4) Enrutamiento dinámico global VPC

Configure el enrutamiento dinámico global en la VPC compartida para permitir el intercambio de rutas dinámicas entre todas las regiones.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

2. HA-VPN a locales

1. HA-VPN en la nube

La pasarela HA-VPN en la nube se utiliza para establecer túneles IPsec con la pasarela VPN local a través de Internet. HA-VPN ofrece un SLA del 99,99%. Puede tener varios túneles HA-VPN en diferentes regiones dentro de la VPC compartida.

2. Enrutadores en la nube

Configure el enrutamiento dinámico entre los routers locales y un Cloud Router en cada región. Cada Cloud Router se implementa mediante dos tareas de software que proporcionan dos interfaces de alta disponibilidad. Configure el enrutamiento BGP a cada una de las interfaces del enrutador Cloud.

3. Enrutamiento dinámico global VPC

Configure el enrutamiento dinámico global en la VPC compartida para permitir el intercambio de rutas dinámicas entre todas las regiones.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

3. DNS

Visión general

En un entorno híbrido, la resolución DNS puede realizarse en Google Cloud o en las instalaciones. Consideremos un caso de uso de DNS híbrido en el que los servidores DNS locales son autoritativos para las zonas DNS locales y Cloud DNS es autoritativo para las zonas de Google Cloud.

1) DNS local

Configure sus servidores DNS locales para que sean autoritativos para las zonas DNS locales. Configure el reenvío de DNS (para nombres DNS de Google Cloud) apuntando a la dirección IP de reenvío entrante de DNS de Cloud, que se crea a través de la política de servidor entrante en la VPC compartida Prod. Esto permite que la red local resuelva los nombres DNS de Google Cloud.

2) VPC compartida Prod - Proxy de salida DNS

Anuncie el intervalo de proxy de salida de DNS de Google 35.199.192.0/19 a la red local a través de los routers de la nube. Las solicitudes DNS salientes de Google Cloud a las instalaciones se originan en este intervalo de direcciones IP.

3) Proyecto Prod host - Cloud DNS

• Configure una política de servidor entrante para las solicitudes DNS entrantes desde las instalaciones.
• b. Configure una zona de reenvío Cloud DNS (para nombres DNS locales) dirigida a los resolvers DNS locales.

 

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

4. Private Service Connect (PSC) para las API de Google (acceso a todas las API y servicios compatibles)

Visión general

Puedes utilizar Private Service Connect (PSC) para acceder a todos los servicios y API de Google compatibles desde hosts de Google Compute Engine (GCE) y hosts locales mediante la dirección IP interna de un punto final de PSC en una VPC compartida. Consideremos el acceso de PSC a un servicio en el Proyecto de Servicio 4 a través de la VPC Compartida.

Crear un punto final PSC

1.  Elige una dirección de punto final de PSC (por ejemplo, 10.2.2.2) y crea un punto final de PSC en la VPC compartida de Prod con un objetivo de "all-apis", que da acceso a todas las API y servicios de Google compatibles. Service Directory crea automáticamente un registro DNS (con el nombre DNS de p.googleapis.com) vinculado a la dirección IP del punto final del PSC.

2) Acceso a la API desde hosts de la CME

Los hosts de la CME pueden acceder a todos los servicios y API de Google compatibles a través del punto final de PSC en la VPC compartida de Prod.

2. Habilita Private Google Access en todas las subredes con instancias de cálculo que requieran acceso a las API de Google a través de PSC.

3. 3. Si tus clientes GCE pueden utilizar nombres DNS personalizados (por ejemplo, storage-xyz.p.googleapis.com), puedes utilizar el nombre DNS p.googleapis.com creado automáticamente.

6. Si sus clientes locales no pueden utilizar nombres DNS personalizados, puede crear registros A que asignen los nombres DNS predeterminados (por ejemplo, storage.googleapis.com) a la dirección del punto final de PSC.

 

Acceso desde hosts locales

Los hosts locales pueden acceder a todos los servicios y API de Google compatibles a través del punto final PSC de la VPC compartida Prod.

5. En el enrutador de la nube, anuncie la dirección del punto final de PSC a la red local.

6. 5. Si sus clientes locales pueden utilizar nombres DNS personalizados (por ejemplo, storage-xyz.p.googleapis.com), puede crear registros A que asignen los nombres DNS personalizados a la dirección del punto final de PSC.

7. 6. Si sus clientes locales no pueden utilizar nombres DNS personalizados, puede crear registros A que asignen los nombres DNS predeterminados (por ejemplo, storage.googleapis.com) a la dirección del punto final de PSC.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Private Service Connect (PSC) para API de Google (acceso a API y servicios compatibles con VPC Service Control)

Visión general

Puedes utilizar Private Service Connect (PSC) para acceder a todos los servicios y API de Google compatibles desde hosts de Google Compute Engine (GCE) y hosts locales mediante la dirección IP interna de un punto final de PSC en una VPC compartida. Consideremos el acceso de PSC a un servicio en el Proyecto de Servicio 4 a través de la VPC Compartida.

Crear un punto final PSC

1.Elige una dirección de punto final de PSC (por ejemplo, 10.2.2.2) y crea un punto final de PSC en la VPC compartida Prod con un objetivo de "vpc-sc", que da acceso a las API y los servicios de Google compatibles con VPC Service Control. Service Directory crea automáticamente un registro DNS (con el nombre DNS de p.googleapis.com) vinculado a la dirección IP del punto final del PSC.

 

2) Acceso a la API desde hosts de la CME

Los hosts GCE pueden acceder a las API y a los servicios de Google compatibles con VPC Service Control a través del punto final PSC de la VPC compartida Prod.

2. 2. Habilita Private Google Access en todas las subredes con instancias de cálculo que requieran acceso a las API de Google a través de PSC.

3. Si tus clientes GCE pueden utilizar nombres DNS personalizados (por ejemplo, storage-xyz.p.googleapis.com), puedes utilizar el nombre DNS p.googleapis.com creado automáticamente.

4. 4. Si tus clientes de la CME no pueden utilizar nombres DNS personalizados, puedes crear registros DNS de nube utilizando los nombres DNS predeterminados (por ejemplo, storage.googleapis.com).

Acceso desde hosts locales

Los hosts locales pueden acceder a todos los servicios y API seguros de Google a través del punto final de PSC en la VPC compartida de Prod.

5. En el enrutador de la nube, anuncie la dirección del punto final de PSC a la red local.

6. 5. Si sus clientes locales pueden utilizar nombres DNS personalizados (por ejemplo, storage-xyz.p.googleapis.com), puede crear registros A que asignen los nombres DNS personalizados a la dirección del punto final de PSC.

7. 6. Si sus clientes locales no pueden utilizar nombres DNS personalizados, puede crear registros A que asignen los nombres DNS predeterminados (por ejemplo, storage.googleapis.com) a la dirección del punto final de PSC.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

6. Control de servicios VPC

Visión general

VPC Service Control utiliza reglas de entrada y salida para controlar el acceso a y desde un perímetro. Las reglas especifican la dirección del acceso permitido hacia y desde diferentes identidades y recursos.

Consideremos un caso de uso específico en el que se requiere acceso a un servicio protegido en el Proyecto de Servicio 4 a través de la VPC compartida Prod. A continuación se describen las acciones de VPC Service Control para este escenario.

1. Perímetro - proyecto de servicio

El perímetro contiene un proyecto de servicio (Proyecto de servicio 4) e incluye las API de Google y los servicios que deben protegerse en el proyecto de servicio.

2. 2) Acceso a la API desde hosts de la CME

Una instancia GCE puede acceder a APIs seguras a través de un endpoint PSC en la VPC compartida. Considerando el perímetro alrededor del Proyecto de Servicio 4, la interfaz de red de la instancia de computación GCE-4 está en la VPC compartida Prod del proyecto anfitrión Prod. Las llamadas a la API desde la instancia CME-4 a un servicio (por ejemplo, storage.googleapis.com) en el proyecto de servicio 4 parecen originarse en el proyecto host Prod, donde se encuentran la interfaz de la instancia y el punto final PSC.

3.3) Regla de entrada - Proyecto de host Prod en el perímetro

Configure una regla de entrada que permita las llamadas a la API de Google desde el proyecto host Prod a los servicios protegidos dentro del perímetro del Proyecto de servicio 4. Esta regla permite llamadas API desde las instancias de la CME (por ejemplo, CME-4) al perímetro.

Aquí tienes una configuración detallada:

1. Política de cortafuegos perimetral de acceso:

• Vaya al proyecto de servicio 4 en Google Cloud Console.
• Vaya a Red VPC > Políticas de cortafuegos.
• Haga clic en la política de cortafuegos predeterminada.

2. Crear una nueva regla de entrada:

• Haga clic en el botón Añadir regla.
• Establezca la acción en Permitir.
• Seleccione TCP como Protocolo.
• Para la Fuente, elija el rango IP.
• Introduzca el rango IP de sus instancias GCE en Proyecto Host. Puede encontrar esta información en los detalles de la instancia de la CME. Por ejemplo, si el rango IP es 10.0.0.0/8, introdúzcalo aquí.
• Para el Destino, seleccione Rango IP e introduzca el rango IP de los servicios protegidos en el Proyecto de Servicio 4. Puede tratarse del rango IP interno de su red VPC o de direcciones IP específicas de los servicios.
• En la sección Destino, seleccione Todos.
• Para la Prioridad, elija un valor adecuado (por ejemplo, 1000).
• Haga clic en Añadir regla.

3. Verifique la regla:

• Una vez creada la regla, compruebe sus detalles para asegurarse de que está configurada correctamente.
• Pruebe la regla realizando una llamada API desde una instancia GCE en el Proyecto Host a un servicio protegido en el Proyecto Service 4.
• Consideraciones adicionales:
• Si tiene varias instancias de CME o desea permitir el tráfico de subredes específicas, ajuste el intervalo de IP de origen en consecuencia.
• Para un control más granular, considere el uso de etiquetas de origen o reglas de cortafuegos basadas en puertos o protocolos específicos.
• Si necesita permitir el tráfico de otros proyectos o direcciones IP externas, modifique la fuente en consecuencia.

4. Acceso desde hosts locales

4) Acceso a la API para hosts locales Los hosts locales pueden acceder a las API protegidas en el Proyecto de servicio 4 a través del punto final PSC en la VPC compartida Prod. Las llamadas API desde los locales a los servicios del Proyecto de Servicio 4 parecen originarse en el proyecto anfitrión Prod, donde se encuentran la Interconexión (o VPN) y el punto final PSC. La regla de entrada (mencionada en el paso 3) permite llamadas API desde las instalaciones al perímetro del Proyecto de Servicio 4 a través del proyecto de host Prod. El siguiente diagrama es un ejemplo.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

 

A medida que las empresas migran cargas de trabajo a la nube, deben comprender los distintos patrones de redes híbridas para garantizar una conectividad perfecta entre los entornos locales y en la nube. Este blog ha esbozado configuraciones clave que le ayudarán a lograr este objetivo. En futuras publicaciones, profundizaremos en los patrones avanzados para ayudarte a optimizar tu estrategia de nube híbrida en Google Cloud. Permanezca atento a la próxima entrega, en la que exploraremos la multi-VPC y las soluciones de conectividad basadas en dispositivos.