Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

Configurar servicios de perímetro de red con grupos de endpoints de red de conectividad híbrida

Google ofrece varios servicios de perímetro de red que pueden aumentar las funciones y la seguridad de los servicios basados fuera de Google Cloud(servicios on-premise y multicloud), por ejemplo, en un centro de datos on-premise o en otra nube pública.

Estos servicios de red perimetral te permiten hacer lo siguiente:

Acepta y enruta el tráfico de clientes externos a nivel mundial con una sola VIP Anycast.
Reduce la carga del servidor finalizando el tráfico TLS en el perímetro con un balanceador de carga de aplicaciones externo y certificados SSL gestionados por Google.
Habilita reglas de cortafuegos de aplicaciones web (WAF) preconfiguradas y aplica listas de permitidos y listas de denegación al tráfico entrante con Google Cloud Armor.
Controla el acceso de los usuarios a tus aplicaciones y recursos con Identity-Aware Proxy (IAP).
Optimiza la distribución de contenido y la latencia de los usuarios finales con Cloud CDN.

Ejemplo de servicios de red perimetral. — Ejemplo de servicios de extremo de red (haz clic en la imagen para ampliarla)

Para disfrutar de estas ventajas en tus servicios privados, locales o multicloud, despliega un balanceador de carga de aplicación externo para recibir tráfico de Internet público. El balanceador de carga de aplicaciones externo reenvía el tráfico a un proxy intermedio que configura Cloud Service Mesh. Este proxy intermedio enruta el tráfico a tu entorno on-premise o a un entorno que no sea deGoogle Cloud mediante Cloud VPN o Cloud Interconnect.

En este tutorial se explica un ejemplo completo que usa Cloud Armor en el perímetro de Google para permitir de forma selectiva que los clientes accedan a un servicio local de forma privada. Se permite el acceso a los clientes en función de su dirección IP.

Debes completar las siguientes tareas:

Despliega Envoy como proxy intermedio en un grupo de instancias gestionado (MIG). Este proxy de Envoy se conecta automáticamente a Cloud Service Mesh.
Crea una instancia de máquina virtual (VM) privada y local simulada. En un ejemplo práctico, probablemente ya tengas una máquina virtual local.
Configura Cloud Service Mesh para enrutar todas las solicitudes que lleguen al proxy intermedio a la máquina virtual local simulada.
Crea un balanceador de carga de aplicaciones externo para recibir tráfico de la red pública de Internet y reenviarlo al proxy intermedio.
Asocia una política de seguridad de Cloud Armor al balanceador de carga de aplicaciones externo.

Una vez que hayas completado estas tareas, puedes explorar otros servicios perimetrales y funciones avanzadas de gestión del tráfico.

Requisitos previos

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

Consulta Preparar la configuración de Cloud Service Mesh con Envoy y completa todas las tareas previas, como conceder los permisos y roles necesarios y habilitar la API Cloud Service Mesh.
Asegúrate de que se pueda acceder a tus endpoints on-premise privados desde tu red de Google Cloud nube privada virtual (VPC) Google Cloud a través de Cloud VPN o Cloud Interconnect. En el ejemplo de este tutorial, solo se enruta el tráfico a un endpoint de Google Cloud, por lo que no es necesario configurar la conectividad híbrida para seguirlo. En un escenario de implementación real, sería necesario configurar la conectividad híbrida.
Asegúrate de que los intervalos CIDR de las subredes de tu VPC no entren en conflicto con los intervalos CIDR remotos. Cuando las direcciones IP se superponen, las rutas de subred tienen prioridad sobre la conectividad remota.
Para esta demostración, obtén los permisos necesarios para crear y actualizar políticas de seguridad de Cloud Armor. Los permisos pueden variar si quieres usar otro servicio, como Cloud CDN.

Desplegar el proxy intermedio en máquinas virtuales de Compute Engine

En esta sección se describe cómo desplegar Envoy como proxy intermedio en Compute Engine para recibir tráfico del balanceador de carga externo y reenviarlo a su destino remoto.

Crea la plantilla de instancia del proxy intermedio

Una plantilla de instancia especifica la configuración de las VMs de un grupo de instancias gestionado (MIG).

Usa la siguiente plantilla para crear instancias de VM con un proxy de Envoy conectado a Cloud Service Mesh:

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

Para personalizar tu despliegue de Envoy, por ejemplo, especificando el nombre de la red, definiendo una ruta de registro o habilitando el rastreo, consulta la guía de opciones para desplegar Envoy automáticamente.

Crea el MIG del proxy intermedio

Crea el MIG a partir de la plantilla. En este ejemplo, puedes mantener el tamaño del grupo de instancias en 1 para desplegar una sola instancia. Para usarlo en producción, habilita el autoescalado (por ejemplo, en función del uso de la CPU) para evitar que se produzca un cuello de botella si tu proxy intermedio tiene que gestionar 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
```

Para futuras configuraciones y verificaciones, 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 tutorial, crearás un balanceador de carga externo para gestionar el tráfico público de Internet de tus clientes.

Como el balanceador de carga externo puede enrutar automáticamente el tráfico a la región más cercana a sus clientes y al MIG de esa región, le recomendamos que cree varios MIGs. Para ver una lista completa de las regiones y zonas disponibles de Google Cloud, consulta Regiones y zonas.

Desplegar el servicio on-premise simulado

En esta sección se describe cómo desplegar un grupo de endpoints de red (NEG) de conectividad híbrida. En una implementación de producción, este NEG contendría un endpoint (IP:port) que se resuelve en tu servidor local. En este ejemplo, crearás una VM de Compute Engine a la que se puede acceder a través de un IP:port. Esta máquina virtual actúa como tu servidor local simulado.

Crear la VM local simulada

Despliega 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'

Identifica y almacena su dirección IP interna para futuras configuraciones y verificaciones. El servidor de esta VM recibe 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 especificando el non-gcp-private-ip-porttipo de endpoint de red. Añade la dirección IP y el puerto de tu VM local simulada como endpoint a este NEG. Siguiendo el paso anterior, la dirección IP se almacena en la variable de entorno ON_PREM_IP.

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

Añade IP:port a tu nuevo NEG:

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

Configurar Cloud Service Mesh con componentes de Cloud Load Balancing

En esta sección se muestra cómo configurar Cloud Service Mesh y habilitar tu proxy intermedio para que reenvíe el tráfico a tu servicio privado on-premise. Configura los siguientes componentes:

Una comprobación del estado. Esta comprobación del estado se comporta de forma ligeramente diferente a las comprobaciones del estado configuradas para otros tipos de NEG.
Un servicio de backend. Para obtener más información, consulta la descripción general de los servicios backend.
Un mapa de reglas de enrutamiento. Este paso incluye la creación de una regla de reenvío, un proxy de destino y un mapa de URLs. Para obtener más información, consulta Mapas de reglas de enrutamiento.

Crear la comprobación del estado

Las comprobaciones de estado verifican que tus endpoints estén en buen estado y puedan recibir solicitudes. La comprobación del estado de este tipo de NEG se basa en el mecanismo de comprobación del estado distribuido de Envoy.

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

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

Crea el servicio de backend

Crea un servicio de backend con el esquema de balanceo de carga INTERNAL_SELF_MANAGED para usarlo con Cloud Service Mesh. Cuando crees este servicio backend, especifica la comprobación del estado que has creado anteriormente:
```
gcloud compute backend-services create td-on-prem-backend-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --health-checks=td-on-prem-health-check
```

Añade el NEG que has creado anteriormente como 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

Crear el mapa de reglas de enrutamiento

El mapa de reglas de enrutamiento define cómo enruta Cloud Service Mesh el tráfico a tu servicio de backend.

Crea un mapa de URLs que use el servicio de backend definido anteriormente:

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

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

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

Usa el comando import para crear el proxy HTTP de destino (para obtener más información, consulta Proxies de destino de Cloud Service Mesh):
```
gcloud compute target-http-proxies import td-hybrid-proxy \
    --source=target_proxy.yaml
```
Crea una regla de reenvío que haga referencia a este proxy HTTP de destino. Asigna la dirección IP 0.0.0.0 a la regla de reenvío. Si se define la dirección IP de la regla como 0.0.0.0, el tráfico se enruta en función del puerto de entrada, el nombre de host HTTP y la información de la ruta configurados en el mapa de URLs. 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

Cloud Service Mesh ahora está configurado para enrutar el tráfico a través del proxy intermedio a tu servicio privado y local simulado. Para verificar esta configuración, cree una VM de cliente de prueba, inicie sesión en ella y envíe una solicitud al proxy intermedio que ejecuta Envoy. Después de verificar la configuración, elimina la VM del cliente de prueba.

Obtén la dirección IP del proxy intermedio. Solo necesitas esta información para el paso de verificación:
```
gcloud compute instances list
```
Anota la dirección IP de la instancia en el td-middle-proxy-us-central1-a MIG.

Crea una instancia de cliente de prueba:

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

Usa ssh para iniciar sesión en el cliente de prueba:

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

Envía una solicitud a la VM del proxy intermedio. Sustituye la dirección IP que has obtenido anteriormente por MIDDLE_PROXY_IP:
```
curl $MIDDLE_PROXY_IP:8080
```
Deberías ver este resultado:
```
Hello world from on-premises!
```
Sal de la VM del cliente de prueba. Después de salir, puedes eliminar la VM:
```
gcloud compute instances delete test-client \
    --zone=us-central1-a
```

Implementar el balanceador de carga de aplicación externo

En esta sección, desplegarás un balanceador de carga de aplicación externo que enviará el tráfico entrante al proxy intermedio. Esta implementación es una configuración estándar de balanceador de carga de aplicación 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. Esta dirección IP externa se obtiene durante el paso de verificación que se explica más adelante en este tutorial.

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

Configurar el balanceador de carga HTTP externo

Configura el balanceador de carga externo para que enrute el tráfico de los clientes de Internet a tu proxy intermedio ya configurado.

Crea una comprobación del 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
```

Crea una regla de cortafuegos para permitir que se realicen comprobaciones del estado. Vuelve a usar la etiqueta allow-hc para aplicar la regla de cortafuegos a las VMs proxy intermedias:

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

Crea un servicio de backend:

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

Añade el MIG de 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

Crea un mapa de URLs para enrutar las solicitudes entrantes al proxy intermedio como servicio de backend predeterminado:
```
gcloud compute url-maps create lb-map-http \
    --default-service=td-middle-proxy-backend-service
```
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 carga externo se gestionen según el mapa de URLs:
```
gcloud compute target-http-proxies create http-lb-proxy \
    --url-map=lb-map-http
```

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

Definir el puerto con nombre del MIG

Define un puerto con nombre para el grupo de instancias para permitir que tu proxy intermedio reciba tráfico HTTP del balanceador de carga externo:

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

Verificar la configuración del balanceador de carga de aplicación externo

En este paso, verificará que el balanceador de carga externo esté configurado correctamente.

Deberías poder enviar una solicitud a la IP virtual del balanceador de carga y obtener una respuesta de la VM local simulada:
```
PUBLIC_VIP=gcloud compute addresses describe external-lb-vip \
    --format="get(address)" \
    --global
```
Envía una solicitud curl a la dirección IP externa (PUBLIC_VIP) y comprueba que recibes el mensaje Hello world:
```
curl $PUBLIC_VIP
```
Verás el siguiente resultado:
```
Hello world from on-premises!
```

Habilitar Cloud Armor

Configura las políticas de seguridad de Cloud Armor para que solo permitan el acceso a tu servicio desde CLIENT_IP_RANGE, que debe incluir la dirección IP externa del dispositivo cliente con el que quieras hacer la prueba (por ejemplo, "192.0.2.0/24").

Estas políticas se aplican en el servicio de backend del balanceador de carga externo (en este ejemplo, td-hybrid-backend-service apunta al proxy intermedio). Para obtener más información sobre los permisos necesarios para definir estas reglas, consulta el artículo Configurar políticas de seguridad de Cloud Armor.

Crea la política de seguridad de Cloud Armor:

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

Actualiza la regla predeterminada de la política de seguridad para denegar todo el tráfico:

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

Añade una regla de mayor prioridad para permitir el tráfico de un intervalo de IPs 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"

Adjunta las políticas de seguridad de Cloud Armor a tu servicio de backend:

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

Verificación final

Envía una solicitud curl a la dirección IP virtual pública del balanceador de carga de aplicación externo. Si la dirección IP del dispositivo cliente está dentro del intervalo permitido CLIENT_IP_RANGE especificado anteriormente, deberías recibir la respuesta esperada.
```
curl $PUBLIC_VIP
```
Verás el siguiente resultado:
```
Hello world from on-premises!
```
Envía la misma solicitud curl desde un dispositivo cliente diferente cuya dirección IP no esté incluida en CLIENT_IP_RANGE o actualiza la regla de tu política de seguridad para que no incluya la dirección IP de tu cliente. Ahora deberías recibir un error 404 Not Found.

Solución de problemas

En las siguientes instrucciones se describe cómo solucionar problemas con la configuración.

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

Si tu servicio local ya es accesible en lasGoogle Cloud VMs en las que se ejecutan los Envoys, sigue estos pasos para solucionar los problemas de tu configuración:

Asegúrate de que el Google Cloud MIG de Envoy se indica como correcto. En la Google Cloud consola, ve a Servicios de red > Balanceo de carga y haz clic en url-map lb-map-http para ver sus detalles. Deberías ver que 1/1 de la instancia de td-middle-proxy-us-central1-a está en buen estado.
Si no está en buen estado, comprueba si se ha configurado una regla de cortafuegos para permitir el tráfico de comprobación del estado de entrada a las VMs que ejecutan Envoy: Google Cloud
```
gcloud compute firewall-rules describe fw-allow-health-check
```
Deberías ver este resultado:
```
allowed:
‑ IPProtocol: tcp
...
direction: INGRESS
disabled: false
...
...
sourceRanges:
‑ 130.211.0.0/22
‑ 35.191.0.0/16
targetTags:
‑ allow-hc
```

Siguientes pasos

Para encontrar políticas de enrutamiento más complejas para tus servicios locales o multicloud, consulta las funciones avanzadas de gestión del tráfico de Cloud Service Mesh.
Para implementar Cloud Service Mesh, consulta la información general de la guía de configuración.
Para habilitar servicios de red perimetral adicionales, consulta las siguientes guías:
- Habilitar IAP para Compute Engine
- Configurar Cloud CDN con un grupo de instancias gestionado