1. Introduction
Un équilibreur de charge proxy TCP interne régional doté d'une connectivité hybride vous permet de mettre un service hébergé sur site ou dans d'autres environnements cloud à la disposition des clients de votre réseau VPC.
Si vous souhaitez rendre le service hybride disponible sur d'autres réseaux VPC, vous pouvez publier le service à l'aide de Private Service Connect. En plaçant un rattachement de service devant votre équilibreur de charge proxy TCP régional interne, vous pouvez permettre aux clients d'autres réseaux VPC d'accéder aux services hybrides exécutés dans des environnements sur site ou dans d'autres environnements cloud.
Objectifs de l'atelier
Dans cet atelier de programmation, vous allez créer un équilibreur de charge proxy TCP interne avec connectivité hybride vers un service sur site à l'aide d'un groupe de points de terminaison du réseau. À partir du client, le VPC peut communiquer avec le service sur site.
Points abordés
- Créer un ILB de proxy TCP avec un service de backend de NEG hybride
- Établir un producteur Private Service Connect (rattachement de service) et un client (règle de transfert)
- Comment tester et valider la communication entre le service client et le producteur
Prérequis
- Mise en réseau hybride établie, par exemple VPN haute disponibilité, interconnexion, SW-WAN
- Projet Google Cloud
Établir une connectivité hybride
Vos environnements Google Cloud et sur site ou d'autres clouds doivent être connectés via une connectivité hybride, à l'aide de rattachements de VLAN Cloud Interconnect ou de tunnels Cloud VPN avec Cloud Router. Nous vous recommandons d'utiliser une connexion à haute disponibilité.
Un routeur Cloud Router activé avec le routage dynamique global apprend le point de terminaison spécifique via BGP et le programme dans votre réseau VPC Google Cloud. Le routage dynamique régional n'est pas disponible. De même, les routes statiques ne sont pas prises en charge.
Le réseau VPC Google Cloud que vous utilisez pour configurer Cloud Interconnect ou Cloud VPN est le même réseau que celui que vous utilisez pour configurer le déploiement de l'équilibrage de charge hybride. Assurez-vous que les plages CIDR de sous-réseau de votre réseau VPC n'entrent pas en conflit avec vos plages CIDR distantes. Lorsque les adresses IP se chevauchent, les routes de sous-réseau sont prioritaires sur la connectivité à distance.
Pour savoir comment procéder, consultez les articles suivants :
Annonces de routage personnalisées
Les sous-réseaux ci-dessous exigent des annonces personnalisées de Cloud Router vers le réseau sur site pour garantir la mise à jour des règles de pare-feu sur site.
Sous-réseau | Description |
172.16.0.0/23 | Sous-réseau proxy TCP utilisé pour communiquer directement avec le service sur site |
130.211.0.0/22, 35.191.0.0/16 |
2. Avant de commencer
Mettre à jour le projet pour qu'il soit compatible avec l'atelier de programmation
Cet atelier de programmation utilise $variables pour faciliter l'implémentation de la configuration gcloud dans Cloud Shell.
Dans Cloud Shell, effectuez les opérations suivantes :
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab
3. Configuration du producteur
Créer le VPC de producteur
Dans Cloud Shell, effectuez les opérations suivantes :
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
Créer les sous-réseaux du producteur
Dans Cloud Shell, effectuez les opérations suivantes :
gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1
Créer les sous-réseaux du proxy TCP
L'allocation du proxy s'effectue au niveau du VPC, et non au niveau de l'équilibreur de charge. Vous devez créer un sous-réseau proxy réservé dans chaque région d'un réseau virtuel (VPC) dans lequel vous utilisez des équilibreurs de charge basés sur Envoy. Si vous déployez plusieurs équilibreurs de charge dans la même région et le même réseau VPC, ils partagent le même sous-réseau proxy réservé pour l'équilibrage de charge.
- Un client établit une connexion avec l'adresse IP et le port de la règle de transfert de l'équilibreur de charge.
- Chaque proxy écoute l'adresse IP et le port spécifiés par la règle de transfert de l'équilibreur de charge correspondant. L'un des proxys reçoit la connexion réseau du client et y met fin.
- Le proxy établit une connexion à la VM de backend ou au point de terminaison approprié dans un NEG, comme déterminé par le mappage d'URL et les services de backend de l'équilibreur de charge.
Vous devez créer des sous-réseaux proxy réservés, que votre réseau soit en mode automatique ou personnalisé. Un sous-réseau proxy réservé doit fournir au moins 64 adresses IP. Cela correspond à une longueur de préfixe inférieure ou égale à /26. La taille de sous-réseau recommandée est de /23 (512 adresses proxy réservées).
Dans Cloud Shell, effectuez les opérations suivantes :
gcloud compute networks subnets create proxy-subnet-us-central \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=us-central1 \
--network=producer-vpc \
--range=172.16.0.0/23
Créer les sous-réseaux NAT Private Service Connect
Créez un ou plusieurs sous-réseaux dédiés à utiliser avec Private Service Connect. Si vous utilisez la console Google Cloud pour publier un service, vous pouvez créer les sous-réseaux au cours de cette procédure. Créez le sous-réseau dans la même région que l'équilibreur de charge du service. Vous ne pouvez pas convertir un sous-réseau standard en sous-réseau Private Service Connect.
Dans Cloud Shell, effectuez les opérations suivantes :
gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect
Créer les règles de pare-feu du producteur
Configurez des règles de pare-feu pour autoriser le trafic entre les points de terminaison Private Service Connect et le rattachement de service. Dans cet atelier de programmation, vous avez créé une règle de pare-feu d'entrée autorisant le sous-réseau NAT 100.100.10.0/24 à accéder au rattachement de service Private Service Connect (équilibreur de charge interne).
Dans Cloud Shell, effectuez les opérations suivantes :
gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24
Dans Cloud Shell, créez la règle fw-allow-health-check pour autoriser les vérifications de l'état Google Cloud à atteindre le service sur site (service de backend) sur le port TCP 80.
gcloud compute firewall-rules create fw-allow-health-check \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--rules=tcp:80
Créer une règle de pare-feu d'entrée autorisant les services sur site à communiquer avec le sous-réseau proxy sur le port 80
gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=172.16.0.0/23 \
--rules=tcp:80
Configurer le NEG de connectivité hybride
Lorsque vous créez le NEG,utilisez une ZONE qui réduit la distance géographique entre Google Cloud et votre environnement sur site ou un autre environnement cloud. Par exemple, si vous hébergez un service dans un environnement sur site à Francfort, en Allemagne, vous pouvez spécifier la zone Google Cloud europe-west3-a lorsque vous créez le NEG.
De plus, si vous utilisez Cloud Interconnect, la ZONE utilisée pour créer le NEG doit se trouver dans la même région que celle où le rattachement Cloud Interconnect a été configuré.
Pour en savoir plus sur les régions et zones disponibles, consultez la documentation Compute Engine: Régions et zones disponibles.
Dans Cloud Shell, créez un NEG de connectivité hybride à l'aide de la commande gcloud compute network-endpoint-groups create.
gcloud compute network-endpoint-groups create on-prem-service-neg \
--network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
--zone=us-central1-a \
--network=producer-vpc
Dans Cloud Shell, ajoutez le point de terminaison IP:Port sur site au NEG hybride.
gcloud compute network-endpoint-groups update on-prem-service-neg \
--zone=us-central1-a \
--add-endpoint="ip=192.168.1.5,port=80"
Configurer l'équilibreur de charge
Dans les étapes suivantes, vous allez configurer l'équilibreur de charge (règle de transfert) et associer au groupe de points de terminaison du réseau
Dans Cloud Shell, créez la vérification d'état régionale transmise au service sur site.
gcloud compute health-checks create tcp on-prem-service-hc \
--region=us-central1 \
--use-serving-port
Dans Cloud Shell, créez le service de backend pour le backend sur site.
gcloud compute backend-services create on-premise-service-backend \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=TCP \
--region=us-central1 \
--health-checks=on-prem-service-hc \
--health-checks-region=us-central1
Dans Cloud Shell, ajoutez le backend NEG hybride au service de backend. Pour MAX_CONNECTIONS, saisissez le nombre maximal de connexions simultanées que le backend doit gérer.
gcloud compute backend-services add-backend on-premise-service-backend \
--network-endpoint-group=on-prem-service-neg \
--network-endpoint-group-zone=us-central1-a \
--region=us-central1 \
--balancing-mode=CONNECTION \
--max-connections=100
Créer le proxy cible dans Cloud Shell
gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
--backend-service=on-premise-service-backend \
--region=us-central1
Dans Cloud Shell, créez la règle de transfert (ILB).
Créez la règle de transfert à l'aide de la commande gcloud compute forwarding-rules create.
Remplacez FWD_RULE_PORT par un numéro de port unique compris entre 1 et 65535. La règle de transfert ne transfère que les paquets dont le port de destination correspond.
gcloud compute forwarding-rules create tcp-ilb-psc \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=subnet-201 \
--ports=80 \
--region=us-central1 \
--target-tcp-proxy=on-premise-svc-tcpproxy \
--target-tcp-proxy-region=us-central1
Obtenir l'adresse IP de l'équilibreur de charge interne
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2
4. Valider l'équilibreur de charge
Dans la console Cloud, accédez à Services réseau → Équilibrage de charge → Équilibreurs de charge. Notez que le premier NEG est vert, ce qui indique que la vérification de l'état du service sur site a réussi.
Si vous sélectionnez ‘on-premise-service-backend', vous obtenez l'adresse IP du frontal.
5. Afficher les routes apprises sur site
Accédez à Réseau VPC → Routes. Notez que le sous-réseau de service sur site appris 192.168.1.0/27
6. Valider la connectivité au service sur site
À partir du VPC des producteurs, nous allons créer une VM pour tester la connectivité au service sur site. Le rattachement de service sera ensuite le prochain rattachement pour la configuration.
Dans Cloud Shell, créez l'instance de test dans le VPC du producteur.
gcloud compute instances create test-box-us-central1 \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-201 \
--no-address
Pour autoriser IAP à se connecter à vos instances de VM, créez une règle de pare-feu qui:
- S'applique à toutes les instances de VM auxquelles vous souhaitez rendre accessibles à l'aide d'IAP.
- Autorise le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP utilisées par IAP pour le transfert TCP.
Dans Cloud Shell, créez l'instance de test dans le VPC du producteur.
gcloud compute firewall-rules create ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Connectez-vous à test-box-us-central1 à l'aide d'IAP dans Cloud Shell pour valider la connectivité au service sur site en exécutant une commande curl sur l'adresse IP de l'équilibrage de charge. Réessayez en cas d'expiration du délai.
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
Effectuer une requête curl pour valider la connectivité au service sur site. Une fois la validation terminée, quittez la VM pour revenir à l'invite Cloud Shell. Remplacez l'adresse IP de l'équilibreur de charge interne en fonction du résultat identifié aux étapes 3 et 4.
deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
* Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.1.2
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
<
Welcome to my on-premise service!!
7. Créer le rattachement de service Private Service Connect
Dans les étapes suivantes, nous allons créer le rattachement de service, une fois associé à un point de terminaison client. L'accès au service sur site est possible sans qu'il soit nécessaire d'effectuer un appairage de VPC.
Créer le rattachement de service
Dans Cloud Shell, créez le rattachement de service.
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet
Facultatif: Si vous utilisez un VPC partagé, créez le rattachement de service dans le projet de service
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>
Valider le rattachement de service TCP
gcloud compute service-attachments describe service-1 --region us-central1
8. Facultatif: Accédez à Services réseau → Private Service Connect pour afficher le rattachement de service nouvellement créé
Si vous sélectionnez Service-1, vous obtiendrez plus de détails, y compris l'URI du rattachement de service utilisé par le client pour établir une connexion de service privée. Notez l'URI, car vous en aurez besoin lors d'une prochaine étape.
Détails du rattachement de service:projects/<nom du projet>/regions/us-central1/serviceAttachments/service-1
9. Configuration client
Créer le VPC consommateur
Dans Cloud Shell, effectuez les opérations suivantes :
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
Créer les sous-réseaux de client
Dans Cloud Shell, créez le sous-réseau GCE.
gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1
Dans Cloud Shell, créez le sous-réseau du point de terminaison du client.
gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1
Créer le point de terminaison client (règle de transfert)
Dans Cloud Shell, créez l'adresse IP statique qui sera utilisée comme point de terminaison du client.
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
Permet d'utiliser l'URI du rattachement de service généré précédemment pour créer le point de terminaison client
Dans Cloud Shell, créez le point de terminaison du client.
gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1
10. Valider le service client Private Service Connect - VPC du client
À partir du VPC client, vérifiez que la connexion au service privé a bien été établie en accédant à Services réseau → Private Service Connect → Points de terminaison connectés. Notez la connexion psc-consumer-1 établie et l'adresse IP correspondante que nous avons précédemment créées.
Lorsque vous sélectionnez psc-consumer-1, des détails supplémentaires sont fournis, y compris l'URI du rattachement de service
11. Valider le client Private Service Connect - VPC du producteur
À partir du VPC du producteur, vérifiez que la connexion au service privé a bien été établie en accédant à Services réseau → Private Service Connect → Service publié. Notez que la connexion service-1 publiée indique désormais une règle de transfert (point de terminaison de la connexion).
12. Créer une zone DNS privée et Enregistrement A
Créez la zone DNS privée mappée au point de terminaison de connexion PSC pour permettre un accès fluide au producteur depuis n'importe quel hôte du VPC.
Depuis Cloud Shell
gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"
gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"
13. Valider l'accès du client au service Producers à l'aide d'une VM
À partir du VPC "Consumers" (Clients), nous allons créer une VM pour tester la connectivité au service sur site en accédant au point de terminaison du client service1.codelabs.net
Dans Cloud Shell, créez l'instance de test dans le VPC du client.
gcloud compute instances create consumer-vm \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-101 \
--no-address
Pour autoriser IAP à se connecter à vos instances de VM, créez une règle de pare-feu qui:
- S'applique à toutes les instances de VM auxquelles vous souhaitez rendre accessibles à l'aide d'IAP.
- Autorise le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP utilisées par IAP pour le transfert TCP.
Dans Cloud Shell, créez l'instance de test dans le VPC du client.
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Connectez-vous à l'instance consumer-vm à l'aide d'IAP dans Cloud Shell pour valider la connectivité au service sur site en exécutant une commande curl sur le nom de domaine complet du DNS service1.codelab.net. Réessayez en cas d'expiration du délai.
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
Effectuer une requête curl pour valider la connectivité au service sur site. Une fois la sortie validée de la VM, retour à l'invite Cloud Shell
Dans Cloud Shell, exécutez une requête curl
$ curl -v service1.codelab.net
* Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
<
Welcome to my on-premise service!!
Vous trouverez ci-dessous un exemple de capture provenant du service sur site. Notez que l'adresse IP source 172.16.0.2 provient de la plage de sous-réseaux du proxy TCP 172.16.0.0/23.
14. Nettoyage du producteur
Supprimer les composants Producer
Dans Cloud Shell, supprimez les composants du producteur.
gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet
gcloud compute service-attachments delete service-1 --region=us-central1 --quiet
gcloud compute forwarding-rules delete tcp-ilb-psc --region=us-central1 --quiet
gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --region=us-central1 --quiet
gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet
gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet
gcloud compute networks subnets delete psc-nat-subnet subnet-201 proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet
gcloud compute health-checks delete on-prem-service-hc --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
15. Nettoyage consommateur
Supprimer les composants Consumer
Dans Cloud Shell, supprimez les composants client.
gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet
gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet
gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet
gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap-consumer --quiet
gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet
gcloud dns managed-zones delete codelab-zone --quiet
gcloud compute networks delete consumer-vpc --quiet
16. Félicitations
Félicitations, vous avez correctement configuré et validé Private Service Connect avec un proxy TCP.
Vous avez créé l'infrastructure du producteur et ajouté un rattachement de service dans le VPC du producteur pointant vers un service sur site. Vous avez appris comment créer un point de terminaison client dans le VPC client pour permettre la connectivité au service sur site.
Et ensuite ?
Découvrez quelques-uns des ateliers de programmation...
- Utiliser Private Service pour publier et consommer des services avec GKE
- Publier et consommer des services à l'aide de Private Service Connect