Configura servicios de red perimetral para implementaciones híbridas

Google ofrece varios servicios de perímetro de red que pueden aumentar las capacidades y la seguridad de los servicios fuera de Google Cloud (servicios locales y de múltiples nubes), por ejemplo, en un centro de datos local o en otra nube pública.

Estos servicios de perímetro de red te permiten hacer lo siguiente:

• Aceptar y enrutar el tráfico de clientes externos a nivel mundial con un solo VIP de Anycast

• Reduce la carga del servidor mediante la finalización del tráfico TLS en el perímetro con un balanceador de cargas de aplicaciones externo y certificados SSL administrados por Google.

• Habilita las reglas de firewall de aplicación web (WAF) preconfiguradas y aplica listas de entidades permitidas y de bloqueo al tráfico entrante con Google Cloud Armor.

• Controla el acceso de los usuarios a tus aplicaciones y recursos con Identity-Aware Proxy.

• Optimiza la entrega de contenido y la latencia del usuario final con Cloud CDN.

Ejemplo de servicios perimetrales de la red (haz clic para agrandar)

Para implementar estos beneficios en tus servicios privados, locales o de múltiples nubes, implementa un balanceador de cargas de aplicaciones externo a fin de recibir tráfico de la Internet pública. El balanceador de cargas de aplicaciones externo reenvía el tráfico a un proxy intermedio que configura Traffic Director. Este proxy intermedio enruta el tráfico a tu entorno local o a un entorno que no es de Google Cloud mediante Cloud VPN o Cloud Interconnect.

Nota: Los balanceadores de cargas de aplicaciones externos proporcionan una funcionalidad similar cuando usan grupos de extremos de red (NEG) de Internet. El tráfico se puede enviar directo a las direcciones IP de acceso público y a los nombres de dominio completamente calificados (FQDN) que se pueden resolver fuera de Google Cloud, sin la necesidad de un proxy intermedio. Sin embargo, este tráfico no recorre tu red de nube privada virtual (VPC) y no puede enrutarse a un extremo remoto con una conexión privada. Para obtener más información sobre la compatibilidad con extremos públicos, consulta Descripción general de grupos de extremos de red de Internet.

En este instructivo, se explica un ejemplo de extremo a extremo que usa Google Cloud Armor en el extremo de Google para permitir que los clientes accedan a un servicio local de forma privada. Los clientes pueden acceder en función de su dirección IP.

Completa las siguientes tareas:

1. Implementa Envoy como un proxy intermedio en un grupo de instancias administrado (MIG). Este proxy de Envoy se conecta de forma automática a Traffic Director.
2. Crea una instancia de máquina virtual (VM) local privada y simulada. En un ejemplo real, es probable que ya tengas una VM local.
3. Configura Traffic Director para enrutar todas las solicitudes que llegan al proxy central a la VM local simulada
4. Crea un balanceador de cargas de aplicaciones externo para recibir tráfico de la Internet pública y reenviarlo al proxy central.
5. Adjunta una política de seguridad de Google Cloud Armor al balanceador de cargas de aplicaciones externo.

Después de completar estas tareas, puedes explorar servicios adicionales y funciones avanzadas de administración del tráfico.

Requisitos previos

Antes de configurar tu proxy central, completa las siguientes tareas:

• Revisa Prepárate para configurar Traffic Director con Envoy y completa todas las tareas de requisitos previos, que incluyen otorgar los permisos y roles necesarios y habilitar la API de Traffic Director.

• Asegúrate de que se pueda acceder a los extremos locales privados desde tu red de nube privada virtual (VPC) de Google Cloud a través de Cloud VPN o Cloud Interconnect. En el ejemplo que se usa en este instructivo, solo se enruta el tráfico a un extremo dentro de Google Cloud, por lo que no necesitas configurar la conectividad híbrida para seguirlo. En una situación de implementación real, se requeriría la configuración de la conectividad híbrida.

• Asegúrate de que los rangos CIDR de tu subred de VPC no entren en conflicto con tus rangos de CIDR remotos. Cuando las direcciones IP se superponen, las rutas de subred se priorizan por sobre la conectividad remota.

• En esta demostración, obtén los permisos necesarios para crear y actualizar las políticas de seguridad de Google Cloud Armor. Es posible que los permisos varíen si deseas usar un servicio diferente, como Cloud CDN.

Implementa el proxy intermedio en las VM de Compute Engine

En esta sección, se describe cómo implementar Envoy como un proxy intermedio en Compute Engine para recibir tráfico del balanceador de cargas externo y reenviarlo a tu destino remoto.

Crea la plantilla de instancias para el proxy intermedio

Una plantilla de instancias especifica la configuración de VM dentro de un grupo de instancias administrado (MIG).

1. Usa la siguiente plantilla para crear instancias de VM con un proxy de Envoy conectado a Traffic Director:

   gcloud compute instance-templates create td-middle-proxy \
       --service-proxy=enabled \
       --tags=allow-hc
   

2. Para personalizar tu implementación de Envoy, por ejemplo, si especificas el nombre de red, debes establecer una ruta de registro o habilitar el seguimiento, consulta la Guía de opciones de implementación automática de Envoy.

Crea el MIG para el proxy medio

1. Crear un MIG basado en la plantilla En este ejemplo, puedes conservar el tamaño del grupo de instancias de 1 para implementar una sola instancia. Para el uso en producción, habilita el ajuste de escala automático, por ejemplo, según el uso de CPU, a fin de evitar crear un cuello de botella si el proxy intermedio necesita manipular mucho tráfico.

   gcloud compute instance-groups managed create td-middle-proxy-us-central1-a \
       --zone=us-central1-a \
       --template=td-middle-proxy \
       --size=1
   

2. Para configuraciones y verificaciones futuras, identifica y almacena la dirección IP interna de la instancia en MIDDLE_PROXY_IP:

   MIDDLE_PROXY_IP=$(gcloud compute instances list \
       --filter="name~'td-middle-proxy-us-central1-a-.*'" \
       --zones=us-central1-a \
       --format="value(networkInterfaces.networkIP)")
   

En este ejemplo, creamos el MIG que contiene instancias de VM que ejecutan Envoy en us-central1-a. Más adelante en este instructivo, crearás un balanceador de cargas externo para manejar el tráfico de Internet público de tus clientes.

Debido a que el balanceador de cargas externo puede enrutar de forma automática el tráfico a la región más cercana a tus clientes y al MIG dentro de esa región, es posible que desees crear varios MIG. Para obtener una lista completa de las regiones y zonas disponibles de Google Cloud, consulta Regiones y zonas.

Implementa el servicio local simulado

En esta sección, se describe cómo implementar un grupo de extremos de red de conectividad híbrida (NEG). En una implementación de producción, este NEG contendrá un extremo (IP:port) que se resuelve en tu servidor local. En este ejemplo, solo debes crear una VM de Compute Engine a la que se pueda acceder en un IP:port. Esta VM actúa como tu servidor local simulado.

Crea la VM local simulada

1. Implementa una sola instancia de VM para simular un servidor privado local

   gcloud compute instances create on-prem-vm \
       --zone=us-central1-a \
       --metadata startup-script='#! /bin/bash
   ## Installs apache and a custom homepage
   sudo su -
   apt-get update
   apt-get install -y apache2
   cat <<EOF > /var/www/html/index.html
   <html><body><h1>Hello world from on-premises!</h1></body></html>
   EOF'
   

2. Identifica y almacena su dirección IP interna para opciones de configuración y verificaciones futuras. El servidor de esta VM escucha las solicitudes entrantes en el puerto 80:

   ON_PREM_IP=$(gcloud compute instances describe on-prem-vm \
       --zone=us-central1-a \
       --format="value(networkInterfaces.networkIP)" | sed "s/['\[\]]*//g")
   

Crea el NEG

Crea el NEG para esta configuración de demostración mediante la especificación del tipo de extremo de red non-gcp-private-ip-port. Agrega la dirección IP y el puerto para tu VM local simulada como extremo a este NEG. En el paso anterior, la dirección IP se almacena en la variable de entorno ON_PREM_IP.

Nota: En una implementación de producción, debes usar el IP:port del servidor local en lugar del IP:port de la VM local simulada. Se debe poder acceder a este IP:port desde el proxy intermedio de la red de VPC.

1. Crea el NEG:

   gcloud compute network-endpoint-groups create td-on-prem-neg \
       --network-endpoint-type=non-gcp-private-ip-port \
       --zone=us-central1-a
   

2. Agrega IP:port a tu NEG nuevo:

   gcloud compute network-endpoint-groups update td-on-prem-neg \
       --zone=us-central1-a \
       --add-endpoint="ip=$ON_PREM_IP,port=80"
   

Configura Traffic Director con componentes de Cloud Load Balancing

En esta sección, se muestra cómo configurar Traffic Director y permitir que tu proxy intermedio reenvíe el tráfico a tu servicio privado local. Debes configurar los siguientes componentes:

• Una verificación de estado. Esta verificación de estado se comporta de manera un poco diferente a las verificaciones de estado configuradas para otros tipos de NEG.

• Un servicio de backend. Para obtener información detallada, consulta Descripción general de los servicios de backend.

• Un mapa de reglas de enrutamiento. Esto incluye crear una regla de reenvío, un proxy de destino y un mapa de URL. Para obtener más información, consulta Mapas de reglas de enrutamiento.

Crea la verificación de estado

Las verificaciones de estado verifican que tus extremos estén en buen estado y puedan recibir solicitudes. Las verificaciones de estado para este tipo de NEG se basan en el mecanismo de verificación de estado distribuido de Envoy.

Otros tipos de NEG usan el sistema de verificación de estado centralizado de Google Cloud:

gcloud compute health-checks create http td-on-prem-health-check

Nota: La verificación de estado distribuida de Envoy da como resultado un tráfico de red adicional en tu canal de conectividad híbrida. El tráfico de la verificación de estado escala con la cantidad de extremos agregados a NEG con el tipo non-gcp-private-ip-port y la cantidad de proxies de Envoy que verifican estos extremos.

Crea el servicio de backend.

1. Crea un servicio de backend con el esquema de balanceo de cargas de INTERNAL_SELF_MANAGED para usarlo con Traffic Director. Cuando crees este servicio de backend, especifica la verificación de estado que acabas de crear.

   gcloud compute backend-services create td-on-prem-backend-service \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --health-checks=td-on-prem-health-check
   

2. A continuación, agrega el NEG que creaste antes como el backend de este servicio de backend.

   gcloud compute backend-services add-backend td-on-prem-backend-service \
       --global \
       --network-endpoint-group=td-on-prem-neg \
       --network-endpoint-group-zone=us-central1-a \
       --balancing-mode=RATE \
       --max-rate-per-endpoint=5
   

Nota: Un solo servicio de backend no puede incluir backends de diferentes tipos. Por ejemplo, no puedes mezclar MIG y NEG de diferentes tipos en el mismo servicio de backend. Sin embargo, tu mapa de URL puede tener reglas de enrutamiento que se resuelvan en diferentes servicios de backend, lo que permite la administración avanzada de enrutamiento y tráfico para diferentes tipos de servicios.

Crea el mapa de reglas de enrutamiento

El mapa de reglas de enrutamiento define cómo Traffic Director enruta el tráfico a tu servicio de backend.

1. Crea un mapa de URL que use el servicio de backend definido con anterioridad.

   gcloud compute url-maps create td-hybrid-url-map \
       --default-service=td-on-prem-backend-service
   

2. Crea un archivo target_proxy.yaml con el siguiente contenido:

   name: td-hybrid-proxy
   proxyBind: true
   urlMap: global/urlMaps/td-hybrid-url-map
   

3. Usa el comando de import a fin de crear el proxy HTTP de destino (a fin de obtener más información, consulta Proxies de destino para Traffic Director):

   gcloud compute target-http-proxies import td-hybrid-proxy \
       --source=target_proxy.yaml
   

4. Crea una regla de reenvío que haga referencia a este proxy HTTP de destino. Establece la dirección IP de la regla de reenvío en 0.0.0.0. Configurar la dirección IP de la regla en 0.0.0.0 enruta el tráfico según el puerto entrante, el nombre de host HTTP y la información de la ruta configurada en el mapa de URL. Se ignora la dirección IP especificada en la solicitud HTTP.

   gcloud compute forwarding-rules create td-hybrid-forwarding-rule \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --address=0.0.0.0 \
       --target-http-proxy=td-hybrid-proxy \
       --ports=8080 \
       --network=default
   

Nota: Con proxyBind habilitada, configurar la dirección de la regla de reenvío en un valor distinto de 0.0.0.0 fallará.

Verifica que el proxy intermedio pueda enrutar solicitudes al servicio local simulado

Traffic Director está configurado para enrutar el tráfico a través del proxy medio al servicio privado y simulado de forma local. Para verificar esta configuración, crea una VM de cliente de prueba, accede a esa VM y envía una solicitud al proxy central que ejecuta Envoy. Después de verificar la configuración, borra la VM de cliente de prueba.

1. Obtén la dirección IP del proxy intermedio. Solo necesitas esta información para el paso de verificación:

   gcloud compute instances list
   

2. Escribe la dirección IP de la instancia o anótala en el MIG de td-middle-proxy-us-central1-a.

3. Crea una instancia de cliente de prueba:

   gcloud compute instances create test-client \
       --zone=us-central1-a
   

4. Usa ssh para acceder al cliente de prueba:

   gcloud compute ssh test-client
       --zone=us-central1-a
   

5. Envía una solicitud a la VM del proxy intermedio y sustituye la dirección IP que obtuviste antes por MIDDLE_PROXY_IP:

   curl $MIDDLE_PROXY_IP:8080
   

   Debería ver el siguiente resultado:

   Hello world from on-premises!
   

6. Sal de la VM de cliente de prueba. Después de salir, puedes borrar la VM:

   gcloud compute instances delete test-client \
       --zone=us-central1-a
   

Implementa el balanceador de cargas de aplicaciones externo

En esta sección, implementarás un balanceador de cargas de aplicaciones externo que envía el tráfico entrante al proxy intermedio. Esta implementación es una configuración de balanceador de cargas de aplicaciones externo estándar.

Reservar una dirección IP externa

Crea una dirección IP externa estática global (external-lb-vip) a la que los clientes externos enviarán tráfico. Recupera esta dirección IP externa durante el paso de verificación más adelante en este instructivo.

gcloud compute addresses create external-lb-vip \
    --ip-version=IPV4 \
    --global

Configura el balanceador de cargas HTTP externo

Configura el balanceador de cargas externo para enrutar el tráfico de clientes de Internet a tu proxy intermedio ya configurado.

1. Crea una verificación de estado que se use para determinar si el MIG que ejecuta el proxy intermedio está en buen estado y puede recibir tráfico:

   gcloud compute health-checks create tcp tcp-basic-check \
       --port=8080
   

2. Cree una regla de firewall para permitir las verificaciones de estado. Aquí, deberás volver a usar la etiqueta allow-hc para aplicar la regla de firewall a las VM del proxy intermedio:

   gcloud compute firewall-rules create fw-allow-health-checks \
       --network=default \
       --action=ALLOW \
       --direction=INGRESS \
       --source-ranges=35.191.0.0/16,130.211.0.0/22 \
       --target-tags=allow-hc \
       --rules=tcp
   

3. Crea un servicio de backend:

   gcloud compute backend-services create td-middle-proxy-backend-service \
       --protocol=HTTP \
       --health-checks=tcp-basic-check \
       --global
   

4. Agrega el MIG del proxy intermedio como el backend a este servicio de backend:

   gcloud compute backend-services add-backend td-middle-proxy-backend-service \
       --instance-group=td-middle-proxy-us-central1-a \
       --instance-group-zone=us-central1-a \
       --global
   

5. Crea una asignación de URL para enrutar las solicitudes entrantes al proxy central como el servicio de backend predeterminado.

   gcloud compute url-maps create lb-map-http \
       --default-service=td-middle-proxy-backend-service
   

6. Crea un proxy HTTP de destino para que las solicitudes a la dirección IP virtual (VIP) de la regla de reenvío del balanceador de cargas externo se manejen en función del mapa de URL:

   gcloud compute target-http-proxies create http-lb-proxy \
       --url-map=lb-map-http
   

7. Crea una regla de reenvío global para enrutar las solicitudes entrantes al proxy HTTP de destino.

   gcloud compute forwarding-rules create http-forwarding-rule \
       --address=external-lb-vip\
       --global \
       --load-balancing-scheme=EXTERNAL \
       --target-http-proxy=http-lb-proxy \
       --ports=80
   

Nota: Para habilitar la comunicación HTTPS del el cliente al balanceador de cargas, configura un proxy HTTPS de destino en lugar de un proxy HTTP de destino. Luego, asígnale un certificado SSL administrado por Google o autoadministrado.

Configura el puerto con nombre del MIG

Configura un puerto con nombre para el grupo de instancias a fin de permitir que tu proxy intermedio reciba tráfico HTTP desde el balanceador de cargas externo.

gcloud compute instance-groups managed set-named-ports td-middle-proxy-us-central1-a \
    --named-ports=http:8080 \
    --zone=us-central1-a

Verifica la configuración del balanceador de cargas de aplicaciones externo

En este paso, verificarás que el balanceador de cargas externo esté configurado de forma correcta.

1. Deberías poder enviar una solicitud al VIP del balanceador de cargas y obtener una respuesta de la VM local simulada.

   PUBLIC_VIP=gcloud compute addresses describe external-lb-vip \
       --format="get(address)" \
       --global
   

2. Realiza una solicitud curl a la dirección IP pública y verifica que recibas el mensaje Hello world.

   curl $PUBLIC_VIP
   

   Verás el siguiente resultado:

   Hello world from on-premises!
   

Habilita Google Cloud Armor

Nota: Google Cloud Armor se usa aquí a modo de demostración. Puedes configurar cualquier otro servicio disponible en el balanceador de cargas externo, además de Google Cloud Armor, o en lugar de este. Los pasos anteriores se mantienen iguales.

Configura las políticas de seguridad de Google Cloud Armor para que solo puedan acceder a tu servicio desde CLIENT_IP_RANGE, que debe incluir la dirección IP pública del dispositivo cliente con el que deseas realizar pruebas. por ejemplo, "192.0.2.0/24".

Estas políticas se aplican en el servicio de backend del balanceador de cargas externo (en este ejemplo, td-hybrid-backend-service apunta al proxy central). Si deseas obtener más información sobre los permisos necesarios para establecer estas reglas, consulta Configura las políticas de seguridad de Google Cloud Armor.

1. Crea la política de seguridad de Google Cloud Armor.

   gcloud compute security-policies create external-clients-policy \
       --description="policy for external clients"
   

2. Actualiza la regla predeterminada de la política de seguridad para rechazar todo el tráfico.

   gcloud compute security-policies rules update 2147483647 \
       --security-policy=external-clients-policy \
       --action="deny-404"
   

3. Agrega una regla de prioridad más alta para permitir el tráfico desde un rango de IP específico.

   gcloud compute security-policies rules create 1000 \
       --security-policy=external-clients-policy \
       --description="allow traffic from CLIENT_IP_RANGE" \
       --src-ip-ranges="CLIENT_IP_RANGE" \
       --action="allow"
   

4. Adjunta las políticas de seguridad de Google Cloud Armor al servicio de backend.

   gcloud compute backend-services update td-middle-proxy-backend-service \
       --security-policy=external-clients-policy
   

Verificación final

1. Emite una solicitud curl a la dirección IP virtual pública del balanceador de cargas de aplicaciones externo. Si la dirección IP de tu dispositivo cliente se encuentra dentro del valor permitido CLIENT_IP_RANGE especificado con anterioridad, deberías recibir la respuesta esperada.

   curl $PUBLIC_VIP
   

   Verás el siguiente resultado:

   Hello world from on-premises!
   

2. Emite la misma solicitud curl de otro dispositivo cliente cuya dirección IP coincida con CLIENT_IP_RANGE o simplemente actualiza tu regla de política de seguridad para que ya no incluya tu dirección IP de cliente. Ahora deberías recibir un error 404 Not Found.

Soluciona problemas

No se puede acceder a mi servicio local a través de la dirección IP del balanceador de cargas de aplicaciones externo global

Si suponemos que ya puedes acceder a tu servicio local en las VM de Google Cloud que ejecutan Envoy, sigue estos pasos para solucionar problemas de la configuración.

1. Asegúrate de que se informe que el MIG de Envoy de Google Cloud se encuentra en buen estado. En la consola de Google Cloud, ve a Servicios de red > Balanceo de cargas y haz clic en url-map lb-map-http para ver los detalles. Deberías poder ver que 1/1 de la instancia en td-middle-proxy-us-central1-a se encuentra en buen estado.

2. Si no está en buen estado, verifica si una regla de firewall se configuró para permitir el tráfico de verificación de estado de entrada a las VM de Google Cloud que ejecutan Envoy:

   gcloud compute firewall-rules describe fw-allow-health-check
   

   Debería ver el siguiente resultado:

   allowed:
   ‑ IPProtocol: tcp
   ...
   direction: INGRESS
   disabled: false
   ...
   ...
   sourceRanges:
   ‑ 130.211.0.0/22
   ‑ 35.191.0.0/16
   targetTags:
   ‑ allow-hc
   

¿Qué sigue?

• A fin de encontrar políticas de enrutamiento más complejas para tus servicios locales o de múltiples nubes, consulta las funciones avanzadas de administración de tráfico de Traffic Director.

• Para implementar Traffic Director, consulta la Descripción general de la guía de configuración.

• Para habilitar servicios de red perimetral adicionales, consulta las siguientes guías:

  • Habilita IAP para Compute Engine
  • Configura Cloud CDN con un grupo de instancias administrado