Utilisation de l'instance de saut suivant (sans tag et avec tag), de l'adresse de saut suivant et de la passerelle de saut suivant des routes statiques IPv6

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 combiner l'adressage ULA et GUA, et comment rendre le VPC ULA accessible à l'Internet public à l'aide de la nouvelle fonctionnalité de route personnalisée.

Points abordés

• Créer une route personnalisée IPv6 avec un saut suivant next-hop-ilb en spécifiant le nom de l'équilibreur de charge interne
• Créer une route personnalisée IPv6 avec un saut suivant next-hop-ilb en spécifiant l'adresse IPv6 de l'équilibreur de charge interne

Ce dont vous avez besoin

• Projet Google Cloud

2. Avant de commencer

Mettre à jour le projet pour qu'il soit compatible avec 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 routes personnalisées, 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 allez utiliser une route personnalisée avec next-hop-ilb pointant vers un équilibreur de charge interne (à l'aide du nom de l'équilibreur de charge interne) devant un groupe d'instances de passerelle à plusieurs cartes d'interface réseau, qui sont intercalées entre deux équilibreurs de charge internes. Pour fournir un routage vers l'instance cliente (après avoir supprimé la route par défaut ::/0), vous allez utiliser une route personnalisée avec next-hop-ilb (à l'aide de l'adresse de l'équilibreur de charge interne) pointant vers l'équilibreur de charge interne.

3. Configurer le 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 du 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 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. Configurer le VPC serveur

Créer le VPC 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 du serveur

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 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érifiez qu'Apache est en cours d'exécution.

sudo systemctl status apache2

Écrasez 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 cartes d'interface réseau

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 le script de démarrage a été transmis correctement et que la table de routage v6 est correcte, connectez-vous 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 connecter en SSH à l'instance.

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 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érifiez la table de routage IPv6 sur l'instance.

ip -6 route show

Exemple de sortie affichant 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 pour l'équilibreur de charge

Avant de pouvoir créer des routes dans les deux VPC, nous devons créer des équilibreurs de charge passthrough internes des deux côtés des instances de passerelle pour transférer le trafic.

Les équilibreurs de charge créés dans cet atelier de programmation sont composés des éléments suivants :

• Vérification d'état : dans cet atelier de programmation, nous allons créer des vérifications d'état simples ciblant le port 22. Notez que les vérifications d'état ne fonctionneront pas telles qu'elles sont déployées (cela impliquerait d'ajouter des règles de pare-feu pour autoriser les vérifications d'état et de 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 sont non opérationnels, à savoir, transférer vers tous les backends en dernier recours.
• Service de backend : nous allons utiliser le protocole TCP pour le service de backend. Toutefois, étant donné que 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 Cloud Shell :

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.

Noter les adresses du serveur

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 doivent s'afficher. Exemple de sortie

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 de nouvelles routes, 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 ULA IPV6 de l'instance de serveur 1 (la commande définit un délai d'attente court de 5 secondes pour éviter que curl n'attende trop longtemps) :

curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

Remarque : Veillez à utiliser l'équivalent IPv6 de la commande curl :

curl -g -6 ‘http://[ip-address-of-server]:80/'

Exemple : curl -g -6 ‘ http://[fd20:987:cc5e::]:80/*'*

Cette commande curl doit expirer, car le VPC client ne dispose pas encore d'une route vers le VPC 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é que le VPC client ne dispose pas d'une route vers le préfixe ULA, ajoutons-la maintenant en créant une route qui pointe vers l'équilibreur de charge interne côté client par adresse.

Remarque : Les équilibreurs de charge passthrough internes IPv6 se voient attribuer des adresses /96. Il est nécessaire de supprimer le masque /96 de l'adresse avant de la transmettre à la commande suivante. (la substitution bash sur place est utilisée ci-dessous)

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}

Reconnectez-vous en SSH à l'instance cliente :

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Dans l'instance cliente, tentez à nouveau la requête curl vers l'instance de serveur. (la commande définit un délai d'attente court de 5 secondes pour éviter que curl n'attende trop longtemps)

curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

Cette commande curl expire toujours, car le VPC serveur ne dispose pas encore d'une 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 le VPC 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}

Reconnectez-vous en SSH à l'instance cliente :

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Dans l'instance cliente, tentez une dernière fois 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 maintenant, ce qui indique que vous disposez d'une accessibilité de bout en bout depuis l'instance cliente vers l'instance de serveur ULA. Cette connectivité n'est possible que grâce à l'utilisation de routes personnalisées IPv6 avec next-hop-ilb comme sauts suivants.

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 faire référence au nom de l'équilibreur de charge au lieu de son adresse IPv6 dans next-hop-ilb. 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 les routes précédentes

Restaurons l'environnement à l'état antérieur à 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 confirmer 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 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 ULA IPV6 de l'instance de serveur 1 (la commande définit un délai d'attente court de 5 secondes pour éviter que curl n'attende trop longtemps) :

curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

Remarque : Veillez à utiliser l'équivalent IPv6 de la commande curl :

curl -g -6 ‘http://[ip-address-of-server]:80/'

Exemple : curl -g -6 ‘ http://[fd20:987:cc5e::]:80/*'*

Cette commande curl doit expirer, car le VPC client ne dispose plus d'une route vers le VPC serveur.

Ajouter des routes personnalisées dans les VPC client et serveur

Ajoutons à nouveau les routes personnalisées dans les VPC client et serveur, mais au lieu d'utiliser l'adresse de l'équilibreur de charge interne, nous allons utiliser le nom et la région de l'équilibreur de charge interne 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

Reconnectez-vous en SSH à l'instance cliente :

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Dans l'instance cliente, tentez à nouveau la requête curl vers l'instance de serveur. (la commande définit un délai d'attente court de 5 secondes pour éviter que curl n'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 disposez d'une accessibilité de bout en bout depuis l'instance cliente vers 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 de l'équilibreur de charge

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 utilisé des routes IPv6 personnalisées statiques 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 depuis des hôtes sur site à l'aide d'adresses IPv6
• Options d'adressage IP IPv4 et IPv6
• Utiliser l'instance de prochain saut des routes statiques IPv6, l'adresse de prochain saut et la passerelle de prochain saut

Lectures complémentaires et vidéos

• Présentation d'IPv6 sur Google Cloud

Documents de référence

• Compatibilité du protocole IPv6 avec les routes statiques
• Sous-réseaux IPv6