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

Se usó la API de Cloud Translation para traducir esta página.

Configura servicios perimetrales de red con grupos de extremos de red de conectividad híbrida

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
Reducir 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 los 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 de perímetro de red. — Ejemplo de servicios perimetrales de la red (haz clic para agrandar)

Para llevar estos beneficios a tus servicios privados, locales o de múltiples nubes, implementas un balanceador de cargas de aplicaciones externo para recibir tráfico del público a Internet. El balanceador de cargas 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 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:

Implementa Envoy como un proxy intermedio en un grupo de instancias administrado (MIG). Este proxy de Envoy se conecta automáticamente a Cloud Service Mesh.
Crea una instancia de máquina virtual (VM) local privada y simulada. En un ejemplo real, es probable que ya tengas una VM local.
Configura Cloud Service Mesh para enrutar todas las solicitudes que llegan al proxy central a la VM local simulada
Crea un balanceador de cargas de aplicaciones externo para recibir tráfico de la Internet pública y reenviarlo al proxy medio.
Conectar 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:

Revisión Prepárate para configurar Cloud Service Mesh con Envoy y completar todas las tareas de requisitos previos, como otorgar permisos y roles, y habilitar la API de Cloud Service Mesh.
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 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).

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

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
```

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

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'

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.

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

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 Cloud Service Mesh con los componentes de Cloud Load Balancing

En esta sección, se muestra cómo configurar la malla de servicios de Cloud 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

Crea el servicio de backend.

Crea un servicio de backend con el balanceo de cargas de INTERNAL_SELF_MANAGED del esquema que se usará con Cloud Service Mesh. 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
```

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 Cloud Service Mesh enruta el tráfico a tu servicio de backend.

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

Crea un archivo 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 para 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. 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
```

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

La malla de servicios de Cloud está configurada 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.

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

Crea una instancia de cliente de prueba:

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

Usa ssh para acceder al cliente de prueba:

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

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!
```
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 tráfico entrante al proxy intermedio. Esta es una configuración estándar del balanceador de cargas de aplicaciones 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. 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.

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
```

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

Crea un servicio de backend:

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

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

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
```
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
```

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 de aplicaciones externo

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

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
```
Realiza una solicitud curl a la dirección IP externa (PUBLIC_VIP) 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 que solo puedan acceder a tu servicio desde CLIENT_IP_RANGE, que debe incluir la dirección IP externa 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.

Crea la política de seguridad de Google 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 rechazar todo el tráfico.

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

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"

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

Emitir una solicitud curl a la IP virtual pública del balanceador de cargas de aplicaciones externo web. 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!
```
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

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

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

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

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.
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 VMs de Google Cloud que ejecutan Envoy:
```
gcloud compute firewall-rules describe fw-allow-health-check
```
Deberías 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?

Para 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 Cloud Service Mesh.
Para implementar Cloud Service Mesh, 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