Servicios de perímetro de red para implementaciones de múltiples entornos

Google ofrece varios servicios perimetrales de la 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 red perimetral te permiten realizar las siguientes acciones:

Ejemplo de servicios perimetrales de la red.
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, debes implementar un balanceador de cargas de HTTP(S) externo para recibir tráfico de la Internet pública. El balanceador de cargas de HTTP(S) 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.

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. Crear 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 HTTP(S) externo para recibir tráfico de la Internet pública y reenviarlo al proxy central.
  5. Conecta una política de seguridad de Google Cloud Armor al balanceador de cargas de HTTP(S) 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.

  • Asegúrate de que se pueda acceder a tus extremos privados locales 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 seguirla. En una situación de implementación real, se requerirá configuración de 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 se superponen direcciones IP, se priorizan las rutas de subred mediante 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 del medio

  1. Crea el MIG en función de 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 verificación 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-.*'" \
        --zone=us-central1-a \
        --format="value(networkInterfaces.networkIP)"
    

En este ejemplo, creamos el MIG que contiene las 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 automáticamente el tráfico a la región más cercana a tus clientes y al MIG dentro de esa región, es posible que quieras crear varios MIG. Para obtener una lista completa de las regiones y zonas disponibles de Google Cloud, consulta Regiones y zonas.

Implemente 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, se crea una VM de Compute Engine a la que se puede 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.

  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 centralizado de verificación de estado de Google Cloud:

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

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 creaste antes:

    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
    

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 import a fin de crear el proxy HTTP de destino (si deseas 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 a 0.0.0.0 enruta el tráfico según el puerto entrante, el nombre de host HTTP y la información de 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
    

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 central. Solo necesitas esta información para el paso de verificación:

    gcloud compute instances list
    
  2. Anota o anota la dirección IP de la instancia en el MIG 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 central 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 HTTP(S) externo

En esta sección, implementarás un balanceador de cargas de HTTP(S) externo que envía tráfico entrante al proxy intermedio. Esta es una configuración del balanceador de cargas de HTTP(S) externo.

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. Deberás recuperar 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 central:

    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 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 según el 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
    

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 HTTP(S) 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

Configura las políticas de seguridad de Google Cloud Armor para permitir solo el acceso a tu servicio desde CLIENT_IP_RANGE, que debe incluir la dirección IP pública del dispositivo cliente con el que deseas realizar la prueba, 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 quieres obtener más información sobre los permisos necesarios para configurar 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 pública virtual del balanceador de cargas de HTTP(S) externo. Si la dirección IP de tu dispositivo cliente se encuentra dentro del CLIENT_IP_RANGE permitido, especificado antes, debes 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 HTTP(S) 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 el MIG de Google Cloud Envoy esté en buen estado. En Google Cloud Console, 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 1/1 de la instancia en td-middle-proxy-us-central1-a en buen estado.

  2. Si no está en buen estado, verifica si se configuró una regla de firewall 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?