Diese Seite wurde von der Cloud Translation API übersetzt.

Reine IPv6-VM-Instanzen erstellen und NAT64/DNS64 aktivieren

1. Einführung

Eine der größten Herausforderungen bei der Migration zu IPv6 ist die Aufrechterhaltung der Erreichbarkeit von reinen IPv4-Endpunkten und ‑Netzwerken. Eine führende Technologie zur Bewältigung dieser Herausforderung ist die Kombination aus DNS64 (definiert in RFC6147), um A-Einträge für Clients in AAAA-Einträge zu übersetzen, und NAT64 (definiert in RFC6146), um speziell formatierte IPv6-Adressen in IPv4 zu übersetzen, wobei die IPv4-Adresse in die spezielle IPv6-Adresse eingebettet ist. In diesem Codelab wird beschrieben, wie Sie beide Funktionen in einer Virtual Private Cloud (VPC) der Google Cloud Platform (GCP) konfigurieren. Wenn GCP NAT64 und DNS64 zusammen konfiguriert werden, können reine IPv6-Instanzen mit reinen IPv4-Servern im Internet kommunizieren.

In diesem Lab richten Sie eine VPC mit verschiedenen Arten von IPv6-Subnetzen und ‑Instanzen ein : reine IPv6-GUA (Global Unicast Address), reine IPv6-ULA (Unique Local Address) und Dual-Stack-ULA. Anschließend konfigurieren und testen Sie die verwalteten DNS64- und NAT64-Dienste von Google Cloud, um darüber auf reine IPv4-Websites zuzugreifen.

2. Lerninhalte

Nur-IPv6-Subnetze und -Instanzen erstellen
So aktivieren Sie den verwalteten DNS64-Dienst von Google Cloud für eine VPC .
So erstellen Sie ein für NAT64 konfiguriertes Google Cloud NAT-Gateway .
So testen Sie die DNS64-Auflösung von reinen IPv6-Instanzen zu reinen IPv4-Zielen.
Wie sich DNS64- und NAT64-Verhalten zwischen Single-Stack- und Dual-Stack-Instanzen unterscheidet.
So konfigurieren Sie ein NAT-Gateway für NAT64.
So testen Sie die NAT64-Konnektivität von reinen IPv6-Instanzen zu reinen IPv4-Zielen.

3. Hinweis

Projekt für das Codelab aktualisieren

In diesem Codelab werden $Variablen verwendet, um die Implementierung der gcloud-Konfiguration in Cloud Shell zu erleichtern.

Führen Sie in Cloud Shell die folgenden Schritte aus:

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]

Gesamtarchitektur des Labs

Um zu veranschaulichen, wie NAT64 und DNS64 mit verschiedenen IPv6-Subnetztypen interagieren, erstellen Sie eine einzelne VPC mit IPv6-Subnetzen in GUA- und ULA-Varianten. Außerdem erstellen Sie ein Dual-Stack-Subnetz (mit ULA-Adressierung), um zu demonstrieren, dass DNS64 und NAT64 nicht für Dual-Stack-VMs gelten.

Anschließend konfigurieren Sie DNS64 und NAT64 und testen die Verbindung zu IPv6- und IPv4-Zielen im Internet.

4. Vorbereitungsschritte

Richten Sie zuerst das erforderliche Dienstkonto, IAM, die Netzwerkinfrastruktur und die Instanzen in Ihrem Google Cloud-Projekt ein.

Dienstkonto und IAM-Bindungen erstellen

Zuerst erstellen wir ein neues Dienstkonto, damit die Instanzen über gcloud per SSH miteinander kommunizieren können. Wir benötigen diese Möglichkeit, da wir nicht über IAP auf die reine GUA-IPv6-Instanz zugreifen können und Cloud Shell noch keinen direkten IPv6-Zugriff ermöglicht. Führen Sie die folgenden Befehle in Cloud Shell aus.

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

VPC erstellen und ULA aktivieren

Erstellen Sie ein VPC-Netzwerk mit benutzerdefiniertem Subnetzmodus und aktiviertem internen ULA-IPv6, indem Sie die folgenden Befehle in Cloud Shell ausführen.

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

Firewallregeln erstellen

Erstellen Sie Firewallregeln, um den SSH-Zugriff zuzulassen. Eine Regel lässt SSH aus dem gesamten ULA-Bereich (fd20::/20) zu. Zwei weitere Regeln lassen Traffic aus den vordefinierten IPv6- und IPv4-Bereichen von IAP (2600:2d00:1:7::/64 bzw. 35.235.240.0/20) zu.

Führen Sie die folgenden Befehle in Cloud Shell aus:

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

Subnetze erstellen

Erstellen Sie ein GUA-Subnetz, ein ULA-Subnetz und ein Dual-Stack-ULA-Subnetz, die jeweils nur IPv6 verwenden. Führen Sie die folgenden Befehle in Cloud Shell aus:

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

Instanzen erstellen

Erstellen Sie Instanzen in jedem der gerade erstellten Subnetze. Die reine IPv6-ULA-Instanz wird mit cloud-platform angegeben, damit wir sie als Jumpbox für die reine GUA-IPv6-Instanz verwenden können. Führen Sie die folgenden Befehle in Cloud Shell aus:

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

Ersteinrichtung und Zugriff auf die Instanz

Stellen Sie eine SSH-Verbindung zur ULA-Instanz her. Dabei wird standardmäßig IAP verwendet. Verwenden Sie den folgenden Befehl in Cloud Shell, um eine SSH-Verbindung zur ULA-Instanz herzustellen:

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

<username>@ula-instance:~$

Wir verwenden die ULA-Instanz auch als Jumpbox für die GUA-Instanz, da IAP nicht mit GUA-Instanzen funktioniert und Cloud Shell-VMs nicht auf IPv6-Ziele zugreifen können.

Sie befinden sich weiterhin in der Shell der ULA-Instanz. Versuchen Sie, mit dem folgenden gcloud-Befehl eine SSH-Verbindung zur GUA-Instanz herzustellen.

Wenn Sie zum ersten Mal einen SSH-Befehl in einer Instanz ausführen, werden Sie aufgefordert, ein SSH-Schlüsselpaar einzurichten. Drücken Sie die Eingabetaste, bis der Schlüssel erstellt und der SSH-Befehl ausgeführt wird. Dadurch wird ein neues Schlüsselpaar ohne Passphrase erstellt.

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

Wenn der Vorgang erfolgreich ist, wird der SSH-Befehl erfolgreich ausgeführt und Sie haben eine SSH-Verbindung zur GUA-Instanz hergestellt:

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. Reine IPv6-Instanzen untersuchen

Sehen wir uns beide reinen IPv6-Instanzen an, indem wir eine SSH-Verbindung zu ihnen herstellen und ihre Routingtabellen untersuchen.

GUA-Instanz untersuchen

Stellen Sie eine SSH-Verbindung zur „gua-instance“ her, indem Sie zuerst über die „ula-instance“ springen.

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

Sehen wir uns die IPv6-Routingtabelle der Instanz mit dem folgenden Befehl an.

<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

Wir sehen drei Einträge in der Routingtabelle.

Eine /65-Route für das GUA-Subnetz, zu dem die Instanz gehört, mit einem abgeleiteten nächsten Hop, der eine link-lokale Adresse für das Standardgateway verwendet. Der obere /65-Bereich ist für IPv6-Passthrough-Network-Load-Balancer reserviert.
Eine integrierte /64-Route für das verbindungslokale Unicast-Präfix fe80::/64
Eine Standardroute, die auf die Link-Local-Adresse für das Standardgateway des Subnetzes verweist.

Sehen wir uns die IPv4-Routingtabelle an, indem wir diesen Befehl ausführen.

<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

Überraschend? Tatsächlich wird in reinen IPv6-Instanzen eine IPv4-Routingtabelle verwaltet, um den Zugriff auf den Compute Metadata-Server (169.254.169.154) zu ermöglichen, da es sich dabei um einen reinen IPv4-Endpunkt handelt.

Da die Instanz die IP-Adresse 169.254.1.2 übernimmt, wenn es sich um eine reine IPv6-Instanz handelt. Diese IP-Adresse kann nur zum Compute-Metadatenserver geroutet werden. Die Instanz ist also effektiv von allen IPv4-Netzwerken isoliert.

Curl-Tests

Wir testen die tatsächliche Verbindung zu reinen IPv4- und reinen IPv6-Websites mit curl.

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

Unten sehen Sie ein Beispiel für die Ausgabe.

<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

Wie erwartet, ist ein IPv4-Internetendpunkt von einer reinen IPv6-Instanz aus nicht erreichbar. Ohne die Bereitstellung von DNS64 und NAT64 hat die reine IPv6-Instanz keinen Pfad zu einem IPv4-Ziel. Die Erreichbarkeit eines IPv6-Ziels funktioniert normal, da die Instanz eine GUA-IPv6-Adresse hat.

ULA-Instanz prüfen

Stellen Sie eine SSH-Verbindung zur Instanz „ula-instance“ her (standardmäßig wird IAP verwendet).

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

Sehen wir uns die IPv6-Routingtabelle der Instanz mit dem folgenden Befehl an.

<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

In der Routingtabelle sind drei Einträge zu sehen, ähnlich wie bei der GUA-Instanz, mit der Ausnahme, dass die Maske /64 statt /65 ist. Die Subnetzroute gehört zu einem ULA-Bereich. (unter dem fd20::/20-Aggregat)

Sehen wir uns die IPv4-Routingtabelle an, indem wir diesen Befehl ausführen.

<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

Das ist eine ähnliche Situation wie bei der GUA-Instanz.

Curl-Tests

Wiederholen der Konnektivitätstests für reine v4- und reine v6-Websites mit curl.

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

Unten sehen Sie ein Beispiel für die Ausgabe.

<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

Im Fall der ULA-Instanz ist keine Erreichbarkeit beider Internetendpunkte möglich, da für den IPv6-Endpunkt keine ULA-Adresse für die ausgehende Kommunikation verwendet werden kann und die Instanz als reine IPv6-Instanz nicht über IPv4 erreichbar ist.

6. NAT64 und DNS64 aktivieren

Konfigurieren Sie die verwalteten DNS64- und NAT64-Dienste für Ihre VPC.

DNS64

Aktivieren Sie die DNS64-Serverrichtlinie für Ihre VPC . Dadurch wird der DNS-Resolver der VPC angewiesen, AAAA-Einträge für Antworten zu synthetisieren, die nur A-Einträge enthalten. Führen Sie die folgenden Befehle in Cloud Shell aus:

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

NAT64

Erstellen Sie einen Cloud Router, der für Cloud NAT erforderlich ist . Erstellen Sie dann ein für NAT64 konfiguriertes Cloud NAT-Gateway, das für alle IPv6-Subnetz-IP-Bereiche aktiviert ist und externe IP-Adressen automatisch zuweist. Führen Sie die folgenden Befehle in Cloud Shell aus:

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. NAT64 und DNS64 testen

Testen Sie nun Ihre NAT64- und DNS64-Konfiguration über die reinen IPv6-Instanzen. Beginnen Sie mit der GUA-Instanz und fahren Sie dann mit der ULA-Instanz fort.

DNS64/NAT64 von einer GUA-Instanz aus testen

Stellen Sie eine SSH-Verbindung zur „gua-instance“ her, indem Sie zuerst über die „ula-instance“ springen.

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

DNS-Tests

DNS-Auflösung einer reinen IPv6-Website testen (z.B. v6.ipv6test.app. Jede reine IPv6-Website sollte jedoch ein ähnliches Ergebnis liefern.

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

Es werden nur IPv6-AAAA-Antworten erwartet.

Beispielausgabe

<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

Testen Sie die DNS-Auflösung einer reinen IPv4-Website (z.B. v4.ipv6test.app) . Sie erwarten sowohl einen A-Eintrag (die ursprüngliche IPv4) als auch einen AAAA-Eintrag, der von DNS64 mit dem bekannten Präfix 64:ff9b::/96 synthetisiert wurde .

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

Beispielausgabe

<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

Im obigen Beispiel würde die IPv4-Adresse (54.192.51.38) in Dezimalzahlen in (36 c0 33 26) in Hexadezimalzahlen übersetzt. Daher würden wir erwarten, dass eine Antwort für den AAAA-Eintrag (64:ff9b::36c0:3326) lautet, was einer der AAAA-Antworten entspricht, die wir erhalten haben.

Curl-Tests

Wir testen die tatsächliche Konnektivität zu denselben reinen v4- und reinen v6-Endpunkten mit curl über IPv6.

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

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

Unten sehen Sie ein Beispiel für die Ausgabe.

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

Beide curl-Befehle werden erfolgreich ausgeführt. Beachten Sie, dass die Verbindung zu einer reinen IPv4-Website über IPv6 möglich war, da NAT64 und DNS64 zusammengearbeitet haben, um die Verbindung erfolgreich herzustellen.

Quell-IP-Adressen prüfen

Wir verwenden einen IP-Reflexionsdienst, um die vom Ziel beobachtete Quell-IP zu prüfen .

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

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

Beispielausgabe:

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

Die gemeldete IPv6-Adresse sollte mit der IPv6-Adresse der Instanz übereinstimmen . Diese Adresse sollte mit der Ausgabe des Befehls „ip -6 address“ auf der Instanz übereinstimmen. Beispiel

<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

Die gemeldete IPv4-Adresse sollte jedoch mit der externen IP-Adresse des Cloud NAT-Gateways übereinstimmen, da es die NAT64-Funktion ausführt, bevor es ins Internet gelangt. Dies kann durch Ausführen dieses gcloud-Befehls in Cloud Shell überprüft werden.

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

Beispielausgabe:

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

Beachten Sie, dass die in der Ausgabe angegebene „natIp“ mit der Ausgabe der IP-Reflexionswebsite übereinstimmt.

DNS64/NAT64 von einer ULA-Instanz aus testen

Stellen Sie zuerst eine SSH-Verbindung zur ULA-Instanz „ula-instance“ her.

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

<username>@ula-instance:~$

DNS-Tests

DNS-Auflösung einer reinen IPv6-Website testen (z.B. v6.ipv6test.app. Jede reine IPv6-Website sollte jedoch ein ähnliches Ergebnis liefern.

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

Es werden nur IPv6-AAAA-Antworten erwartet.

Beispielausgabe

<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

Beispielausgabe

<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

Curl-Tests

Wir testen die tatsächliche Verbindung zu denselben reinen v4- und reinen v6-Endpunkten mit curl.

Zunächst zeigen wir, dass die Erreichbarkeit über IPv4 nicht möglich ist, da die Instanz eine reine IPv6-Instanz ist.

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

Beide Curls schlagen fehl. Sie schlagen aus unterschiedlichen Gründen fehl. Unten sehen Sie ein Beispiel für die Ausgabe.

<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

Der IPv4-Curl zu einem reinen IPv6-Endpunkt schlägt fehl, weil die DNS-Auflösung für den A-Eintrag fehlschlägt (wie bei den DNS-Tests gezeigt). Der IPv4-Curl zu einem reinen IPv4-Endpunkt schlägt fehl, da eine reine IPv6-Instanz keine Erreichbarkeit für IPv4-Adressen hat. Daher kommt es zu einem Zeitüberschreitungsfehler.

Testen wir nun die Erreichbarkeit über IPv6.

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

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

Unten sehen Sie ein Beispiel für die Ausgabe.

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

Der curl-Befehl für die reine IPv6-Website schlägt fehl, da ULA-Subnetze nicht direkt über das Internet erreichbar sind. Der curl-Befehl für die reine IPv4-Website wird erfolgreich ausgeführt, da DNS64 und NAT64 für GUA- und ULA-Instanzen gleich funktionieren. Die einzige Voraussetzung ist, dass die Instanz nur IPv6 verwendet.

DNS64/NAT64 über eine Dual-Stack-ULA-Instanz testen

Stellen Sie zuerst eine SSH-Verbindung zur Dual-Stack-ULA-Instanz „dualstack-ula-instance“ her. Wir müssen das Flag „–tunnel-through-iap“ verwenden, um gcloud zu zwingen, die IPv4-Adresse für IAP zu verwenden.

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

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

Testen wir DNS64 jetzt mit dem Dienstprogramm „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

Die Website, die nur IPv4 verwendet, gibt jetzt nur noch IPv4-Adressen zurück und nicht mehr die synthetischen DNS64-Antworten. Das liegt daran, dass DNS64 nur auf reine IPv6-Instanzen angewendet wird und nicht für Dual-Stack-Instanzen ausgewertet wird.

Um DNS64 zu umgehen, fügen wir der Datei „/etc/hosts“ einen Eintrag hinzu, um zu testen, ob NAT64 funktioniert. Führen Sie den folgenden Befehl in der Dual-Stack-Instanz aus:

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

Verwenden wir dann curl, um zu testen, ob die IPv4-Website über IPv6 erreichbar ist.

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

Hier sehen Sie eine Beispielausgabe des obigen Befehls:

<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

Der curl-Befehl sollte ein Zeitlimit überschreiten, da wie bei DNS64 auch bei NAT64 die Instanz nur IPv6 verwenden muss, damit NAT64 angewendet werden kann.

Um zu bestätigen, dass NAT64 nicht auf die Dual-Stack-Instanz angewendet wird, verwenden wir den Befehl „get-nat-mapping“, um alle Portzuordnungen aufzulisten, die das NAT-Gateway anwendet. Führen Sie die folgenden Befehle in Cloud Shell aus:

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

Die Ausgabe sollte in etwa so aussehen:

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

Die NAT-Ausgabe zeigt, dass das NAT64-Gateway nur Ports für die reinen IPv6-GUA- und ULA-Instanzen, nicht aber für die Dual-Stack-Instanz zugewiesen hat.