1. Introduction
Les routes personnalisées statiques influencent le comportement de routage par défaut dans un VPC. Les routes personnalisées IPv6 sont désormais compatibles avec de nouveaux attributs de saut suivant: next-hop-gateway, next-hop-instance et next-hop-address. Cet atelier de programmation explique comment utiliser des routes personnalisées IPv6 avec ces nouvelles options de saut suivant à l'aide de deux VPC connectés par une instance de VM à plusieurs cartes d'interface réseau. Vous allez également montrer comment mélanger les adresses ULA et GUA, et comment assurer la connectivité du VPC ULA à l'Internet public à l'aide de la nouvelle fonctionnalité de route personnalisée.
Points abordés
- Créer une route IPv6 personnalisée avec un saut suivant next-hop-ilb en spécifiant le nom de l'ILB
- Créer une route IPv6 personnalisée avec un saut suivant "next-hop-ilb" en spécifiant l'adresse IPv6 de l'ILB
Prérequis
- Projet Google Cloud
2. Avant de commencer
Mettre à jour le projet pour qu'il prenne en charge l'atelier de programmation
Cet atelier de programmation utilise des $variables pour faciliter l'implémentation de la configuration gcloud dans Cloud Shell.
Dans Cloud Shell, procédez comme suit :
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
export projectname=$(gcloud config list --format="value(core.project)")
Architecture globale de l'atelier
Pour illustrer les deux types de sauts suivants de route personnalisée, vous allez créer deux VPC: un VPC client et un VPC serveur qui utilisent l'adressage ULA.
Pour que le VPC client puisse accéder au serveur, vous devez utiliser une route personnalisée avec next-hop-ilb pointant vers un ILB (à l'aide du nom de l'ILB) devant un groupe d'instances de passerelle multi-NIC prises en sandwich entre deux ILB. Pour fournir un routage vers l'instance cliente (après avoir supprimé la route ::/0 par défaut), vous utiliserez une route personnalisée avec next-hop-ilb (à l'aide de l'adresse de l'ILB) pointant vers l'ILB.
3. Configuration du VPC client
Créer le VPC client
Dans Cloud Shell, procédez comme suit:
gcloud compute networks create client-vpc \
--project=$projectname \
--subnet-mode=custom --mtu=1500 \
--bgp-routing-mode=regional \
--enable-ula-internal-ipv6
Créer le sous-réseau client
Dans Cloud Shell, procédez comme suit:
gcloud compute networks subnets create client-subnet \
--network=client-vpc \
--project=$projectname \
--range=192.168.1.0/24 \
--stack-type=IPV4_IPV6 \
--ipv6-access-type=internal \
--region=us-central1
Enregistrez le sous-réseau IPv6 attribué dans une variable d'environnement à l'aide de cette commande
export client_subnet=$(gcloud compute networks subnets \
describe client-subnet \
--project $projectname \
--format="value(internalIpv6Prefix)" \
--region us-central1)
Lancer l'instance cliente
Dans Cloud Shell, procédez comme suit:
gcloud compute instances create client-instance \
--subnet client-subnet \
--stack-type IPV4_IPV6 \
--zone us-central1-a \
--project=$projectname
Ajouter une règle de pare-feu pour le trafic VPC client
Dans Cloud Shell, procédez comme suit:
gcloud compute firewall-rules create allow-gateway-client \
--direction=INGRESS --priority=1000 \
--network=client-vpc --action=ALLOW \
--rules=tcp --source-ranges=$client_subnet \
--project=$projectname
Ajouter une règle de pare-feu pour autoriser l'IAP pour l'instance cliente
Dans Cloud Shell, procédez comme suit:
gcloud compute firewall-rules create allow-iap-client \
--direction=INGRESS --priority=1000 \
--network=client-vpc --action=ALLOW \
--rules=tcp:22 --source-ranges=35.235.240.0/20 \
--project=$projectname
Confirmer l'accès SSH à l'instance cliente
Dans Cloud Shell, connectez-vous à l'instance cliente:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Si l'opération réussit, une fenêtre de terminal s'affiche à partir de l'instance cliente. Quittez la session SSH pour continuer l'atelier de programmation.
4. Configuration du VPC du serveur
Créer le VPC du serveur
Dans Cloud Shell, procédez comme suit:
gcloud compute networks create server-vpc \
--project=$projectname \
--subnet-mode=custom --mtu=1500 \
--bgp-routing-mode=regional \
--enable-ula-internal-ipv6
Créer les sous-réseaux de serveurs
Dans Cloud Shell, procédez comme suit:
gcloud compute networks subnets create server-subnet \
--network=server-vpc \
--project=$projectname \
--range=192.168.0.0/24 \
--stack-type=IPV4_IPV6 \
--ipv6-access-type=internal \
--region=us-central1
Enregistrez le sous-réseau attribué dans une variable d'environnement à l'aide de cette commande :
export server_subnet=$(gcloud compute networks subnets \
describe server-subnet \
--project $projectname \
--format="value(internalIpv6Prefix)" \
--region us-central1)
Lancer la VM serveur
Dans Cloud Shell, procédez comme suit:
gcloud compute instances create server-instance \
--subnet server-subnet \
--stack-type IPV4_IPV6 \
--zone us-central1-a \
--project=$projectname
Ajouter une règle de pare-feu pour autoriser l'accès au serveur depuis le client
Dans Cloud Shell, procédez comme suit:
gcloud compute firewall-rules create allow-client-server \
--direction=INGRESS --priority=1000 \
--network=server-vpc --action=ALLOW \
--rules=tcp --source-ranges=$client_subnet \
--project=$projectname
Ajouter une règle de pare-feu pour autoriser les IAP
Dans Cloud Shell, procédez comme suit:
gcloud compute firewall-rules create allow-iap-server \
--direction=INGRESS --priority=1000 \
--network=server-vpc --action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20 \
--project=$projectname
Installer Apache dans l'instance de serveur ULA
Dans Cloud Shell, connectez-vous à l'instance cliente:
gcloud compute ssh server-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Dans le shell de la VM serveur, exécutez la commande suivante :
sudo apt update && sudo apt -y install apache2
Vérifier qu'Apache est en cours d'exécution
sudo systemctl status apache2
Écraser la page Web par défaut
echo '<!doctype html><html><body><h1>Hello World! From Server Instance!</h1></body></html>' | sudo tee /var/www/html/index.html
Quittez la session SSH pour continuer l'atelier de programmation.
5. Créer des instances de passerelle
Créer un modèle d'instance de passerelle à plusieurs cartes d'interface réseau
Dans Cloud Shell, procédez comme suit:
gcloud compute instance-templates create gateway-instance-template \
--project=$projectname \
--instance-template-region=us-central1 \
--region=us-central1 \
--network-interface=stack-type=IPV4_IPV6,subnet=client-subnet,no-address \
--network-interface=stack-type=IPV4_IPV6,subnet=server-subnet,no-address \
--can-ip-forward \
--metadata=startup-script='#! /bin/bash
sudo sysctl -w net.ipv6.conf.ens4.accept_ra=2
sudo sysctl -w net.ipv6.conf.ens5.accept_ra=2
sudo sysctl -w net.ipv6.conf.ens4.accept_ra_defrtr=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1'
Créer un groupe d'instances de passerelle à plusieurs NIC
Dans Cloud Shell, procédez comme suit:
gcloud compute instance-groups managed create gateway-instance-group \
--project=$projectname \
--base-instance-name=gateway-instance \
--template=projects/$projectname/regions/us-central1/instanceTemplates/gateway-instance-template \
--size=2 \
--zone=us-central1-a
Vérifier les instances de passerelle
Pour vous assurer que notre script de démarrage a été transmis correctement et que la table de routage v6 est correcte. Se connecter en SSH à l'une des instances de passerelle
Dans Cloud Shell, listez les instances de passerelle en exécutant la commande suivante:
gcloud compute instances list \
--project=$projectname \
--zones=us-central1-a \
--filter name~gateway \
--format 'csv(name)'
Notez l'un des noms d'instance et utilisez-le dans la commande suivante pour vous y connecter en SSH.
Dans Cloud Shell, connectez-vous à l'une des instances de passerelle.
gcloud compute ssh gateway-instance-<suffix> \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Dans le shell de la VM de la passerelle, exécutez la commande suivante pour vérifier le transfert IPv6 :
sudo sysctl net.ipv6.conf.all.forwarding
La commande doit renvoyer la valeur "1", ce qui indique que le transfert IPv6 est activé.
Vérifier la table de routage IPv6 sur l'instance
ip -6 route show
Exemple de sortie affichant à la fois les routes de sous-réseau ULA et GUA, avec la route par défaut pointant vers l'interface GUA.
::1 dev lo proto kernel metric 256 pref medium
2600:1900:4000:7a7f:0:1:: dev ens4 proto kernel metric 256 expires 83903sec pref medium
2600:1900:4000:7a7f::/65 via fe80::4001:c0ff:fea8:101 dev ens4 proto ra metric 1024 expires 88sec pref medium
fd20:3df:8d5c::1:0:0 dev ens5 proto kernel metric 256 expires 83904sec pref medium
fd20:3df:8d5c::/64 via fe80::4001:c0ff:fea8:1 dev ens5 proto ra metric 1024 expires 84sec pref medium
fe80::/64 dev ens5 proto kernel metric 256 pref medium
fe80::/64 dev ens4 proto kernel metric 256 pref medium
default via fe80::4001:c0ff:fea8:101 dev ens4 proto ra metric 1024 expires 88sec pref medium
Quittez la session SSH pour continuer l'atelier de programmation.
6. Créer des composants d'équilibreur de charge
Avant de pouvoir créer des routes dans les deux VPC, nous devons créer des équilibreurs de charge passthrough internes de chaque côté des instances de passerelle pour transférer le trafic.
Les équilibreurs de charge créés dans cet atelier de programmation se composent des éléments suivants :
- Vérification de l'état: dans cet atelier de programmation, nous allons créer des vérifications d'état simples qui ciblent le port 22. Notez que les vérifications de l'état ne fonctionneront pas comme prévu (cela impliquerait d'ajouter des règles de pare-feu pour autoriser les vérifications de l'état et créer des routes spéciales sur les instances de passerelle). Étant donné que cet atelier de programmation est axé sur le transfert IPv6, nous allons nous appuyer sur le comportement de distribution du trafic par défaut des équilibreurs de charge passthrough internes lorsque tous les backends ne sont pas opérationnels, c'est-à-dire que nous allons transférer le trafic vers tous les backends en dernier recours.
- Service de backend: nous utiliserons le protocole TCP pour le service de backend. Toutefois, comme les équilibreurs de charge sont créés à des fins de routage, tous les protocoles sont transférés, quel que soit le protocole du service de backend.
- Règle de transfert: nous créons une règle de transfert par VPC .
- Adresse IPv6 interne: dans cet atelier de programmation, nous allons laisser la règle de transfert allouer automatiquement des adresses IPv6 à partir du sous-réseau.
Créer une vérification d'état
Dans Cloud Shell, procédez comme suit:
gcloud compute health-checks create tcp tcp-hc-22 \
--project=$projectname \
--region=us-central1 \
--port=22
Créer des services de backend
Dans Cloud Shell, procédez comme suit:
gcloud compute backend-services create bes-ilb-clientvpc \
--project=$projectname \
--load-balancing-scheme=internal \
--protocol=tcp \
--network=client-vpc \
--region=us-central1 \
--health-checks=tcp-hc-22 \
--health-checks-region=us-central1
gcloud compute backend-services create bes-ilb-servervpc \
--project=$projectname \
--load-balancing-scheme=internal \
--protocol=tcp \
--network=server-vpc \
--region=us-central1 \
--health-checks=tcp-hc-22 \
--health-checks-region=us-central1
Ajouter un groupe d'instances au service de backend
Dans Cloud Shell, procédez comme suit:
gcloud compute backend-services add-backend bes-ilb-clientvpc \
--project=$projectname \
--region=us-central1 \
--instance-group=gateway-instance-group \
--instance-group-zone=us-central1-a
gcloud compute backend-services add-backend bes-ilb-servervpc \
--project=$projectname \
--region=us-central1 \
--instance-group=gateway-instance-group \
--instance-group-zone=us-central1-a
Créer des règles de transfert
Dans Cloud Shell, procédez comme suit:
gcloud compute forwarding-rules create fr-ilb-clientvpc \
--project=$projectname \
--region=us-central1 \
--load-balancing-scheme=internal \
--network=client-vpc \
--subnet=client-subnet \
--ip-protocol=TCP \
--ip-version=IPV6 \
--ports=ALL \
--backend-service=bes-ilb-clientvpc \
--backend-service-region=us-central1
gcloud compute forwarding-rules create fr-ilb-servervpc \
--project=$projectname \
--region=us-central1 \
--load-balancing-scheme=internal \
--network=server-vpc \
--subnet=server-subnet \
--ip-protocol=TCP \
--ip-version=IPV6 \
--ports=ALL \
--backend-service=bes-ilb-servervpc \
--backend-service-region=us-central1
Enregistrez les adresses IPv6 des deux règles de transfert en exécutant les commandes suivantes dans Cloudshell:
export fraddress_client=$(gcloud compute forwarding-rules \
describe fr-ilb-clientvpc \
--project $projectname \
--format="value(IPAddress)" \
--region us-central1)
export fraddress_server=$(gcloud compute forwarding-rules \
describe fr-ilb-servervpc \
--project $projectname \
--format="value(IPAddress)" \
--region us-central1)
7. Créer et tester des routes vers des équilibreurs de charge (à l'aide de l'adresse de l'équilibreur de charge)
Dans cette section, vous allez ajouter des routes aux VPC client et serveur en utilisant les adresses IPv6 des équilibreurs de charge comme sauts suivants.
Notez les adresses des serveurs
Dans Cloud Shell, procédez comme suit:
gcloud compute instances list \
--project $projectname \
--zones us-central1-a \
--filter="name~server-instance" \
--format='value[separator=","](name,networkInterfaces[0].ipv6Address)'
Les noms des instances de serveur et leurs préfixes IPv6 devraient s'afficher. Exemple de résultat
server-instance,fd20:3df:8d5c:0:0:0:0:0
Notez l'adresse du serveur, car vous l'utiliserez plus tard dans les commandes curl à partir de l'instance cliente. Malheureusement, les variables d'environnement ne peuvent pas être facilement utilisées pour les stocker, car elles ne sont pas transférées via les sessions SSH.
Exécuter la commande curl du client vers l'instance de serveur ULA
Pour voir le comportement avant d'ajouter des itinéraires. Exécutez une commande curl à partir de l'instance cliente vers l'instance de serveur 1.
Dans Cloud Shell, connectez-vous à l'instance cliente:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Dans l'instance cliente, effectuez une requête curl à l'aide de l'adresse IPv6 ULA de l'instance server1 (la commande définit un délai avant expiration court de 5 s pour éviter que curl n'attende trop longtemps)
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Cette commande curl doit expirer, car le VPC client ne dispose pas encore d'une route vers le VPC du serveur.
Essayons de résoudre ce problème. Quittez la session SSH pour le moment.
Ajouter une route personnalisée dans le VPC client
Étant donné qu'il manque une route vers le préfixe ULA dans le VPC client. Ajoutons-le maintenant en créant une route qui pointe vers l'ILB côté client par adresse.
Remarque: Les adresses /96 sont attribuées aux équilibreurs de charge passthrough internes IPv6. Vous devez supprimer le masque /96 de l'adresse avant de la transmettre à la commande suivante. (ci-dessous, la substitution in situ de bash est utilisée)
Dans Cloud Shell, procédez comme suit:
gcloud compute routes create client-to-server-route \
--project=$projectname \
--destination-range=$server_subnet \
--network=client-vpc \
--next-hop-ilb=${fraddress_client//\/96}
Revenez à l'instance cliente via SSH:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Dans l'instance cliente, réessayez d'exécuter la requête curl vers l'instance de serveur. (la commande définit un délai avant expiration court de 5 s pour éviter que curl attende trop longtemps)
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Cette commande curl expire toujours, car le VPC du serveur n'a pas encore de route vers le VPC client via l'instance de passerelle.
Quittez la session SSH pour continuer l'atelier de programmation.
Ajouter une route personnalisée dans un VPC de serveur
Dans Cloud Shell, procédez comme suit:
gcloud compute routes create server-to-client-route \
--project=$projectname \
--destination-range=$client_subnet \
--network=server-vpc \
--next-hop-ilb=${fraddress_server//\/96}
Revenez à l'instance cliente via SSH:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Dans l'instance cliente, essayez à nouveau d'exécuter la requête curl vers l'instance de serveur.
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Cette commande curl réussit désormais, ce qui indique que vous disposez d'une connectivité de bout en bout de l'instance cliente à l'instance de serveur ULA. Cette connectivité n'est désormais possible que par l'utilisation de routes personnalisées IPv6 avec next-hop-ilb comme saut suivant.
Exemple de résultat
<user id>@client-instance:~$ curl -m 5.0 -g -6 'http://[fd20:3df:8d5c:0:0:0:0:0]:80/'
<!doctype html><html><body><h1>Hello World! From Server Instance!</h1></body></html>
Quittez la session SSH pour continuer l'atelier de programmation.
8. Créer et tester des routes vers des équilibreurs de charge (à l'aide du nom de l'équilibreur de charge)
Vous pouvez également utiliser next-hop-ilb pour référencer le nom de l'équilibreur de charge au lieu de son adresse IPv6. Dans cette section, nous allons passer en revue la procédure à suivre et vérifier que la connectivité est toujours établie entre le client et le serveur.
Supprimer des routes précédentes
Restaurons l'environnement tel qu'il était avant l'ajout de routes personnalisées en supprimant les routes personnalisées qui utilisent le nom de l'instance.
Dans Cloud Shell, procédez comme suit:
gcloud compute routes delete client-to-server-route --quiet --project=$projectname
gcloud compute routes delete server-to-client-route --quiet --project=$projectname
Exécuter la commande curl du client vers l'instance de serveur ULA
Pour vérifier que les routes précédentes ont bien été supprimées, exécutez une commande curl à partir de l'instance cliente vers l'instance de serveur1.
Dans Cloud Shell, connectez-vous à l'instance cliente:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Dans l'instance cliente, effectuez une requête curl à l'aide de l'adresse IPv6 ULA de l'instance server1 (la commande définit un délai avant expiration court de 5 s pour éviter que curl n'attende trop longtemps)
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Cette commande curl doit expirer, car le VPC client n'a plus de route vers le VPC du serveur.
Ajouter des routes personnalisées dans les VPC client et serveur
Remettons les routes personnalisées dans les VPC client et serveur, mais au lieu d'utiliser l'adresse de l'équilibreur de charge, nous utiliserons son nom et sa région dans la commande.
Dans Cloud Shell, procédez comme suit:
gcloud compute routes create client-to-server-route \
--project=$projectname \
--destination-range=$server_subnet \
--network=client-vpc \
--next-hop-ilb=fr-ilb-clientvpc \
--next-hop-ilb-region=us-central1
gcloud compute routes create server-to-client-route \
--project=$projectname \
--destination-range=$client_subnet \
--network=server-vpc \
--next-hop-ilb=fr-ilb-servervpc \
--next-hop-ilb-region=us-central1
Revenez à l'instance cliente via SSH:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Dans l'instance cliente, réessayez d'exécuter la requête curl vers l'instance de serveur. (la commande définit un délai avant expiration court de 5 s pour éviter que curl attende trop longtemps)
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Cette commande curl réussit maintenant, ce qui indique que vous avez une connectivité de bout en bout de l'instance cliente à l'instance de serveur ULA.
9. Effectuer un nettoyage
Nettoyer les routes personnalisées
Dans Cloud Shell, procédez comme suit:
gcloud compute routes delete client-to-server-route --quiet --project=$projectname
gcloud compute routes delete server-to-client-route --quiet --project=$projectname
Nettoyer les composants LB
Dans Cloud Shell, procédez comme suit:
gcloud compute forwarding-rules delete fr-ilb-clientvpc --region us-central1 --quiet --project=$projectname
gcloud compute forwarding-rules delete fr-ilb-servervpc --region us-central1 --quiet --project=$projectname
gcloud compute backend-services delete bes-ilb-clientvpc --region us-central1 --quiet --project=$projectname
gcloud compute backend-services delete bes-ilb-servervpc --region us-central1 --quiet --project=$projectname
gcloud compute health-checks delete tcp-hc-22 --region us-central1 --quiet --project=$projectname
Nettoyer les instances et le modèle d'instance
Dans Cloud Shell, procédez comme suit:
gcloud compute instances delete client-instance --zone us-central1-a --quiet --project=$projectname
gcloud compute instances delete server-instance --zone us-central1-a --quiet --project=$projectname
gcloud compute instance-groups managed delete gateway-instance-group --zone us-central1-a --quiet --project=$projectname
gcloud compute instance-templates delete gateway-instance-template --region us-central1 --quiet --project=$projectname
Nettoyer les sous-réseaux
Dans Cloud Shell, procédez comme suit:
gcloud compute networks subnets delete client-subnet --region=us-central1 --quiet --project=$projectname
gcloud compute networks subnets delete server-subnet --region=us-central1 --quiet --project=$projectname
Nettoyer les règles de pare-feu
Dans Cloud Shell, procédez comme suit:
gcloud compute firewall-rules delete allow-iap-client --quiet --project=$projectname
gcloud compute firewall-rules delete allow-iap-server --quiet --project=$projectname
gcloud compute firewall-rules delete allow-gateway-client --quiet --project=$projectname
gcloud compute firewall-rules delete allow-client-server --quiet --project=$projectname
Nettoyer les VPC
Dans Cloud Shell, procédez comme suit:
gcloud compute networks delete client-vpc --quiet --project=$projectname
gcloud compute networks delete server-vpc --quiet --project=$projectname
10. Félicitations
Vous avez correctement utilisé des routes IPv6 statiques personnalisées avec des sauts suivants définis sur next-hop-ilb. Vous avez également validé la communication IPv6 de bout en bout à l'aide de ces routes.
Étape suivante
Découvrez quelques-uns des ateliers de programmation...
- Accéder aux API Google à partir d'hôtes sur site à l'aide d'adresses IPv6
- Options d'adressage IPv4 et IPv6
- Utiliser l'instance, l'adresse et la passerelle de saut suivant des routes statiques IPv6