La creación de redes es necesaria para que los recursos se comuniquen dentro de tu organización Google Cloud y entre tu entorno de nube y tu entorno local. En esta sección se describe la estructura del plano técnico de las redes de VPC, el espacio de direcciones IP, el DNS, las políticas de cortafuegos y la conectividad con el entorno local.
Topología de red
El repositorio de planos ofrece las siguientes opciones para tu topología de red:
- Usa redes de VPC compartidas independientes para cada entorno, sin permitir el tráfico de red directamente entre entornos.
- Usa un modelo de eje y radio que añada una red de concentrador para conectar cada entorno en Google Cloud, con el tráfico de red entre entornos controlado por un dispositivo virtual de red (NVA).
Elige la red de VPC compartida para cada topología de entorno cuando no quieras que haya conectividad de red directa entre los entornos. Elige la topología de red de concentrador y radios cuando quieras permitir la conectividad de red entre entornos que esté filtrada por una NVA, por ejemplo, cuando utilices herramientas que requieran una ruta de red directa a cada servidor de tu entorno.
Ambas topologías usan la VPC compartida como estructura de red principal, ya que permite separar claramente las responsabilidades. Los administradores de red gestionan los recursos de red en un proyecto de host centralizado, mientras que los equipos de cargas de trabajo despliegan sus propios recursos de aplicación y consumen los recursos de red en proyectos de servicio vinculados al proyecto de host.
Red de VPC compartida para cada topología de entorno
Si necesitas aislar la red entre tus redes de desarrollo, no productivas y productivas en Google Cloud, te recomendamos que uses la red de VPC compartida para cada topología de entorno. Esta topología no permite el tráfico de red entre entornos.
En el siguiente diagrama se muestra la red VPC compartida de cada topología de entorno.
En el diagrama se describen los siguientes conceptos clave de la VPC compartida para cada topología de entorno:
- Cada entorno (producción, no producción y desarrollo) tiene una red de VPC compartida. En este diagrama solo se muestra el entorno de producción, pero el mismo patrón se repite en cada entorno.
- Cada red VPC compartida tiene dos subredes, y cada subred está en una región diferente.
- La conectividad con los recursos on-premise se habilita mediante cuatro vinculaciones de VLAN a la instancia de Interconnect dedicada de cada red de VPC compartida, con cuatro servicios de Cloud Router (dos en cada región para la redundancia). Para obtener más información, consulta el artículo sobre la conectividad híbrida entre un entorno local y Google Cloud.
Por diseño, esta topología no permite que el tráfico de red fluya directamente entre entornos. Si necesitas que el tráfico de red fluya directamente entre entornos, debes seguir pasos adicionales para permitir esta ruta de red. Por ejemplo, puedes configurar puntos finales de Private Service Connect para exponer un servicio de una red de VPC a otra. También puedes configurar tu red local para que el tráfico fluya de unGoogle Cloud entorno al entorno local y, después, a otro Google Cloud entorno.
Topología de red de tipo concentrador y radios
Si despliega recursos en Google Cloud que requieren una ruta de red directa a recursos en varios entornos, le recomendamos la topología de red de concentrador y radios.
La topología de concentrador y radios usa varios de los conceptos que forman parte de la red de VPC compartida para cada topología de entorno, pero modifica la topología para añadir una red de concentrador. En el siguiente diagrama se muestra la topología de concentrador y radios.
En el diagrama se describen estos conceptos clave de la topología de red de concentrador y radios:
- Este modelo añade una red de concentrador, y cada una de las redes de desarrollo, no de producción y de producción (radios) se conecta a la red de concentrador mediante el emparejamiento entre redes de VPC. Si prevés superar el límite de la cuota, puedes usar una pasarela de VPN de alta disponibilidad.
- La conectividad con las redes on-premise solo se permite a través de la red de concentrador. Todas las redes de radio pueden comunicarse con los recursos compartidos de la red de concentrador y usar esta ruta para conectarse a redes on‐premise.
- Las redes de concentrador incluyen una NVA para cada región, implementada de forma redundante detrás de instancias de balanceador de carga de red interno. Esta NVA actúa como pasarela para permitir o denegar el tráfico entre redes de radio.
- La red del centro de control también aloja herramientas que requieren conectividad con todas las demás redes. Por ejemplo, puedes desplegar herramientas en instancias de VM para gestionar la configuración del entorno común.
Para habilitar el tráfico entre radios, el blueprint implementa NVAs en la red de VPC compartida del hub, que actúan como pasarelas entre redes. Las rutas se intercambian de las redes de VPC de concentrador a las de radio mediante el intercambio de rutas personalizadas. En este caso, la conectividad entre los radios debe enrutarse a través de la NVA, ya que el emparejamiento entre redes de VPC no es transitivo y, por lo tanto, las redes de VPC de los radios no pueden intercambiar datos entre sí directamente. Debes configurar los dispositivos virtuales para permitir selectivamente el tráfico entre radios.
Patrones de implementación de proyectos
Cuando crees proyectos para cargas de trabajo, debes decidir cómo se conectarán los recursos de este proyecto a tu red. En la siguiente tabla se describen los patrones para implementar proyectos que se utilizan en el plano.
| Patrón | Descripción | Ejemplo de uso |
|---|---|---|
| Proyectos de servicio de VPC compartida | Estos proyectos se configuran como proyectos de servicio de un proyecto host de VPC compartida. Usa este patrón cuando los recursos de tu proyecto cumplan los siguientes criterios:
|
example_shared_vpc_project.tf |
| Proyectos flotantes | Los proyectos flotantes no están conectados a otras redes de VPC de tu topología. Usa este patrón cuando los recursos de tu proyecto cumplan los siguientes criterios:
Puede que te encuentres en una situación en la que quieras mantener la red de VPC de un proyecto flotante separada de la topología de la red de VPC principal, pero también quieras exponer un número limitado de endpoints entre las redes. En este caso, publica servicios mediante Private Service Connect para compartir el acceso a la red de un punto final concreto entre redes de VPC sin exponer toda la red. |
example_floating_project.tf |
| Proyectos de emparejamiento | Los proyectos de emparejamiento crean sus propias redes de VPC y se emparejan con otras redes de VPC de tu topología. Usa este patrón cuando los recursos de tu proyecto cumplan los siguientes criterios:
Si creas proyectos de emparejamiento, es tu responsabilidad asignar intervalos de direcciones IP que no entren en conflicto y planificar la cuota de grupos de emparejamiento. |
example_peering_project.tf |
Asignación de direcciones IP
En esta sección se explica cómo asigna la arquitectura del plano técnico los intervalos de direcciones IP. Es posible que tengas que cambiar los intervalos de direcciones IP específicos que se usan en función de la disponibilidad de direcciones IP en tu entorno híbrido.
En la siguiente tabla se desglosa el espacio de direcciones IP asignado al plan. El entorno de concentrador solo se aplica en la topología de concentrador y radios.
| Finalidad | Región | Entorno del centro de control | Entorno de desarrollo | Entorno de no producción | Entorno de producción |
|---|---|---|---|---|---|
| Intervalos de subredes principales | Región 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 |
| Región 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | |
| Sin asignar | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | |
| Acceso a servicios privados | Global | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 |
| Endpoints de Private Service Connect | Global | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 |
| Subredes de solo proxy | Región 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 |
| Región 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | |
| Sin asignar | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | |
| Intervalos de subredes secundarias | Región 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 |
| Región 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | |
| Sin asignar | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
En la tabla anterior se muestran estos conceptos para asignar intervalos de direcciones IP:
- La asignación de direcciones IP se divide en intervalos para cada combinación de finalidad, región y entorno.
- Algunos recursos son globales y no requieren subdivisiones para cada región.
- De forma predeterminada, en el caso de los recursos regionales, el blueprint se despliega en dos regiones. Además, hay intervalos de direcciones IP sin usar para que puedas ampliar tu cobertura a seis regiones más.
- La red de concentrador solo se usa en la topología de red de concentrador y radios, mientras que los entornos de desarrollo, no de producción y de producción se usan en ambas topologías de red.
En la siguiente tabla se explica cómo se usa cada tipo de intervalo de direcciones IP.
| Finalidad | Descripción |
|---|---|
| Intervalos de subredes principales | Los recursos que implementes en tu red de VPC, como las instancias de máquina virtual, usan direcciones IP internas de estos intervalos. |
| Acceso a servicios privados | Algunos Google Cloud servicios, como Cloud SQL, requieren que preasignes un intervalo de subred para el acceso privado a servicios. El blueprint reserva un intervalo /21 de forma global para cada una de las redes de VPC compartida para asignar direcciones IP a los servicios que requieren acceso a servicios privados. Cuando creas un servicio que depende del acceso a servicios privados, asignas una subred regional /24 del intervalo /21 reservado. |
| Private Service Connect | El blueprint aprovisiona cada red de VPC con un endpoint de Private Service Connect para comunicarse con las APIs de Google Cloud. Este endpoint permite que tus recursos de la red de VPC accedan a las APIs de Google Cloud sin depender del tráfico saliente a Internet ni de los intervalos de Internet anunciados públicamente. |
| Balanceadores de carga basados en proxies | Algunos tipos de balanceadores de carga de aplicaciones requieren que preasignes subredes de solo proxy. Aunque el blueprint no implementa balanceadores de carga de aplicaciones que requieran este intervalo, asignar intervalos con antelación ayuda a reducir los problemas de las cargas de trabajo cuando necesiten solicitar un nuevo intervalo de subred para habilitar determinados recursos del balanceador de carga. |
| Intervalos de subredes secundarias | Algunos casos prácticos, como las cargas de trabajo basadas en contenedores, requieren rangos secundarios. Aunque el plano no implementa servicios que requieran intervalos secundarios, asigna intervalos del espacio de direcciones IP RFC 6598 a los intervalos secundarios. Si tienes problemas para asignar bloques CIDR lo suficientemente grandes para estos servicios, puedes plantearte implementar esos servicios con el patrón de proyecto flotante que se describe en la sección Patrones de implementación de proyectos. |
Configuración de DNS centralizada
Para la resolución de DNS entre entornos Google Cloud y locales, te recomendamos que uses un enfoque híbrido con dos sistemas de DNS autoritativos. Con este enfoque, Cloud DNS gestiona la resolución de DNS autoritativa de tu entornoGoogle Cloud y tus servidores DNS on-premise gestionan la resolución de DNS autoritativa de los recursos on-premise. Tu entorno local y el entorno de Google Cloud realizan búsquedas de DNS entre entornos mediante solicitudes de reenvío.
En el siguiente diagrama se muestra la topología de DNS de las varias redes VPC que se usan en el plano.
En el diagrama se describen los siguientes componentes del diseño de DNS que se implementa en el blueprint:
- El centro de DNS es el punto central del intercambio de DNS entre el entorno local y el entorno de Google Cloud. El reenvío de DNS usa las mismas instancias de Interconnect dedicado y los mismos routers de Cloud Router que ya están configurados en tu topología de red.
- En la red de VPC compartida de cada topología de entorno, el proyecto de DNS es el mismo que el proyecto host de VPC compartida de producción.
- En la topología de concentrador y radios, el proyecto de concentrador de DNS es el mismo que el proyecto de host de VPC compartida del concentrador.
- Los servidores de cada red de VPC compartida pueden resolver registros DNS de otras redes de VPC compartida mediante el reenvío de DNS, que se configura entre Cloud DNS en cada proyecto del host de VPC compartida y el hub de DNS.
- Los servidores locales pueden resolver registros DNS en entornos Google Cloud mediante políticas de servidor DNS que permitan consultas de servidores locales. El plano configura una política de servidor entrante en el centro de DNS para asignar direcciones IP, y los servidores DNS locales reenvían las solicitudes a estas direcciones. Todas las solicitudes de DNS llegan primero al centro de DNS, que resuelve registros de los peers de DNS. Google Cloud
- Los servidores de Google Cloud pueden resolver registros DNS en el entorno local mediante zonas de reenvío que consultan servidores locales. Todas las solicitudes de DNS al entorno on-premise proceden del centro de DNS. El origen de la solicitud de DNS es 35.199.192.0/19.
Políticas de cortafuegos
Google Cloud tiene varios tipos de políticas de cortafuegos. Las políticas de cortafuegos jerárquicas se aplican a nivel de organización o carpeta para heredar las reglas de la política de cortafuegos de forma coherente en todos los recursos de la jerarquía. Además, puedes configurar políticas de cortafuegos de red para cada red de VPC. El plano combina estas políticas de cortafuegos para aplicar configuraciones comunes en todos los entornos mediante políticas de cortafuegos jerárquicas y para aplicar configuraciones más específicas en cada red de VPC mediante políticas de cortafuegos de red.
El plano no usa reglas de cortafuegos de VPC antiguas. Te recomendamos que solo uses políticas de cortafuegos y que no las combines con reglas de cortafuegos de VPC antiguas.
Políticas de cortafuegos jerárquicas
El plano define una sola política de cortafuegos jerárquica y la asocia a cada una de las carpetas de producción, no producción, desarrollo, bootstrap y comunes. Esta política de cortafuegos jerárquica contiene las reglas que se deben aplicar de forma general en todos los entornos y delega la evaluación de reglas más específicas en la política de cortafuegos de red de cada entorno.
En la siguiente tabla se describen las reglas de la política de cortafuegos jerárquica implementadas por el blueprint.
| Descripción de la regla | Dirección del tráfico | Filtro (intervalo de IPv4) | Protocolos y puertos | Acción |
|---|---|---|---|---|
| Delega la evaluación del tráfico entrante de RFC 1918 a niveles inferiores de la jerarquía. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| Delega la evaluación del tráfico saliente a RFC 1918 en niveles inferiores de la jerarquía. | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| IAP para el reenvío de TCP | Ingress |
35.235.240.0/20 |
tcp:22,3389 |
Allow |
| Activación de Windows Server | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Comprobaciones del estado de Cloud Load Balancing | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
Políticas de cortafuegos de red
El plano configura una política de cortafuegos de red para cada red. Cada política de cortafuegos de red empieza con un conjunto mínimo de reglas que permiten el acceso a los servicios de Google Cloud y deniegan el tráfico saliente a todas las demás direcciones IP.
En el modelo de eje y radio, las políticas de cortafuegos de red contienen reglas adicionales para permitir la comunicación entre los radios. La política de cortafuegos de red permite el tráfico saliente de una red de radio a la red de concentrador o a otra red de radio, así como el tráfico entrante de la NVA en la red de concentrador.
En la siguiente tabla se describen las reglas de la política de cortafuegos de red global implementada en cada red de VPC del blueprint.
| Descripción de la regla | Dirección del tráfico | Filtro | Protocolos y puertos |
|---|---|---|---|
| Permite el tráfico saliente a las APIs de Google Cloud. | Egress |
El endpoint de Private Service Connect que se configura para cada red. Consulta Acceso privado a las APIs de Google. | tcp:443 |
| Deniega el tráfico saliente que no coincida con otras reglas. | Egress |
todos | all |
Permite el tráfico de salida de un spoke a otro (solo para el modelo de concentrador y radios). | Egress | La agregación de todas las direcciones IP utilizadas en la topología de concentrador y radios. El tráfico que sale de una VPC de spoke se enruta primero a la NVA de la red de concentrador. | all |
Permitir el tráfico entrante a un radio desde la NVA de la red de concentrador (solo para el modelo de concentrador y radio). |
Ingress |
Tráfico procedente de las NVAs de la red de concentrador. | all |
Cuando implementas el blueprint por primera vez, una instancia de VM de una red de VPC puede comunicarse con los servicios, pero no con otros recursos de infraestructura de la misma red de VPC. Google Cloud Para permitir que las instancias de VM se comuniquen, debes añadir reglas adicionales a tu política de cortafuegos de red y etiquetas que permitan explícitamente que las instancias de VM se comuniquen. Las etiquetas se añaden a las instancias de VM y el tráfico se evalúa en función de esas etiquetas. Las etiquetas también tienen controles de gestión de identidades y accesos (IAM) para que puedas definirlas de forma centralizada y delegar su uso en otros equipos.
En el siguiente diagrama se muestra un ejemplo de cómo puedes añadir etiquetas personalizadas y reglas de política de cortafuegos de red para permitir que las cargas de trabajo se comuniquen dentro de una red de VPC.
En el diagrama se muestran los siguientes conceptos de este ejemplo:
- La política de cortafuegos de red contiene la regla 1, que deniega el tráfico de salida de todas las fuentes con la prioridad 65530.
- La política de cortafuegos de red contiene la regla 2, que permite el tráfico entrante de instancias con la etiqueta
service=frontenda instancias con la etiquetaservice=backendcon la prioridad 999. - La VM instance-2 puede recibir tráfico de instance-1 porque el tráfico coincide con las etiquetas permitidas por la regla 2. La regla 2 se corresponde antes de que se evalúe la regla 1, según el valor de prioridad.
- La VM instance-3 no recibe tráfico. La única regla de política de cortafuegos que coincide con este tráfico es la regla 1, por lo que se deniega el tráfico saliente de instance-1.
Acceso privado a las APIs de Google Cloud
Para que los recursos de tus redes de VPC o de tu entorno local puedan acceder a los servicios deGoogle Cloud , te recomendamos que utilices la conectividad privada en lugar del tráfico de Internet saliente a los endpoints de las APIs públicas. El plano configura Acceso privado de Google en cada subred, crea endpoints internos con Private Service Connect para comunicarse con los servicios de Google Cloud y configura políticas de firewall y registros DNS para permitir el tráfico a esos endpoints. Si se usan conjuntamente, estos controles permiten acceder a los servicios a través de una ruta privada sin depender del tráfico saliente de Internet ni de los intervalos de Internet anunciados públicamente. Google Cloud
El blueprint configura los endpoints de Private Service Connect con el paquete de APIs
llamado vpc-sc, que permite acceder a los Google Cloud servicios
compatibles con la IP virtual restringida. Este control ayuda a reducir el riesgo de exfiltración, ya que impide el acceso a otras APIs de Google que no estén relacionadas con Google Cloud. Este control también es un paso obligatorio para habilitar los controles de servicio de VPC. Para obtener más información sobre los pasos opcionales para habilitar Controles de Servicio de VPC, consulta el artículo Proteger recursos con Controles de Servicio de VPC.
En la siguiente tabla se describen los endpoints de Private Service Connect creados para cada red.
| Entorno | Paquete de APIs | Dirección IP del endpoint de Private Service Connect | ||
|---|---|---|---|---|
| Común | vpc-sc |
10.17.0.5/32 | ||
| Desarrollo | vpc-sc |
10.17.0.6/32 | ||
| Fuera de producción | vpc-sc |
10.17.0.7/32 | ||
| Producción | vpc-sc |
10.17.0.8/32 | ||
Para asegurarse de que el tráfico de los Google Cloud servicios tenga una búsqueda de DNS al endpoint correcto, el blueprint configura zonas de DNS privadas para cada red VPC. En la siguiente tabla se describen estas zonas de DNS privadas.
| Nombre de la zona privada | Nombre de DNS | Tipo de registro | Datos |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
restricted.googleapis.com. |
restricted.googleapis.com |
A |
Dirección IP del endpoint de Private Service Connect de esa red de VPC. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
Dirección IP del endpoint de Private Service Connect de esa red de VPC. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
Dirección IP del endpoint de Private Service Connect de esa red de VPC. |
El plano tiene configuraciones adicionales para asegurar que estos puntos finales de Private Service Connect se usen de forma coherente. Cada red de VPC compartida también aplica lo siguiente:
- Una regla de política de cortafuegos de red que permite el tráfico saliente de todos los orígenes a la dirección IP del endpoint de Private Service Connect en TCP:443.
- Una regla de política de cortafuegos de red que deniega el tráfico saliente a 0.0.0.0/0, lo que incluye los dominios predeterminados que se usan para acceder a los servicios de Google Cloud .
Conectividad a Internet
El plano no permite el tráfico entrante ni saliente entre sus redes de VPC y la red de Internet. En el caso de las cargas de trabajo que requieren conectividad a Internet, debes seguir pasos adicionales para diseñar las rutas de acceso necesarias.
En el caso de las cargas de trabajo que requieren tráfico saliente a Internet, te recomendamos que gestiones el tráfico saliente a través de Cloud NAT para permitir el tráfico saliente sin conexiones entrantes no solicitadas, o bien a través de Secure Web Proxy para tener un control más granular y permitir el tráfico saliente solo a servicios web de confianza.
En el caso de las cargas de trabajo que requieren tráfico entrante de Internet, te recomendamos que las diseñes con Cloud Load Balancing y Google Cloud Armor para beneficiarte de la protección frente a ataques DDoS y WAF.
No te recomendamos que diseñes cargas de trabajo que permitan la conectividad directa entre Internet y una VM mediante una dirección IP externa en la VM.
Conectividad híbrida entre un entorno local y Google Cloud
Para establecer la conectividad entre el entorno local yGoogle Cloud, te recomendamos que uses Interconnect dedicado para maximizar la seguridad y la fiabilidad. Una conexión de interconexión dedicada es un enlace directo entre tu red on-premise yGoogle Cloud.
En el siguiente diagrama se muestra la conectividad híbrida entre el entorno on-premise y una red de nube privada virtual de Google.
En el diagrama se describen los siguientes componentes del patrón de disponibilidad del 99,99% en la interconexión dedicada:
- Cuatro conexiones de interconexión dedicada, con dos conexiones en un área metropolitana y dos conexiones en otra. En cada área metropolitana, hay dos zonas distintas en la instalación de colocación.
- Las conexiones se dividen en dos pares, y cada par se conecta a un centro de datos local independiente.
- Las vinculaciones de VLAN se usan para conectar cada instancia de interconexión dedicada a los routers de Cloud Router que están vinculados a la topología de VPC compartida.
- Cada red VPC compartida tiene cuatro Cloud Routers, dos en cada región, con el modo de enrutamiento dinámico definido como
globalpara que cada Cloud Router pueda anunciar todas las subredes, independientemente de la región.
Con el enrutamiento dinámico global, Cloud Router anuncia rutas a todas las subredes de la red de VPC. Cloud Router anuncia rutas a subredes remotas (subredes que están fuera de la región de Cloud Router) con una prioridad inferior en comparación con las subredes locales (subredes que están en la región de Cloud Router). También puede cambiar los prefijos y las prioridades anunciados al configurar la sesión BGP de un router de Cloud Router.
El tráfico de Google Cloud a un entorno on-premise usa el Cloud Router más cercano a los recursos en la nube. En una misma región, varias rutas a redes locales tienen el mismo valor de discriminador de salida múltiple (MED) y Google Cloud usanrutas de acceso múltiple de igual coste (ECMP) para distribuir el tráfico saliente entre todas las rutas posibles.
Cambios en la configuración on-premise
Para configurar la conectividad entre el entorno local yGoogle Cloud, debe configurar cambios adicionales en su entorno local. El código de Terraform de la blueprint configura automáticamente los recursos, pero no modifica ninguno de los recursos de tu red local.Google Cloud
Algunos de los componentes de conectividad híbrida de tu entorno local aGoogle Cloud se habilitan automáticamente mediante el plano, incluidos los siguientes:
- Cloud DNS se configura con el reenvío de DNS entre todas las redes de VPC compartida a un solo centro, tal como se describe en la sección Configuración de DNS. Una política de servidor de Cloud DNS se configura con direcciones IP de reenviador entrantes.
- Cloud Router está configurado para exportar rutas de todas las subredes y rutas personalizadas de las direcciones IP que usan los endpoints de Private Service Connect.
Para habilitar la conectividad híbrida, debes seguir estos pasos adicionales:
- Solicita una conexión de interconexión dedicada.
- Configura los routers y cortafuegos on-premise para permitir el tráfico saliente al espacio de direcciones IP interno definido en Asignación de espacio de direcciones IP.
- Configura tus servidores DNS locales para que reenvíen las búsquedas de DNS destinadas aGoogle Cloud a las direcciones IP del reenviador de entrada que ya ha configurado el blueprint.
- Configura tus servidores DNS, cortafuegos y routers on-premise para que acepten consultas de DNS de la zona de reenvío de Cloud DNS (35.199.192.0/19).
- Configura los servidores DNS on-premise para que respondan a las consultas de los hosts on-premise a los Google Cloud servicios con las direcciones IP definidas en el acceso privado a las APIs de Cloud.
- Para cifrar los datos en tránsito a través de la conexión de Interconexión Dedicada, configura MACsec para Cloud Interconnect o VPN de alta disponibilidad mediante Cloud Interconnect para el cifrado IPsec.
Para obtener más información, consulta el artículo sobre el Acceso privado a Google para hosts locales.
Siguientes pasos
- Consulta información sobre los controles de detección (el siguiente documento de esta serie).