Las herramientas de redes son necesarias para que los recursos se comuniquen dentro de tu organización de Google Cloud y entre tu entorno de nube y el entorno local. En esta sección, se describe la estructura en el plano de las redes de VPC, el espacio de direcciones IP, el DNS, las políticas de firewall y la conectividad al entorno local.
Topología de la red
El repositorio de planos proporciona las siguientes opciones para la topología de red:
- Usa redes de VPC compartidas independientes para cada entorno, sin tráfico de red permitido directamente entre los entornos.
- Usa un modelo de concentrador y radio que agregue una red de concentrador para conectar cada entorno en Google Cloud, con el tráfico de red entre entornos controlados por un dispositivo virtual de red (NVA).
Elige la topología de red de VPC compartida doble cuando no quieras conectividad de red directa entre entornos. Elige la topología de red de concentrador y radio cuando desees permitir la conectividad de red entre entornos que se filtran por un NVA, como cuando usas las herramientas existentes que requieren una red directa. ruta a cada servidor de tu entorno.
Ambas topologías usan una VPC compartida como una construcción de red principal porque la VPC compartida permite una separación clara de las responsabilidades. Los administradores de red administran los recursos de red en un proyecto host centralizado y los equipos de carga de trabajo implementan sus propios recursos de aplicación y consumen los recursos de red en proyectos de servicio vinculados al proyecto host.
Ambas topologías incluyen una versión base y una restringida de cada red de VPC. La red de VPC base se usa para recursos que contienen datos no sensibles y la red de VPC restringida se usa para recursos con datos sensibles que requieren Controles del servicio de VPC. Para obtener más información sobre la implementación de los controles del servicio de VPC, consulta Protege tus recursos con los controles del servicio de VPC.
Topología de red de VPC compartida doble
Si necesitas aislamiento de red entre tus redes de desarrollo, no producción y producción en Google Cloud, te recomendamos la topología de red de VPC compartida doble. En esta topología, se usan redes de VPC compartidas independientes para cada entorno, cada uno con una división adicional entre una red de VPC compartida base y una red de VPC compartida restringida.
En el siguiente diagrama, se muestra la topología de red de VPC compartida doble.
En el diagrama, se describen estos conceptos clave de la topología de VPC compartida doble:
- Cada entorno (producción, no producción y desarrollo) tiene una red de VPC compartida para la red base y una red de VPC compartida para la red restringida. En este diagrama, solo se muestra el entorno de producción, pero el mismo patrón se repite para cada entorno.
- Cada red de VPC compartida tiene dos subredes, cada una de las cuales se encuentra en una región diferente.
- La conectividad con recursos locales se habilita a través de cuatro adjuntos de VLAN a la instancia de interconexión dedicada para cada red de VPC compartida, mediante cuatro servicios de Cloud Router (dos en cada región para redundancia). Para obtener más información, consulta Conectividad híbrida entre el entorno local y Google Cloud.
De forma predeterminada, 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 los entornos, debes tomar medidas adicionales para permitir esta ruta de red. Por ejemplo, puedes configurar extremos de Private Service Connect para exponer un servicio de una red de VPC a otra. Como alternativa, puedes configurar tu red local para permitir que el tráfico fluya de un entorno de Google Cloud al entorno local y, luego, a otro entorno de Google Cloud.
Topología de red de concentrador y radio
Si implementas recursos en Google Cloud que requieren una ruta de red directa a los recursos en varios entornos, te recomendamos la topología de red de concentrador y radio.
La topología de concentrador y radio usa varios de los conceptos que forman parte de la topología de VPC compartida doble, pero modifica la topología para agregar una red de concentrador. El siguiente diagrama muestra la topología de concentrador y radio.
El diagrama describe estos conceptos clave de la topología de red de concentrador y radio:
- Este modelo agrega una red central y cada una de las redes de desarrollo, no producción y producción (radios) se conecta a la red central mediante el intercambio de tráfico entre redes de VPC. Como alternativa, si anticipas que excede el límite de la cuota, puedes usar una puerta de enlace de VPN con alta disponibilidad en su lugar.
- La conectividad a las redes locales solo se permite a través de la red central. Todas las redes de radio pueden comunicarse con recursos compartidos en la red de concentrador y usar esta ruta de acceso para conectarse a redes locales.
- Las redes de concentrador incluyen un NVA para cada región, que se implementa de forma redundante detrás de las instancias del balanceador de cargas de red interno. Este NVA actúa como la puerta de enlace para permitir o denegar la comunicación del tráfico entre redes de radio.
- La red central también aloja herramientas que requieren conectividad a todas las demás redes. Por ejemplo, puedes implementar herramientas en las instancias de VM para la administración de configuración en el entorno común.
- El modelo de concentrador y radio se duplica para una versión base y una versión restringida de cada red.
Para habilitar el tráfico de radio a radio, el plano implementa NVA en la red de VPC compartida de concentrador que actúan como puertas de enlace entre redes. Estas rutas se intercambian desde las redes de VPC del concentrador al radio a través del intercambio de rutas personalizadas. En esta situación, la conectividad entre los radios se debe enrutar a través del NVA porque el intercambio de tráfico entre redes de VPC no es transitivo y, por lo tanto, las redes de VPC de radio no pueden intercambiar datos de forma directa. Debes configurar los dispositivos virtuales para permitir el tráfico de forma selectiva entre los radios.
Si deseas obtener más información sobre el uso de NVA para controlar el tráfico entre radios, consulta Dispositivos de red centralizados en Google Cloud.
Patrones de implementación de proyectos
Cuando creas proyectos nuevos para las cargas de trabajo, debes decidir cómo se conectan los recursos de este proyecto a tu red existente. En la siguiente tabla, se describen los patrones para implementar proyectos que se usan en el plano.
| Patrón | Descripción | Ejemplo de uso |
|---|---|---|
| Proyectos base compartidos | Estos proyectos se configuran como proyectos de servicio para un proyecto host de VPC compartida de base. Usa este patrón cuando los recursos de tu proyecto tengan los siguientes criterios:
|
example_base_shared_vpc_project.tf |
| Proyectos restringidos compartidos | Estos proyectos se configuran como proyectos de servicio para un proyecto host de VPC compartida restringido. Usa este patrón cuando los recursos de tu proyecto tengan los siguientes criterios:
|
example_restricted_shared_vpc_project.tf |
| Proyectos flotantes | Los proyectos flotantes no están conectados a otras redes de VPC en tu topología. Usa este patrón cuando los recursos de tu proyecto tengan los siguientes criterios:
Es posible que tengas una situación en la que desees mantener la red de VPC de un proyecto flotante separada de la topología de red principal de VPC, pero también quieras exponer una cantidad limitada de extremos entre redes. En este caso, publica servicios mediante Private Service Connect para compartir el acceso a la red a un extremo individual entre redes de VPC sin exponer toda la red. |
example_floating_project.tf |
| Proyectos de intercambio de tráfico | Los proyectos de intercambio de tráfico crean sus propias redes de VPC e intercambian tráfico con otras redes de VPC en tu topología. Usa este patrón cuando los recursos de tu proyecto tengan los siguientes criterios:
Si creas proyectos de intercambio de tráfico, es tu responsabilidad asignar rangos de direcciones IP sin conflictos y planificar la cuota del grupo de intercambio de tráfico. |
example_peering_project.tf |
Asignación de direcciones IP
En esta sección, se presenta cómo la arquitectura del plano asigna rangos de direcciones IP. Es posible que debas cambiar los rangos específicos de direcciones IP que se usan en función de la disponibilidad de la dirección IP en tu entorno híbrido existente.
En la siguiente tabla, se proporciona un desglose del espacio de direcciones IP que se asignó para el plano. El entorno de concentrador solo se aplica en la topología de concentrador y radio.
| Objetivo | Tipo de VPC | Región | Entorno de concentrador | Entorno de desarrollo | Entorno que no es de producción | Entorno de producción |
|---|---|---|---|---|---|---|
| Rangos de subredes principales | Capas | Región 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
| Región 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
| No asignado | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
| Restringido | 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 | ||
| No asignado | 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 privado a servicios | Capas | Global | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
| Restringido | Global | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
| Extremos de Private Service Connect | Capas | Global | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
| Restringido | 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 | Capas | Región 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
| Región 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
| No asignado | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
| Restringido | 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 | ||
| No asignado | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
| Rangos de subred secundarios | Capas | Región 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
| Región 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
| No asignado | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
| Restringido | 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 | ||
| No asignado | 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 rangos de direcciones IP:
- La asignación de una dirección IP se subdivide en rangos para cada combinación de VPC compartida base, VPC compartida restringida, región y entorno.
- Algunos recursos son globales y no requieren subdivisiones para cada región.
- De forma predeterminada, para los recursos regionales, el plano se implementa en dos regiones. Además, hay rangos de direcciones IP sin usar para que puedas expandir las seis regiones adicionales.
- La red de concentrador solo se usa en la topología de red de concentrador y radio, mientras que los entornos de desarrollo, de no producción y de producción se usan en ambas topologías de red.
En la siguiente tabla, se presenta cómo se usa cada tipo de rango de direcciones IP.
| Objetivo | Descripción |
|---|---|
| Rangos de subredes principales | Los recursos que implementas en tu red de VPC, como las instancias de máquina virtual, usan direcciones IP internas de estos rangos. |
| Acceso privado a servicios | Algunos servicios de Google Cloud, como Cloud SQL, requieren que asignes previamente un rango de subred para el acceso privado a servicios. El plano reserva un rango /21 a nivel global para cada una de las redes de VPC compartidas a fin de asignar direcciones IP a los servicios que requieren acceso privado a servicios. Cuando crees un servicio que dependa del acceso privado a servicios, deberás asignar una subred /24 regional desde el rango reservado /21. |
| Private Service Connect | El plano aprovisiona cada red de VPC con un extremo de Private Service Connect para comunicarse con las APIs de Google Cloud. Este extremo permite que tus recursos en la red de VPC lleguen a las APIs de Google Cloud sin depender del tráfico saliente a Internet o a los rangos de Internet anunciados de forma pública. |
| Balanceadores de cargas basados en proxy | Algunos tipos de balanceadores de cargas de aplicaciones requieren que asignes previamente subredes de solo proxy. Aunque el plano no implementa balanceadores de cargas de aplicaciones que requieren este rango, la asignación de rangos por adelantado ayuda a reducir la fricción para las cargas de trabajo cuando deben solicitar un rango de subred nuevo a fin de habilitar ciertos recursos del balanceador de cargas. |
| Rangos de subred secundarios | Algunos casos prácticos, como las cargas de trabajo basadas en contenedores, requieren rangos secundarios. El plano asigna rangos del espacio de direcciones IP RFC 6598 para rangos secundarios. |
Configuración de DNS centralizada
Para la resolución de DNS entre Google Cloud y entornos locales, te recomendamos que uses un enfoque híbrido con dos sistemas DNS confiables. En este enfoque, Cloud DNS controla la resolución de DNS autorizada para tu entorno de Google Cloud y tus servidores DNS locales existentes manejan la resolución de DNS confiable para los recursos locales. Tu entorno local y el entorno de Google Cloud realizan búsquedas de DNS entre entornos a través de solicitudes de reenvío.
En el siguiente diagrama, se muestra la topología de DNS en las múltiples redes de VPC que se usan en el plano.
En el diagrama, se describen los siguientes componentes del diseño de DNS que implementa el plano:
- El proyecto del concentrador de DNS en la carpeta común 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 interconexión dedicada y Cloud Routers que ya están configurados en tu topología de red.
- En la topología de VPC compartida doble, el concentrador de DNS usa la red de VPC compartida de producción base.
- En la topología de concentrador y radio, el concentrador de DNS usa la red de VPC compartida del concentrador base.
- Los servidores de cada red de VPC compartida pueden resolver los registros DNS de otras redes de VPC compartida a través del reenvío de DNS, que se configura entre Cloud DNS en cada proyecto host de VPC compartida y el concentrador de DNS.
- Los servidores locales pueden resolver los registros DNS en los entornos de Google Cloud mediante las políticas de servidor DNS que permiten consultas desde servidores locales. El plano configura una política de servidor entrante en el concentrador de DNS para asignar direcciones IP, y los servidores DNS locales reenvían solicitudes a estas direcciones. Todas las solicitudes de DNS a Google Cloud llegan primero al concentrador de DNS, que luego resuelve los registros de los pares DNS.
- Los servidores de Google Cloud pueden resolver los registros DNS en el entorno local mediante las zonas de reenvío que consultan los servidores locales. Todas las solicitudes de DNS al entorno local se originan en el concentrador de DNS. La fuente de la solicitud de DNS es 35.199.192.0/19.
Políticas de firewall
Google Cloud tiene varios tipos de políticas de firewall. Las políticas de firewall jerárquicas se aplican a nivel de organización o carpeta a fin de heredar las reglas de políticas de firewall de manera coherente en todos los recursos de la jerarquía. Además, puedes configurar políticas de firewall de red para cada red de VPC. El plano combina estas políticas de firewall para aplicar opciones de configuración comunes en todos los entornos mediante políticas de firewall jerárquicas y aplicar opciones de configuración más específicas en cada red de VPC individual mediante políticas de firewall de red.
El plano no usa reglas de firewall de VPC heredadas. Recomendamos usar solo políticas de firewall y evitar el uso mixto de reglas de firewall de VPC heredadas.
Políticas jerárquicas de firewall
El plano define una sola política de firewall jerárquica y adjunta la política a cada una de las carpetas de producción, no producción, desarrollo, arranque y común. Esta política de firewall jerárquica contiene las reglas que se deben aplicar de manera amplia en todos los entornos y delega la evaluación de reglas más detalladas a la política de firewall de red para cada entorno individual.
En la siguiente tabla, se describen las reglas de políticas de firewall jerárquicas que implementa el plano.
| Descripción de la regla | Dirección del tráfico | Filtro (rango IPv4) | Protocolos y puertos | Acción |
|---|---|---|---|---|
| Delega la evaluación del tráfico entrante de RFC 1918 a niveles inferiores en 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 a niveles inferiores en 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 la redirección de TCP | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
Allow |
| Activación de Windows Server | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Verificaciones de estado para 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 firewall de red
El plano configura una política de firewall de red para cada red. Cada política de firewall de red comienza con un conjunto mínimo de reglas que permiten el acceso a los servicios de Google Cloud y rechazan la salida a todas las demás direcciones IP.
En el modelo de concentrador y radio, las políticas de firewall de red contienen reglas adicionales para permitir la comunicación entre los radios. La política de firewall de red permite el tráfico saliente de un radio a un concentrador o a otro radio, y permite el tráfico entrante desde el NVA en la red del concentrador.
En la siguiente tabla, se describen las reglas en la política de firewall de red global implementada para cada red de VPC en el plano.
| Descripción de la regla | Dirección del tráfico | Filtro | Protocolos y puertos |
|---|---|---|---|
| Permitir el tráfico de salida a las APIs de Google Cloud. | Egress |
El extremo de Private Service Connect que se configura para cada red individual. 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 saliente de un radio a otro (solo para modelo de concentrador y radio). |
Egress |
La suma de todas las direcciones IP que se usaron en la topología de concentrador y radio. El tráfico que sale de una VPC de radio se enruta primero al NVA en la red central. | all |
Permitir el tráfico entrante a un radio desde el NVA en la red central (solo para el modelo de concentrador y radio). |
Ingress |
El tráfico que se origina en los NVA de la red central. | all |
Cuando implementas el plano por primera vez, una instancia de VM en una red de VPC puede comunicarse con los servicios de Google Cloud, pero no con otros recursos de la infraestructura en la misma red de VPC. Para permitir que las instancias de VM se comuniquen, debes agregar reglas adicionales a tu política de firewall de red y etiquetas que permiten que las instancias de VM se comuniquen de forma explícita. Las etiquetas se agregan a las instancias de VM y el tráfico se evalúa en función de esas etiquetas. Además, las etiquetas tienen controles de IAM para que puedas definirlas de forma centralizada y delegar su uso a otros equipos.
En el siguiente diagrama, se muestra un ejemplo de cómo agregar etiquetas personalizadas y reglas de políticas de firewall 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 firewall de red contiene la regla 1 que rechaza el tráfico saliente de todas las fuentes en la prioridad 65530.
- La política de firewall de red contiene la regla 2 que permite el tráfico entrante de las instancias con la etiqueta
service=frontenda las instancias con la etiquetaservice=backenden 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 coincide 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 firewall que coincide con este tráfico es la regla 1, por lo que se rechaza el tráfico saliente de instance-1.
Acceso privado a las APIs de Google Cloud
Para permitir que los recursos de tus redes de VPC o entornos locales lleguen a los servicios de Google Cloud, recomendamos la conectividad privada en lugar del tráfico de Internet saliente a extremos de APIs públicas. El plano configura el Acceso privado a Google en cada subred y crea extremos internos con Private Service Connect para comunicarse con los servicios de Google Cloud. En conjunto, estos controles permiten una ruta privada a los servicios de Google Cloud, sin depender del tráfico de salida de Internet ni de los rangos de Internet anunciados de forma pública.
El plano configura extremos de Private Service Connect con paquetes de API para diferenciar a qué servicios se puede acceder en qué red. La red base usa el paquete all-apis y puede acceder a cualquier servicio de Google, y la red restringida usa el paquete vpcsc, que permite el acceso a un conjunto limitado de servicios que admiten Controles del servicio de VPC.
Para el acceso desde hosts que se encuentran en un entorno local, te recomendamos que uses una convención de FQDN personalizado para cada extremo, como se describe en la siguiente tabla. El plano usa un extremo único de Private Service Connect para cada red de VPC, configurado a fin de acceder a un conjunto diferente de paquetes de API. Por lo tanto, debes considerar cómo enrutar el tráfico de servicio desde el entorno local a la red de VPC con el extremo de API correcto y, si usas Controles del servicio de VPC, asegúrate de que el tráfico a los servicios de Google Cloud llegan al extremo dentro del perímetro previsto. Configura los controles locales para DNS, firewalls y routers a fin de permitir el acceso a estos extremos, y configura hosts locales para usar el extremo adecuado. Para obtener más información, consulta Accede a las APIs de Google a través de extremos.
En la siguiente tabla, se describen los extremos de Private Service Connect que se crearon para cada red.
| VPC | Entorno | Paquete de API | Dirección IP del extremo de Private Service Connect | FQDN personalizado | ||||
|---|---|---|---|---|---|---|---|---|
| Capas | Common | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
| Desarrollo | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
| No producción | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
| Producción | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
| Restringido | Common | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
| Desarrollo | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
| No producción | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
| Producción | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
|||||
Para garantizar que el tráfico de los servicios de Google Cloud tenga una búsqueda de DNS en el extremo correcto, el plano configura zonas de DNS privadas para cada red de VPC. En la siguiente tabla, se describen estas zonas de DNS privadas.
| Nombre de zona privada | Nombre de DNS | Tipo de registro | Datos |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com. (para redes base) o restricted.googleapis.com. (para redes restringidas) |
private.googleapis.com (para redes base) o restricted.googleapis.com (para redes restringidas) |
A |
La dirección IP del extremo de Private Service Connect para esa red de VPC. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
La dirección IP del extremo de Private Service Connect para esa red de VPC. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
La dirección IP del extremo de Private Service Connect para esa red de VPC. |
El plano tiene configuraciones adicionales para garantizar que estos extremos de Private Service Connect se usen de manera coherente. Cada red de VPC compartida también aplica lo siguiente:
- Una regla de política de firewall de red que permite el tráfico saliente de todas las fuentes a la dirección IP del extremo de Private Service Connect en TCP:443.
- Una regla de política de firewall de red que rechaza el tráfico saliente a 0.0.0.0/0, 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 de entrada ni de salida entre sus redes de VPC e Internet. Para las cargas de trabajo que requieren conectividad a Internet, debes tomar medidas adicionales para diseñar las rutas de acceso necesarias.
Para las cargas de trabajo que requieren tráfico saliente a Internet, te recomendamos que administres el tráfico saliente a través de Cloud NAT para permitir el tráfico saliente sin conexiones entrantes no solicitadas, o mediante Proxy web seguro para obtener un control más detallado para permitir el tráfico de salida a servicios web de confianza.
Para las cargas de trabajo que requieren tráfico entrante de Internet, te recomendamos que diseñes tu carga de trabajo con:Cloud Load Balancing y Google Cloud Armor para aprovechar las protecciones contra DDoS y WAF.
No 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 y Google Cloud, te recomendamos que uses la interconexión dedicada a fin de maximizar la seguridad y la confiabilidad. Una conexión de interconexión dedicada es un vínculo directo entre tu red local y Google Cloud.
En el siguiente diagrama, se presenta la conectividad híbrida entre el entorno local y una red de nube privada virtual de Google.
En el diagrama, se describen los siguientes componentes del patrón para la disponibilidad del 99.99% para la interconexión dedicada:
- Cuatro conexiones de interconexión dedicada, con dos conexiones en una área metropolitana (metro) y dos conexiones en otra área.
- Las conexiones se dividen en dos pares, y cada par se conecta a un centro de datos local independiente.
- Los adjuntos de VLAN se usan para conectar cada instancia de interconexión dedicada a los Cloud Routers que están conectados a la topología de VPC compartida. Estos adjuntos de VLAN se alojan en el proyecto
prj-c-interconnect. - Cada red de VPC compartida tiene cuatro Cloud Routers, dos en cada región, con el modo de enrutamiento dinámico configurado en
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 que se encuentran en la red de VPC. Cloud Router anuncia rutas a subredes remotas (ubicadas fuera de la región de Cloud Router) con una propiedad más baja en comparación con las subredes locales (ubicadas en la región de Cloud Router). De manera opcional, puedes cambiar las prioridades y los prefijos anunciados cuando configuras la sesión de BGP para un Cloud Router.
El tráfico de Google Cloud a un entorno local usa el Cloud Router más cercano a los recursos en la nube. Dentro de una sola región, varias rutas a redes locales tienen el mismo valor de discriminante de varias salidas (MED) y Google Cloud usa el enrutamiento de ruta de acceso múltiple de igual costo (ECMP) para distribuir el tráfico saliente entre todas las rutas posibles.
Cambios en la configuración local
Para configurar la conectividad entre el entorno local y Google Cloud, debes configurar cambios adicionales en tu entorno local. El código de Terraform en el plano configura de forma automática los recursos de Google Cloud, pero no modifica ninguno de tus recursos de red locales.
El plano habilita automáticamente algunos de los componentes de la conectividad híbrida de tu entorno local a Google Cloud, incluidos los siguientes:
- En Cloud DNS, se configura el reenvío de DNS entre todas las redes de VPC compartidas a un solo concentrador, como se describe en Configuración de DNS. Una política del servidor de Cloud DNS se configura con direcciones IP de reenvío entrantes.
- Cloud Router se configura a fin de exportar rutas para todas las subredes y rutas personalizadas para las direcciones IP que usan los extremos de Private Service Connect.
Para habilitar la conectividad híbrida, debes seguir estos pasos adicionales:
- Solicita una conexión de interconexión dedicada.
- Configura routers y firewalls locales para permitir el tráfico de ida al espacio de direcciones IP internas definido en Asignación de espacio de direcciones IP.
- Configura tus servidores DNS locales para reenviar las búsquedas de DNS vinculadas a Google Cloud a las direcciones IP de reenvío entrantes que ya está configurada por el plano.
- Configura los servidores DNS, los firewalls y los routers locales para aceptar consultas de DNS desde la zona de reenvío de Cloud DNS (35.199.192.0/19).
- Configura los servidores DNS locales para que respondan a las consultas de hosts locales a los servicios de Google Cloud con las direcciones IP definidas en el acceso privado a las APIs de Cloud.
- Para la encriptación en tránsito a través de la conexión de interconexión dedicada, configura MACsec para Cloud Interconnect o configura VPN con alta disponibilidad mediante Cloud Interconnect para la encriptación de IPsec.
Si deseas obtener más información, consulta Acceso privado a Google para hosts locales.
Próximos pasos
- Lee sobre los controles de detección (siguiente documento de esta serie).