Cette page a été traduite par l'API Cloud Translation.

Créer des instances de VM IPv6 uniquement et activer NAT64/DNS64

1. Introduction

L'un des principaux défis de la migration vers IPv6 consiste à maintenir l'accessibilité aux points de terminaison et aux réseaux IPv4 uniquement. Une technologie de pointe pour relever ce défi consiste à combiner l'utilisation de DNS64 (défini dans RFC6147) pour traduire les enregistrements A en enregistrements AAAA pour les clients, puis à combiner cela avec NAT64 (défini dans RFC6146) pour traduire les adresses IPv6 spécialement formatées en IPv4, où l'adresse IPv4 est intégrée à l'adresse IPv6 spéciale. Cet atelier de programmation guide l'utilisateur dans la configuration des deux fonctionnalités sur un cloud privé virtuel (VPC) Google Cloud Platform (GCP). Lorsqu'ils sont configurés ensemble, GCP NAT64 et DNS64 permettent aux instances IPv6 uniquement de communiquer avec les serveurs IPv4 uniquement sur Internet.

Dans cet atelier, vous allez configurer un VPC avec différents types de sous-réseaux et d'instances IPv6 : GUA (Global Unicast Address) IPv6 uniquement, ULA (Unique Local Address) IPv6 uniquement et ULA à double pile. Vous configurerez et testerez ensuite les services DNS64 et NAT64 gérés de Google Cloud pour accéder aux sites Web IPv4 uniquement.

2. Points abordés

Créer des sous-réseaux et des instances IPv6 uniquement
Découvrez comment activer le service DNS64 géré de Google Cloud pour un VPC .
Comment créer une passerelle Google Cloud NAT configurée pour NAT64
Découvrez comment tester la résolution DNS64 à partir d'instances IPv6 uniquement vers des destinations IPv4 uniquement.
Différences de comportement de DNS64 et NAT64 entre les instances à pile unique et à double pile.
Configurer une passerelle NAT pour NAT64
Découvrez comment tester la connectivité NAT64 entre des instances IPv6 uniquement et des destinations IPv4 uniquement.

3. Avant de commencer

Mettre à jour le projet pour prendre 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-ID]
export projectname=$(gcloud config list --format="value(core.project)")
export zonename=[COMPUTE ZONE NAME]
export regionname=[REGION NAME]

Architecture globale de l'atelier

Pour illustrer l'interaction entre NAT64 et DNS64 avec différents types de sous-réseaux IPv6, vous allez créer un seul VPC avec des sous-réseaux IPv6 dans les versions GUA et ULA. Vous allez également créer un sous-réseau à double pile (à l'aide de l'adressage ULA) pour montrer que DNS64 et NAT64 ne s'appliquent pas aux VM à double pile.

Vous configurerez ensuite DNS64 et NAT64, puis vous testerez la connectivité aux destinations IPv6 et IPv4 sur Internet.

4. Étapes de préparation

Commencez par configurer le compte de service, IAM, l'infrastructure réseau et les instances nécessaires dans votre projet Google Cloud.

Créer un compte de service et des liaisons IAM

Nous allons commencer par créer un compte de service pour permettre aux instances de se connecter les unes aux autres via SSH à l'aide de gcloud. Nous aurons besoin de cette fonctionnalité, car nous ne pouvons pas utiliser IAP pour accéder à l'instance GUA IPv6 uniquement, et Cloud Shell ne permet pas encore l'accès direct à IPv6. Exécutez la ou les commandes suivantes dans Cloud Shell.

gcloud iam service-accounts create ipv6-codelab \
     --description="temporary service account for a codelab" \
     --display-name="ipv6codelabSA" \
     --project $projectname

gcloud projects add-iam-policy-binding  $projectname \
--member=serviceAccount:ipv6-codelab@$projectname.iam.gserviceaccount.com \
--role=roles/compute.instanceAdmin.v1

gcloud iam service-accounts add-iam-policy-binding \
    ipv6-codelab@$projectname.iam.gserviceaccount.com \
--member=serviceAccount:ipv6-codelab@$projectname.iam.gserviceaccount.com \
--role=roles/iam.serviceAccountUser

Créer un VPC et activer l'ULA

Créez un réseau VPC avec un mode de sous-réseau personnalisé et l'IPv6 interne ULA activé en exécutant les commandes suivantes dans Cloud Shell.

gcloud compute networks create ipv6-only-vpc \
--project=$projectname \
--subnet-mode=custom \
--mtu=1500 --bgp-routing-mode=global \
--enable-ula-internal-ipv6

Créer des règles de pare-feu

Créez des règles de pare-feu pour autoriser l'accès SSH. Une règle autorise le protocole SSH à partir de la plage ULA globale (fd20::/20). Deux autres règles autorisent le trafic provenant des plages IPv6 et IPv4 prédéfinies d'IAP (2600:2d00:1:7::/64 et 35.235.240.0/20, respectivement).

Exécutez la ou les commandes suivantes dans Cloud Shell :

gcloud compute firewall-rules create allow-v6-ssh-ula \
--direction=INGRESS --priority=200 \
--network=ipv6-only-vpc --action=ALLOW \
--rules=tcp:22 --source-ranges=fd20::/20 \
--project=$projectname 

gcloud compute firewall-rules create allow-v6-iap \
--direction=INGRESS --priority=300 \
--network=ipv6-only-vpc --action=ALLOW \
--rules=tcp --source-ranges=2600:2d00:1:7::/64 \
--project=$projectname 

gcloud compute firewall-rules create allow-v4-iap \
--direction=INGRESS --priority=300 \
--network=ipv6-only-vpc --action=ALLOW \
--rules=tcp --source-ranges=35.235.240.0/20 \
--project=$projectname

Créer des sous-réseaux

Créez un sous-réseau GUA v6 uniquement, un sous-réseau ULA v6 uniquement et un sous-réseau ULA à double pile. Exécutez la ou les commandes suivantes dans Cloud Shell :

gcloud compute networks subnets create gua-v6only-subnet \
--network=ipv6-only-vpc \
--project=$projectname \
--stack-type=IPV6_ONLY \
--ipv6-access-type=external \
--region=$regionname 

gcloud compute networks subnets create ula-v6only-subnet  \
--network=ipv6-only-vpc \
--project=$projectname \
--stack-type=IPV6_ONLY \
--ipv6-access-type=internal \
--enable-private-ip-google-access \
--region=$regionname

gcloud compute networks subnets create ula-dualstack-subnet  \
--network=ipv6-only-vpc \
--project=$projectname \
--stack-type=IPV4_IPV6 \
--range=10.120.0.0/16 \
--ipv6-access-type=internal \
--region=$regionname

Créer des instances

Créez des instances dans chacun des sous-réseaux que vous venez de créer. L'instance ULA IPv6 uniquement est spécifiée avec la plate-forme cloud pour nous permettre de l'utiliser comme jumpbox vers l'instance GUA IPv6 uniquement. Exécutez la ou les commandes suivantes dans Cloud Shell :

gcloud compute instances create gua-instance \
--subnet gua-v6only-subnet \
--stack-type IPV6_ONLY \
--zone $zonename \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--service-account=ipv6-codelab@$projectname.iam.gserviceaccount.com \
--project=$projectname

gcloud compute instances create ula-instance \
--subnet ula-v6only-subnet \
--stack-type IPV6_ONLY \
--zone $zonename \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--service-account=ipv6-codelab@$projectname.iam.gserviceaccount.com \
--project=$projectname

gcloud compute instances create dualstack-ula-instance \
--subnet ula-dualstack-subnet \
--stack-type IPV4_IPV6 \
--zone $zonename \
--project=$projectname

Accès et configuration initiaux de l'instance

Établissez une connexion SSH à l'instance ULA, qui utilisera IAP par défaut. Utilisez la commande suivante dans Cloud Shell pour vous connecter en SSH à l'instance ULA :

gcloud compute ssh ula-instance --project $projectname --zone $zonename

<username>@ula-instance:~$

Nous utiliserons également l'instance ULA comme jumpbox pour l'instance GUA (car IAP ne fonctionne pas avec les instances GUA et les VM Cloud Shell ne peuvent pas accéder aux destinations IPv6).

Toujours dans l'interface système de l'instance ULA. Essayez de vous connecter en SSH à l'instance GUA à l'aide de la commande gcloud suivante.

La première fois que vous exécutez une commande SSH dans une instance, vous êtes invité à configurer une paire de clés SSH. Appuyez sur Entrée jusqu'à ce que la clé soit créée et que la commande SSH soit exécutée. Cela crée une paire de clés sans phrase secrète.

ula-instance:~$ gcloud compute ssh gua-instance

WARNING: The private SSH key file for gcloud does not exist.
WARNING: The public SSH key file for gcloud does not exist.
WARNING: You do not have an SSH key for gcloud.
WARNING: SSH keygen will be executed to generate a key.
Generating public/private rsa key pair.

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/galhabian/.ssh/google_compute_engine
Your public key has been saved in /home/galhabian/.ssh/google_compute_engine.pub
The key fingerprint is:
SHA256:5PYzydjcpWYiFtzetYCBI6vmy9dqyLsxgDORkB9ynqY galhabian@ula-instance
The key's randomart image is:
+---[RSA 3072]----+
|..               |
|+.o      .       |
|o= o  . + .      |
| o=    * o o     |
|+o.   . S o . o  |
|Eo . . . O + = . |
|   .=. .+ @ * .  |
|   +ooo... *     |
|    **..         |
+----[SHA256]-----+

Si l'opération réussit, la commande SSH aboutit et vous êtes connecté à l'instance GUA via SSH :

Updating instance ssh metadata...done.                                                                                                                                                                                                                                                                                            
Waiting for SSH key to propagate.
Warning: Permanently added 'compute.3639038240056074485' (ED25519) to the list of known hosts.
Linux gua-instance 6.1.0-34-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.135-1 (2025-04-25) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

<username>@gua-instance:~$

5. Examinez les instances IPv6 uniquement.

Examinons les instances IPv6 uniquement en nous y connectant via SSH et en examinant leurs tables de routage.

Examiner une instance GUA

Connectez-vous en SSH à l'instance "gua-instance" en passant d'abord par l'instance "ula-instance".

gcloud compute ssh ula-instance --project $projectname --zone $zonename
<username>@ula-instance:~$ gcloud compute ssh gua-instance

Examinons la table de routage IPv6 de l'instance à l'aide de la commande suivante :

<username>@gua-instance:~$ ip -6 route

2600:1900:4041:461::/65 via fe80::56:11ff:fef9:88c1 dev ens4 proto ra metric 100 expires 81sec pref medium
fe80::/64 dev ens4 proto kernel metric 256 pref medium
default via fe80::56:11ff:fef9:88c1 dev ens4 proto ra metric 100 expires 81sec mtu 1500 pref medium

Nous remarquons trois entrées dans la table de routage.

Route /65 pour le sous-réseau GUA auquel appartient l'instance, avec un saut suivant dérivé utilisant une adresse locale pour la passerelle par défaut. N'oubliez pas que la limite supérieure /65 est réservée aux équilibreurs de charge réseau passthrough IPv6.
Route /64 intégrée pour le préfixe unicast link-local fe80::/64
Route par défaut pointant vers l'adresse locale du lien pour la passerelle par défaut du sous-réseau.

Examinons la table de routage IPv4 en exécutant cette commande.

<username>@gua-instance:~$ ip -4 route

default via 169.254.1.1 dev ens4 proto dhcp src 169.254.1.2 metric 100 
169.254.1.1 dev ens4 proto dhcp scope link src 169.254.1.2 metric 100 
169.254.169.254 via 169.254.1.1 dev ens4 proto dhcp src 169.254.1.2 metric 100

Surprenant ? En fait, nous conservons une table de routage IPv4 dans les instances IPv6 uniquement, strictement pour permettre l'accès au serveur de métadonnées Compute (169.254.169.154), car il s'agit toujours d'un point de terminaison IPv4 uniquement.

Étant donné que l'instance adopte l'adresse IP 169.254.1.2 lorsqu'il s'agit d'une instance IPv6 uniquement. Cette adresse IP n'est routable que vers le serveur Compute Metadata. L'instance est donc isolée de tous les réseaux IPv4.

Tests de boucles

Testons la connectivité réelle aux sites Web IPv4 uniquement et IPv6 uniquement à l'aide de curl.

<username>@gua-instance:~$ curl -vv --connect-timeout 10 v6.ipv6test.app
<username>@gua-instance:~$ curl -vv --connect-timeout 10 v4.ipv6test.app

Vous trouverez ci-dessous un exemple de résultat.

<username>@gua-instance:~$ curl -vv --connect-timeout 10 v6.ipv6test.app
*   Trying [2600:9000:20be:cc00:9:ec55:a1c0:93a1]:80...
* Connected to v6.ipv6test.app (2600:9000:20be:cc00:9:ec55:a1c0:93a1) port 80 (#0)
> GET / HTTP/1.1
> Host: v6.ipv6test.app
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK
!! Rest of output truncated

<username>@gua-instance:~$ curl -vv --connect-timeout 10 v4.ipv6test.app
*   Trying 3.163.165.4:80...
* ipv4 connect timeout after 4985ms, move on!
*   Trying 3.163.165.50:80...
* ipv4 connect timeout after 2492ms, move on!
*   Trying 3.163.165.127:80...
* ipv4 connect timeout after 1246ms, move on!
*   Trying 3.163.165.37:80...
* ipv4 connect timeout after 1245ms, move on!
* Failed to connect to v4.ipv6test.app port 80 after 10000 ms: Timeout was reached
* Closing connection 0
curl: (28) Failed to connect to v4.ipv6test.app port 80 after 10000 ms: Timeout was reached

Comme prévu, il n'est pas possible d'accéder à un point de terminaison Internet IPv4 à partir d'une instance IPv6 uniquement. Sans provisionnement de DNS64 et NAT64, l'instance IPv6 uniquement n'a aucun chemin d'accès à une destination IPv4. L'accessibilité à une destination IPv6 fonctionne normalement, car l'instance possède une adresse IPv6 GUA.

Examiner l'instance ULA

Connectez-vous en SSH à l'instance "ula-instance" (utilise IAP par défaut).

gcloud compute ssh ula-instance --project $projectname --zone $zonename

Examinons la table de routage IPv6 de l'instance à l'aide de la commande suivante :

<username>@ula-instance:~$ ip -6 route

fd20:f06:2e5e:2000::/64 via fe80::55:82ff:fe6b:1d7 dev ens4 proto ra metric 100 expires 84sec pref medium
fe80::/64 dev ens4 proto kernel metric 256 pref medium
default via fe80::55:82ff:fe6b:1d7 dev ens4 proto ra metric 100 expires 84sec mtu 1500 pref medium

Nous remarquons trois entrées dans la table de routage, semblables à celles de l'instance GUA, à l'exception du masque qui est /64 au lieu de /65. La route de sous-réseau appartient à une plage ULA. (sous l'agrégat fd20::/20)

Examinons la table de routage IPv4 en exécutant cette commande.

<username>@ula-instance:~$ ip -4 route

default via 169.254.1.1 dev ens4 proto dhcp src 169.254.1.2 metric 100 
169.254.1.1 dev ens4 proto dhcp scope link src 169.254.1.2 metric 100 
169.254.169.254 via 169.254.1.1 dev ens4 proto dhcp src 169.254.1.2 metric 100

qui montre une situation similaire à celle de l'instance GUA.

Tests de boucles

Répétez les tests de connectivité pour les sites Web IPv4 uniquement et IPv6 uniquement à l'aide de curl.

<username>@ula-instance:~$ curl -vv --connect-timeout 10 v6.ipv6test.app
<username>@ula-instance:~$ curl -vv --connect-timeout 10 v4.ipv6test.app

Vous trouverez ci-dessous un exemple de résultat.

<username>@ula-instance:~$ curl -vv --connect-timeout 10 v6.ipv6test.app
*   Trying [2600:9000:20be:8400:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 4986ms, move on!
*   Trying [2600:9000:20be:9000:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 2493ms, move on!
*   Trying [2600:9000:20be:d600:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 1246ms, move on!
*   Trying [2600:9000:20be:b000:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 622ms, move on!
*   Trying [2600:9000:20be:7200:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 312ms, move on!
*   Trying [2600:9000:20be:8600:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 155ms, move on!
*   Trying [2600:9000:20be:7a00:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 77ms, move on!
*   Trying [2600:9000:20be:ce00:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 77ms, move on!
* Failed to connect to v6.ipv6test.app port 80 after 10000 ms: Timeout was reached
* Closing connection 0

<username>@ula-instance:~$ curl -vv --connect-timeout 10 v4.ipv6test.app
*   Trying 3.163.165.4:80...
* ipv4 connect timeout after 4985ms, move on!
*   Trying 3.163.165.50:80...
* ipv4 connect timeout after 2492ms, move on!
*   Trying 3.163.165.127:80...
* ipv4 connect timeout after 1246ms, move on!
*   Trying 3.163.165.37:80...
* ipv4 connect timeout after 1245ms, move on!
* Failed to connect to v4.ipv6test.app port 80 after 10000 ms: Timeout was reached
* Closing connection 0
curl: (28) Failed to connect to v4.ipv6test.app port 80 after 10000 ms: Timeout was reached

Dans le cas d'une instance ULA, il n'est pas possible d'accéder aux deux points de terminaison Internet, car pour le point de terminaison IPv6, nous ne pouvons pas utiliser d'adresse ULA pour communiquer, et l'instance n'a pas accès à IPv4 en tant qu'instance IPv6 uniquement.

6. Activer NAT64 et DNS64

Configurez les services DNS64 et NAT64 gérés pour votre VPC.

DNS64

Activez la règle de serveur DNS64 pour votre VPC . Cela indique au résolveur DNS du VPC de synthétiser les enregistrements AAAA pour les réponses A uniquement. Exécutez la ou les commandes suivantes dans Cloud Shell :

gcloud beta dns policies create allow-dns64 \
    --description="Enable DNS64 Policy" \
    --networks=ipv6-only-vpc \
    --enable-dns64-all-queries \
    --project $projectname

NAT64

Créez un routeur Cloud Router, qui est requis pour Cloud NAT . Créez ensuite une passerelle Cloud NAT configurée pour NAT64, en l'activant pour toutes les plages d'adresses IP de sous-réseau IPv6 uniquement et en allouant automatiquement des adresses IP externes. Exécutez la ou les commandes suivantes dans Cloud Shell :

gcloud compute routers create nat64-router \
--network=ipv6-only-vpc \
--region=$regionname \
--project=$projectname


gcloud beta compute routers nats create nat64-natgw \
--router=nat64-router \
--region=$regionname \
--auto-allocate-nat-external-ips \
--nat64-all-v6-subnet-ip-ranges \
--project=$projectname

7. Tester NAT64 et DNS64

Nous allons maintenant tester votre configuration NAT64 et DNS64 à partir des instances IPv6 uniquement, en commençant par l'instance GUA, puis par l'instance ULA.

Tester DNS64/NAT64 à partir d'une instance GUA

Connectez-vous en SSH à l'instance "gua-instance" en passant d'abord par l'instance "ula-instance".

gcloud compute ssh ula-instance --project $projectname --zone $zonename
<username>@ula-instance:~$ gcloud compute ssh gua-instance

Tests DNS

Testez la résolution DNS d'un site Web IPv6 uniquement (par exemple, v6.ipv6test.app, mais tout site Web IPv6 uniquement devrait donner un résultat similaire).

<username>@gua-instance:~$ host -t AAAA v6.ipv6test.app
<username>@gua-instance:~$ host -t A v6.ipv6test.app

Nous nous attendons à ce que seules les réponses AAAA IPv6 soient renvoyées.

Exemple de résultat :

<username>@gua-instance:~$ host -t AAAA v6.ipv6test.app
v6.ipv6test.app has IPv6 address 2600:9000:269f:1000:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:6600:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:b600:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:3e00:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:9c00:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:b200:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:a600:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:1400:9:ec55:a1c0:93a1

<username>@gua-instance:~$ host -t A v6.ipv6test.app
v6.ipv6test.app has no A record

Testez la résolution DNS d'un site Web IPv4 uniquement (par exemple, v4.ipv6test.app). Vous vous attendez à obtenir un enregistrement A (l'adresse IPv4 d'origine) et un enregistrement AAAA synthétisé par DNS64 à l'aide du préfixe bien connu 64:ff9b::/96 .

<username>@gua-instance:~$ host -t AAAA v4.ipv6test.app
<username>@gua-instance:~$ host -t A v4.ipv6test.app

Exemple de résultat :

<username>@gua-instance:~$ host -t AAAA v4.ipv6test.app
v4.ipv6test.app has IPv6 address 64:ff9b::36c0:3318
v4.ipv6test.app has IPv6 address 64:ff9b::36c0:3344
v4.ipv6test.app has IPv6 address 64:ff9b::36c0:333c
v4.ipv6test.app has IPv6 address 64:ff9b::36c0:3326

<username>@gua-instance:~$ host -t A v4.ipv6test.app
v4.ipv6test.app has address 54.192.51.68
v4.ipv6test.app has address 54.192.51.24
v4.ipv6test.app has address 54.192.51.60
v4.ipv6test.app has address 54.192.51.38

Dans l'exemple ci-dessus, l'adresse IPv4 (54.192.51.38) en décimal se traduit par (36 c0 33 26) en hexadécimal. Nous nous attendons donc à ce que la réponse pour l'enregistrement AAAA soit (64:ff9b::36c0:3326), ce qui correspond à l'une des réponses AAAA que nous avons reçues.

Tests de boucles

Testons la connectivité réelle aux mêmes points de terminaison v4 uniquement et v6 uniquement à l'aide de curl sur IPv6.

<username>@gua-instance:~$ curl -vv -6 v6.ipv6test.app

<username>@gua-instance:~$ curl -vv -6 v4.ipv6test.app

Vous trouverez ci-dessous un exemple de résultat.

<username>@gua-instance:~$ curl -vv -6 v6.ipv6test.app
*   Trying [2600:9000:269f:1000:9:ec55:a1c0:93a1]:80...
* Connected to v6.ipv6test.app (2600:9000:269f:1000:9:ec55:a1c0:93a1) port 80 (#0)
> GET / HTTP/1.1

##
## <Output truncated for brevity>
##

<username>@gua-instance:~$ curl -vv -6 v4.ipv6test.app
*   Trying [64:ff9b::36c0:333c]:80...
* Connected to v4.ipv6test.app (64:ff9b::36c0:333c) port 80 (#0)
> GET / HTTP/1.1

##
## <Output truncated for brevity>
##

Les deux commandes curl aboutissent. Vous avez pu vous connecter à un site Web IPv4 uniquement via IPv6, car NAT64 et DNS64 ont fonctionné de concert pour permettre la connectivité.

Vérifier les adresses IP sources

Utilisons un service de réflexion d'adresse IP pour vérifier l'adresse IP source observée par la destination .

<username>@gua-instance:~$ curl -6 v4.ipv6test.app

<username>@gua-instance:~$ curl -6 v6.ipv6test.app

Exemple de sortie

<username>@gua-instance:~$ curl -6 v4.ipv6test.app
34.47.60.91

<username>@gua-instance:~$ curl -6 v6.ipv6test.app
2600:1900:40e0:6f:0:1::

L'adresse IPv6 signalée doit correspondre à l'adresse IPv6 de l'instance . Cette adresse doit correspondre à la sortie de la commande "ip -6 address" sur l'instance. Par exemple :

<username>@gua-instance:~$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2600:1900:40e0:6f:0:1::/128 scope global dynamic noprefixroute
       valid_lft 79912sec preferred_lft 79912sec
    inet6 fe80::86:d9ff:fe34:27ed/64 scope link
       valid_lft forever preferred_lft forever

Toutefois, l'adresse IPv4 signalée doit correspondre à l'adresse IP externe de la passerelle Cloud NAT, car elle effectue la fonction NAT64 avant la sortie vers Internet. Vous pouvez le vérifier en exécutant cette commande gcloud dans Cloud Shell.

gcloud compute routers get-nat-ip-info \
       nat64-router \
       --region=$regionname

Exemple de sortie

result:
- natIpInfoMappings:
  - mode: AUTO
    natIp: 34.47.60.91
    usage: IN_USE
  natName: nat64-natgw

Notez que l'adresse "natIp" indiquée dans le résultat correspond à celle obtenue sur le site Web de réflexion d'adresse IP.

Tester DNS64/NAT64 à partir d'une instance ULA

Tout d'abord, connectez-vous en SSH à l'instance ULA "ula-instance".

gcloud compute ssh ula-instance --project $projectname --zone $zonename

<username>@ula-instance:~$

Tests DNS

Testez la résolution DNS d'un site Web IPv6 uniquement (par exemple, v6.ipv6test.app, mais tout site Web IPv6 uniquement devrait donner un résultat similaire).

<username>@ula-instance:~$ host -t AAAA v6.ipv6test.app
<username>@ula-instance:~$ host -t A v6.ipv6test.app

Nous nous attendons à ce que seules les réponses AAAA IPv6 soient renvoyées.

Exemple de résultat :

<username>@ula-instance:~$ host -t AAAA v6.ipv6test.app
v6.ipv6test.app has IPv6 address 2600:9000:269f:1000:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:6600:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:b600:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:3e00:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:9c00:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:b200:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:a600:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:1400:9:ec55:a1c0:93a1

<username>@ula-instance:~$ host -t A v6.ipv6test.app
v6.ipv6test.app has no A record

<username>@ula-instance:~$ host -t AAAA v4.ipv6test.app
<username>@ula-instance:~$ host -t A v4.ipv6test.app

Exemple de résultat :

<username>@gua-instance:~$ host -t AAAA v4.ipv6test.app
v4.ipv6test.app has IPv6 address 64:ff9b::36c0:3318
v4.ipv6test.app has IPv6 address 64:ff9b::36c0:3344
v4.ipv6test.app has IPv6 address 64:ff9b::36c0:333c
v4.ipv6test.app has IPv6 address 64:ff9b::36c0:3326

<username>@gua-instance:~$ host -t A v4.ipv6test.app
v4.ipv6test.app has address 54.192.51.68
v4.ipv6test.app has address 54.192.51.24
v4.ipv6test.app has address 54.192.51.60
v4.ipv6test.app has address 54.192.51.38

Tests de boucles

Testons la connectivité réelle aux mêmes points de terminaison IPv4 uniquement et IPv6 uniquement à l'aide de curl.

Pour commencer, montrons que l'accessibilité via IPv4 n'est pas possible, car l'instance est une instance IPv6 uniquement.

<username>@ula-instance:~$ curl -vv -4 --connect-timeout 10 v6.ipv6test.app
<username>@ula-instance:~$ curl -vv -4 --connect-timeout 10 v4.ipv6test.app

Les deux requêtes cURL échoueront. Elles échoueront pour différentes raisons. Vous trouverez ci-dessous un exemple de résultat.

<username>@ula-instance:~$ curl -vv -4 v6.ipv6test.app
* Could not resolve host: v6.ipv6test.app
* Closing connection 0
curl: (6) Could not resolve host: v6.ipv6test.app

<username>@ula-instance:~$ curl -vv -4 --connect-timeout 10 v4.ipv6test.app
*   Trying 54.192.51.68:80...
* ipv4 connect timeout after 4993ms, move on!
*   Trying 54.192.51.38:80...
* ipv4 connect timeout after 2496ms, move on!
*   Trying 54.192.51.24:80...
* ipv4 connect timeout after 1248ms, move on!
*   Trying 54.192.51.60:80...
* Connection timeout after 10000 ms
* Closing connection 0
curl: (28) Connection timeout after 10000 ms

La requête curl IPv4 vers un point de terminaison IPv6 uniquement échoue, car la résolution DNS pour l'enregistrement A échoue (comme démontré lors des tests DNS). La requête curl IPv4 vers un point de terminaison IPv4 uniquement échoue, car une instance IPv6 uniquement n'a aucune accessibilité à une adresse IPv4. Nous obtenons donc un délai d'attente.

Testons maintenant l'accessibilité via IPv6.

<username>@ula-instance:~$ curl -vv -6 v6.ipv6test.app

<username>@ula-instance:~$ curl -vv -6 v4.ipv6test.app

Vous trouverez ci-dessous un exemple de résultat.

<username>@ula-instance:~$ curl -vv -6 v6.ipv6test.app
*   Trying [2600:9000:20be:c000:9:ec55:a1c0:93a1]:80...
* connect to 2600:9000:20be:c000:9:ec55:a1c0:93a1 port 80 failed: Connection timed out
*   Trying [2600:9000:20be:f000:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 84507ms, move on!
*   Trying [2600:9000:20be:ae00:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 42253ms, move on!
*   Trying [2600:9000:20be:2000:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 21126ms, move on!
*   Trying [2600:9000:20be:b600:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 10563ms, move on!
*   Trying [2600:9000:20be:7600:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 5282ms, move on!
*   Trying [2600:9000:20be:b000:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 2640ms, move on!
*   Trying [2600:9000:20be:3400:9:ec55:a1c0:93a1]:80...
* ipv6 connect timeout after 2642ms, move on!
* Failed to connect to v6.ipv6test.app port 80 after 300361 ms: Timeout was reached
* Closing connection 0

<username>@ula-instance:~$ curl -vv -6 v4.ipv6test.app
*   Trying [64:ff9b::36c0:333c]:80...
* Connected to v4.ipv6test.app (64:ff9b::36c0:333c) port 80 (#0)
> GET / HTTP/1.1

##
## <Output truncated for brevity>
##

La requête curl vers le site Web IPv6 uniquement échoue, car les sous-réseaux ULA ne sont pas directement accessibles sur Internet. La commande curl vers le site Web IPv4 uniquement réussit, car DNS64 et NAT64 fonctionnent de la même manière pour les instances GUA et ULA. La seule exigence est que l'instance soit IPv6 uniquement.

Tester DNS64/NAT64 à partir d'une instance ULA à double pile

Tout d'abord, connectez-vous en SSH à l'instance ULA à double pile "dualstack-ula-instance". Nous devons utiliser l'option "–tunnel-through-iap" pour forcer gcloud à utiliser l'adresse IPv4 pour IAP.

gcloud compute ssh dualstack-ula-instance --project $projectname --zone $zonename --tunnel-through-iap 

<username>@dualstack-ula-instance:~$

Testons maintenant DNS64 à l'aide de l'utilitaire "host".

<username>@dualstack-ula-instance:~$ host v4.ipv6test.app
v4.ipv6test.app has address 54.192.51.38
v4.ipv6test.app has address 54.192.51.24
v4.ipv6test.app has address 54.192.51.68
v4.ipv6test.app has address 54.192.51.60

<username>@dualstack-ula-instance:~$ host v6.ipv6test.app
v6.ipv6test.app has IPv6 address 2600:9000:269f:fc00:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:1c00:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:a200:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:8a00:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:c800:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:c200:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:5800:9:ec55:a1c0:93a1
v6.ipv6test.app has IPv6 address 2600:9000:269f:dc00:9:ec55:a1c0:93a1

Notez que le site Web IPv4 uniquement ne renvoie désormais que des adresses IPv4, et non plus les réponses DNS64 synthétiques. En effet, DNS64 n'est appliqué qu'aux instances IPv6 uniquement et n'est pas évalué pour les instances à double pile.

Pour éviter d'avoir besoin de DNS64, ajoutons une entrée au fichier /etc/hosts pour tester si NAT64 fonctionne. Exécutez la commande suivante dans l'instance à double pile :

<username>@dualstack-ula-instance:~$ echo '64:ff9b::36c0:3326 v4.ipv6test.app' | sudo tee -a /etc/hosts

Utilisons ensuite curl pour tester l'accès au site Web IPv4 via IPv6.

<username>@dualstack-ula-instance:~$ curl -vv -6 --connect-timeout 10 v4.ipv6test.app

Voici un exemple de résultat de la commande ci-dessus :

<username>@dualstack-ula-instance:~$ curl -vv -6 --connect-timeout 10 v4.ipv6test.app

*   Trying [64:ff9b::36c0:3326]:80...
* ipv6 connect timeout after 10000ms, move on!
* Failed to connect to v4.ipv6test.app port 80 after 10001 ms: Timeout was reached
* Closing connection 0
curl: (28) Failed to connect to v4.ipv6test.app port 80 after 10001 ms: Timeout was reached

La commande curl devrait expirer, car, tout comme DNS64, NAT64 exige également que l'instance soit IPv6 uniquement pour s'appliquer.

Pour confirmer que NAT64 ne s'applique pas à l'instance à double pile, utilisons la commande "get-nat-mapping" pour lister tous les mappages de ports appliqués par la passerelle NAT. Exécutez la ou les commandes suivantes dans Cloud Shell :

gcloud compute routers get-nat-mapping-info \
      nat64-router --region $regionname \
      --project $projectname

Vous devriez obtenir un résultat semblable à l'extrait ci-dessous :

---
instanceName: gua-instance
interfaceNatMappings:
- natIpPortRanges:
  - 34.47.60.91:1024-1055
  numTotalDrainNatPorts: 0
  numTotalNatPorts: 32
  sourceAliasIpRange: ''
  sourceVirtualIp: '2600:1900:40e0:6f:0:1::'
- natIpPortRanges:
  - 34.47.60.91:32768-32799
  numTotalDrainNatPorts: 0
  numTotalNatPorts: 32
  sourceAliasIpRange: ''
  sourceVirtualIp: '2600:1900:40e0:6f:0:1::'
---
instanceName: ula-instance
interfaceNatMappings:
- natIpPortRanges:
  - 34.47.60.91:1056-1087
  numTotalDrainNatPorts: 0
  numTotalNatPorts: 32
  sourceAliasIpRange: ''
  sourceVirtualIp: fd20:9c2:93fc:2800:0:0:0:0
- natIpPortRanges:
  - 34.47.60.91:32800-32831
  numTotalDrainNatPorts: 0
  numTotalNatPorts: 32
  sourceAliasIpRange: ''
  sourceVirtualIp: fd20:9c2:93fc:2800:0:0:0:0

La sortie NAT indique que la passerelle NAT64 n'a alloué des ports que pour les instances GUA et ULA IPv6 uniquement, mais pas pour l'instance à double pile.

8. Effectuer un nettoyage

Nettoyer Cloud Router

Dans Cloud Shell, procédez comme suit :

gcloud compute routers delete nat64-router \
      --region $regionname \
      --project $projectname --quiet

Dissocier et nettoyer la règle DNS

Dans Cloud Shell, procédez comme suit :

gcloud beta dns policies update allow-dns64 \
    --networks="" \
    --project $projectname
gcloud beta dns policies delete allow-dns64 \
    --project $projectname --quiet

Nettoyer les instances

Dans Cloud Shell, procédez comme suit (notez que gcloud beta est utilisé pour nous permettre d'utiliser l'indicateur no-graceful-shutdown pour une opération de suppression d'instance plus rapide) :

gcloud beta compute instances delete gua-instance \
         --zone $zonename \
         --no-graceful-shutdown \
         --project=$projectname --quiet

gcloud beta compute instances delete ula-instance \
         --zone $zonename \
         --no-graceful-shutdown \
         --project=$projectname --quiet

gcloud beta compute instances delete dualstack-ula-instance \
         --zone $zonename \
         --no-graceful-shutdown \
         --project=$projectname --quiet

Nettoyer les sous-réseaux

Dans Cloud Shell, procédez comme suit :

gcloud compute networks subnets delete gua-v6only-subnet \
    --project=$projectname --quiet \
    --region=$regionname
 
gcloud compute networks subnets delete ula-v6only-subnet \
    --project=$projectname --quiet \
    --region=$regionname

gcloud compute networks subnets delete ula-dualstack-subnet \
    --project=$projectname --quiet \
    --region=$regionname

Nettoyer les règles de pare-feu

Dans Cloud Shell, procédez comme suit :

gcloud compute firewall-rules delete allow-v6-iap \
       --project=$projectname \
       --quiet

gcloud compute firewall-rules delete allow-v6-ssh-ula \
       --project=$projectname \
       --quiet

gcloud compute firewall-rules delete allow-v4-iap \
--project=$projectname \
--quiet

Nettoyer le VPC

Dans Cloud Shell, procédez comme suit :

gcloud compute networks delete ipv6-only-vpc \
       --project=$projectname \
       --quiet

Nettoyer les autorisations IAM et le compte de service

Dans Cloud Shell, procédez comme suit :

gcloud projects remove-iam-policy-binding  $projectname \
--member=serviceAccount:ipv6-codelab@$projectname.iam.gserviceaccount.com \
--role=roles/compute.instanceAdmin.v1

gcloud iam service-accounts delete \
     ipv6-codelab@$projectname.iam.gserviceaccount.com \
     --quiet \
     --project $projectname

9. Félicitations

Vous avez utilisé NAT64 et DNS64 pour permettre aux instances IPv6 uniquement d'accéder aux destinations IPv4 uniquement sur Internet.

Créer des instances de VM IPv6 uniquement et activer NAT64/DNS64

1. Introduction

2. Points abordés

3. Avant de commencer

Mettre à jour le projet pour prendre en charge l'atelier de programmation

Architecture globale de l'atelier

4. Étapes de préparation

Créer un compte de service et des liaisons IAM

Créer un VPC et activer l'ULA

Créer des règles de pare-feu

Créer des sous-réseaux

Créer des instances

Accès et configuration initiaux de l'instance

5. Examinez les instances IPv6 uniquement.

Examiner une instance GUA

Tests de boucles

Examiner l'instance ULA

Tests de boucles

6. Activer NAT64 et DNS64

DNS64

NAT64

7. Tester NAT64 et DNS64

Tester DNS64/NAT64 à partir d'une instance GUA

Tests DNS

Tests de boucles

Vérifier les adresses IP sources

Tester DNS64/NAT64 à partir d'une instance ULA

Tests DNS

Tests de boucles

Tester DNS64/NAT64 à partir d'une instance ULA à double pile

8. Effectuer un nettoyage

Nettoyer Cloud Router

Dissocier et nettoyer la règle DNS

Nettoyer les instances

Nettoyer les sous-réseaux

Nettoyer les règles de pare-feu

Nettoyer le VPC

Nettoyer les autorisations IAM et le compte de service

9. Félicitations

Étape suivante

Lectures complémentaires et vidéos

Documents de référence