שימוש במופע של צעד ניתוב הבא (ללא תגים ועם תגים) של נתיבי IPv6 סטטיים, בכתובת של צעד הניתוב הבא ובשער של צעד הניתוב הבא

1. מבוא

נתיבים מותאמים אישית סטטיים משפיעים על התנהגות הניתוב שמוגדרת כברירת מחדל ב-VPC. מסלולים מותאמים אישית של IPv6 תומכים עכשיו במאפיינים חדשים של הניתוב הבא: next-hop-gateway, ‏ next-hop-instance ו-next-hop-address. ב-codelab הזה מתואר איך להשתמש בנתיבים מותאמים אישית של IPv6 עם האפשרויות החדשות של הניתוב לקפיצה הבאה, באמצעות שני VPC שמחוברים על ידי מכונת VM עם כמה כרטיסי NIC. תדגימו גם שילוב של כתובות ULA ו-GUA, ותספקו נגישות ל-VPC של ULA לאינטרנט הציבורי באמצעות יכולת הניתוב המותאם אישית החדשה.

מה תלמדו

  • איך יוצרים מסלול מותאם אישית של IPv6 עם קפיצה הבאה של מופע.
  • איך יוצרים מסלול מותאם אישית של IPv6 עם שער לניתוב קפיצה הבאה.
  • איך יוצרים מסלול מותאם אישית של IPv6 עם כתובת של נקודת מעבר.

הדרישות

  • פרויקט ב-Google Cloud

‫2. לפני שמתחילים

עדכון הפרויקט כדי לתמוך ב-codelab

ב-Codelab הזה נעשה שימוש במשתנים כדי להקל על הטמעת ההגדרה של gcloud ב-Cloud Shell.

ב-Cloud Shell, מבצעים את הפעולות הבאות

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
export projectname=$(gcloud config list --format="value(core.project)")

ארכיטקטורת Lab כוללת

eae86f3e371e74b8.png

כדי להדגים את שני הסוגים של קפיצות מותאמות אישית של מסלולים, תיצרו 3 רשתות VPC: רשת VPC של לקוח שמשתמשת בכתובות GUA, רשת VPC של שרת שמשתמשת בכתובות ULA ורשת VPC שנייה של שרת שמשתמשת בכתובות GUA.

כדי ש-VPC של הלקוח יוכל לגשת לשרת ULA, תשתמשו בנתיב מותאם אישית באמצעות next-hop-instance ו-next-hop-address שמפנים למכונת שער עם כמה כרטיסי NIC. כדי לספק גישה לשרת GUA (אחרי מחיקת מסלול ברירת המחדל ::‎/0), תשתמשו במסלול מותאם אישית עם next-hop-gateway שמצביע על Default Internet Gateway כדי לספק ניתוב באינטרנט.

3. הגדרה של VPC לקוח

יצירת ה-VPC של הלקוח

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks create client-vpc \
    --project=$projectname \
    --subnet-mode=custom \
    --mtu=1500 --bgp-routing-mode=regional

יצירת רשת המשנה של הלקוח

ב-Cloud Shell, מבצעים את הפעולות הבאות:

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=external \
    --region=us-central1

מתעדים את רשת המשנה של GUA שהוקצתה במשתנה סביבה באמצעות הפקודה הזו

export client_subnet=$(gcloud compute networks subnets \
    describe client-subnet \
    --project $projectname \
    --format="value(externalIpv6Prefix)" \
    --region us-central1)

הפעלת מופע של לקוח

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute instances create client-instance \
    --subnet client-subnet \
    --stack-type IPV4_IPV6 \
    --zone us-central1-a \
    --project=$projectname

הוספת כלל לחומת האש לתעבורת נתונים של לקוח VPC

ב-Cloud Shell, מבצעים את הפעולות הבאות:

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

הוספת כלל לחומת האש כדי לאפשר IAP למופע הלקוח

ב-Cloud Shell, מבצעים את הפעולות הבאות:

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

אישור גישת SSH למופע הלקוח

ב-Cloud Shell, מתחברים למופע הלקוח:

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

אם הפעולה תצליח, יופיע חלון טרמינל ממופע הלקוח. כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

4. הגדרה של VPC בשרת ULA

יצירת VPC של שרת ULA

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks create server-vpc1 \
    --project=$projectname \
    --subnet-mode=custom --mtu=1500 \
    --bgp-routing-mode=regional \
    --enable-ula-internal-ipv6

יצירת רשתות משנה של שרת ULA

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks subnets create server-subnet1 \
    --network=server-vpc1 \
    --project=$projectname \
    --range=192.168.0.0/24 \
    --stack-type=IPV4_IPV6 \
    --ipv6-access-type=internal \
    --region=us-central1

מתעדים את רשת המשנה של ULA שהוקצתה במשתנה סביבה באמצעות הפקודה הזו

export server_subnet1=$(gcloud compute networks subnets \
    describe server-subnet1 \
    --project $projectname \
    --format="value(internalIpv6Prefix)" \
    --region us-central1)

הפעלת מכונה וירטואלית של שרת עם כתובת IPV6 פנימית מסוג ULA

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute instances create server-instance1 \
    --subnet server-subnet1 \
    --stack-type IPV4_IPV6 \
    --zone us-central1-a \
    --project=$projectname

הוספת כלל חומת אש שמאפשר גישה לשרת מהלקוח

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute firewall-rules create allow-client-server1 \
    --direction=INGRESS --priority=1000 \
    --network=server-vpc1 --action=ALLOW \
    --rules=tcp --source-ranges=$client_subnet \
    --project=$projectname

הוספת כלל לחומת האש כדי לאפשר IAP

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute firewall-rules create allow-iap-server1 \
    --direction=INGRESS --priority=1000 \
    --network=server-vpc1 --action=ALLOW \
    --rules=tcp:22 \
    --source-ranges=35.235.240.0/20 \
    --project=$projectname

התקנת Apache במופע של שרת ULA

ב-Cloud Shell, מתחברים למופע הלקוח:

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

במעטפת של מכונת ה-VM של השרת, מריצים את הפקודה הבאה

sudo apt update && sudo apt -y install apache2

אימות הפעילות של Apache

sudo systemctl status apache2

החלפת דף האינטרנט שמוגדר כברירת מחדל

echo '<!doctype html><html><body><h1>Hello World! From Server1!</h1></body></html>' | sudo tee /var/www/html/index.html

כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

5. הגדרה של VPC בשרת GUA

יצירת ה-VPC של שרת GUA

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks create server-vpc2 \
    --project=$projectname \
    --subnet-mode=custom --mtu=1500 \
    --bgp-routing-mode=regional

יצירת רשתות משנה של שרת GUA

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks subnets create server-subnet2 \
    --network=server-vpc2 \
    --project=$projectname \
    --range=192.168.0.0/24 \
    --stack-type=IPV4_IPV6 \
    --ipv6-access-type=external \
    --region=us-central1

מתעדים את רשת המשנה של GUA שהוקצתה במשתנה סביבה באמצעות הפקודה הזו

export server_subnet2=$(gcloud compute networks subnets \
    describe server-subnet2 \
    --project $projectname \
    --format="value(externalIpv6Prefix)" \
    --region us-central1)

הפעלת מכונת VM של שרת עם כתובת GUA IPV6

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute instances create server-instance2 \
    --subnet server-subnet2 \
    --stack-type IPV4_IPV6 \
    --zone us-central1-a \
    --project=$projectname

הוספת כלל לחומת האש כדי לאפשר גישה בתוך רשת המשנה

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute firewall-rules create allow-client-server2 \
    --direction=INGRESS \
    --priority=1000 \
    --network=server-vpc2 \
    --action=ALLOW \
    --rules=tcp --source-ranges=$client_subnet \
    --project=$projectname

הוספת כלל לחומת האש כדי לאפשר IAP

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute firewall-rules create allow-iap-server2 \
    --direction=INGRESS \
    --priority=1000 \
    --network=server-vpc2 \
    --action=ALLOW \
    --rules=tcp:22 \
    --source-ranges=35.235.240.0/20 \
    --project=$projectname

אישור גישת SSH למופע של שרת GUA והתקנת Apache

ב-Cloud Shell, מתחברים למופע הלקוח:

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

במעטפת של מכונת ה-VM של השרת, מריצים את הפקודה הבאה

sudo apt update && sudo apt -y install apache2

אימות הפעילות של Apache

sudo systemctl status apache2

החלפת דף האינטרנט שמוגדר כברירת מחדל

echo '<!doctype html><html><body><h1>Hello World! From Server2!</h1></body></html>' | sudo tee /var/www/html/index.html

כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

6. יצירת מכונת שער

מחיקת מסלול ברירת המחדל של רשת ה-VPC של הלקוח

כדי להתכונן להפניה מחדש של תנועת ULA v6 למופע עם כמה כרטיסי רשת ולהשבית את הניתוב של תנועת נתונים שיוצאת מהאינטרנט. מוחקים את מסלול ברירת המחדל ::‎/0 שמצביע על שער ברירת המחדל באינטרנט.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

export client_defroutename=$(gcloud compute routes list \
--project $projectname \
--format='value(name)' \
--filter="network:client-vpc AND destRange~'::/0'")

gcloud compute routes delete $client_defroutename \
--project $projectname \
--quiet

הפעלת מכונה וירטואלית של שער עם מספר כרטיסי רשת

ב-Cloud Shell, מבצעים את הפעולות הבאות:ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute instances create gateway-instance \
    --project=$projectname \
    --zone=us-central1-a \
--network-interface=stack-type=IPV4_IPV6,subnet=client-subnet,no-address \
--network-interface=stack-type=IPV4_IPV6,subnet=server-subnet1,no-address \
    --can-ip-forward

הגדרת מופע של שער

ב-Cloud Shell, מתחברים למכונת השער (יכול להיות שיחלפו כמה דקות עד שחיבור ה-SSH יצליח בזמן שהמכונה מופעלת):

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

במעטפת של מכונת ה-VM של השער, מריצים את הפקודה הבאה כדי להפעיל העברת IPv6 ולהמשיך לקבל הודעות RA עם העברה מופעלת (accept_ra = 2)

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

אימות טבלת הניתוב של IPv6 במכונה

ip -6 route show

פלט לדוגמה שבו מוצגים נתיבי רשת משנה של ULA ו-GUA, והנתיב שמוגדר כברירת מחדל מצביע על ממשק 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

כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

7. יצירה ובדיקה של מסלולים למופע של שער (באמצעות שם המופע)

בקטע הזה תוסיפו מסלולים לשני ה-VPC של הלקוח והשרת באמצעות שם מופע השער כנקודת הניתוב הבאה.

רישום של כתובות השרת

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute instances list \
   --project $projectname \
   --filter="name~server-instance" \
--format='value[separator=","](name,networkInterfaces[0].ipv6Address,networkInterfaces[0].ipv6AccessConfigs[0].externalIpv6)'

הפלט צריך לכלול את השמות של מופעי השרת ואת הקידומות שלהם ב-IPv6. פלט לדוגמה

server-instance1,fd20:3df:8d5c:0:0:0:0:0,
server-instance2,,2600:1900:4000:71fd:0:0:0:0

חשוב לרשום את שתי הכתובות, כי תצטרכו להשתמש בהן בהמשך בפקודות curl ממופע הלקוח. לצערנו, אי אפשר להשתמש בקלות במשתני סביבה כדי לאחסן את הערכים האלה, כי הם לא מועברים דרך סשנים של SSH.

הפעלת פקודת curl מהלקוח למופע של שרת ULA

כדי לראות את ההתנהגות לפני שמוסיפים מסלולים חדשים. מריצים פקודת curl ממופע הלקוח למופע השרת server-instance1.

ב-Cloud Shell, מתחברים למופע הלקוח:

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

בתוך מופע הלקוח, מבצעים curl באמצעות כתובת ה-ULA IPV6 של מופע server1 (הפקודה מגדירה זמן קצוב לתפוגה קצר של 5 שניות כדי למנוע מצב שבו curl ימתין יותר מדי זמן)

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

פקודת ה-curl הזו אמורה להגיע לזמן קצוב לתפוגה כי לרשת ה-VPC של הלקוח עדיין אין נתיב לרשת ה-VPC של השרת.

אנסה לעזור לך לפתור את הבעיה. יוצאים מהסשן של SSH.

הוספת מסלול מותאם אישית ב-VPC של הלקוח

כי חסר ברשת ה-VPC של הלקוח נתיב לקידומת ULA. נוסיף אותו עכשיו.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute routes create client-to-server1-route \
   --project=$projectname \
   --destination-range=$server_subnet1 \
   --network=client-vpc \
   --next-hop-instance=gateway-instance \
   --next-hop-instance-zone=us-central1-a

מתחברים באמצעות SSH בחזרה למופע הלקוח:

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

בתוך מופע הלקוח, מנסים שוב להשתמש בפקודת curl למופע השרת. (הפקודה מגדירה זמן קצוב לתפוגה קצר של 5 שניות כדי למנוע מצב שבו curl ימתין יותר מדי זמן)

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

פקודת curl הזו עדיין מובילה לפסק זמן כי ל-VPC של server1 עדיין אין נתיב חזרה ל-VPC של הלקוח דרך מופע השער.

כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

הוספת מסלול בהתאמה אישית ב-ULA Server VPC

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute routes create server1-to-client-route \
   --project=$projectname \
   --destination-range=$client_subnet \
   --network=server-vpc1 \
   --next-hop-instance=gateway-instance \
   --next-hop-instance-zone=us-central1-a

מתחברים באמצעות SSH בחזרה למופע הלקוח:

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

בתוך מופע הלקוח, מנסים שוב לשלוח את פקודת ה-curl למופע השרת.

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

עכשיו פקודת curl מצליחה, וזה אומר שיש לכם נגישות מקצה לקצה ממופע הלקוח למופע השרת של ULA. הקישוריות הזו אפשרית עכשיו רק באמצעות שימוש בנתיבים מותאמים אישית של IPv6 עם מופע של next-hop כ-next-hop.

פלט לדוגמה

<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 Server1!</h1></body></html>

כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

8. יצירה ובדיקה של מסלולים למופע של שער (באמצעות הכתובת של המופע)

בקטע הזה תוסיפו נתיבים לשני ה-VPC של הלקוח והשרת באמצעות כתובת ה-IPv6 של מופע השער כנקודת הניתוב הבאה.

מחיקת מסלולים קודמים

כדי לשחזר את הסביבה למצב שלפני הוספת נתיבים מותאמים אישית, צריך למחוק את הנתיבים המותאמים אישית שמשתמשים בשם המופע.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute routes delete client-to-server1-route  --quiet --project=$projectname
gcloud compute routes delete server1-to-client-route  --quiet --project=$projectname

הפעלת פקודת curl מהלקוח למופע של שרת ULA

כדי לוודא שהמסלולים הקודמים נמחקו בהצלחה, מריצים פקודת curl ממופע הלקוח אל server-instance1.

ב-Cloud Shell, מתחברים למופע הלקוח:

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

בתוך מופע הלקוח, מבצעים curl באמצעות כתובת ה-ULA IPV6 של מופע server1 (הפקודה מגדירה זמן קצוב לתפוגה קצר של 5 שניות כדי למנוע מצב שבו curl ימתין יותר מדי זמן)

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

פקודת ה-curl הזו אמורה להגיע לזמן קצוב לתפוגה (timeout) כי לרשת ה-VPC של הלקוח אין יותר נתיב לרשת ה-VPC של השרת.

קבלת כתובות IPv6 של מופע שער

כדי לכתוב מסלולים שמשתמשים בכתובת ה-hop הבא, צריך קודם לקבל את כתובות ה-IPv6 של מופע השער.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

export gateway_ula_address=$(gcloud compute instances \
   describe gateway-instance \
   --project $projectname  \
   --format='value(networkInterfaces[1].ipv6Address)')

export gateway_gua_address=$(gcloud compute instances \
   describe gateway-instance \
   --project $projectname  \
   --format='value(networkInterfaces[0].ipv6AccessConfigs[0].externalIpv6)')

הוספת מסלול מותאם אישית ב-VPC של הלקוח

עכשיו אפשר להוסיף מחדש את המסלול ב-VPC של הלקוח עם קידומת ULA, אבל במקום זאת להשתמש בכתובת GUA של השער כנקודת הניתוב הבאה.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute routes create client-to-server1-route \
   --project=$projectname \
   --destination-range=$server_subnet1 \
   --network=client-vpc \
   --next-hop-address=$gateway_gua_address

מתחברים באמצעות SSH בחזרה למופע הלקוח:

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

בתוך מופע הלקוח, מנסים שוב להשתמש בפקודת curl למופע השרת.

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

כצפוי, פקודת ה-curl הזו עדיין מובילה לפסק זמן כי ל-VPC של server1 עדיין אין נתיב חזרה ל-VPC של הלקוח דרך מופע השער.

כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

הוספת מסלול בהתאמה אישית ב-ULA Server VPC

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute routes create server1-to-client-route \
   --project=$projectname \
   --destination-range=$client_subnet \
   --network=server-vpc1 \
   --next-hop-address=$gateway_ula_address

מתחברים באמצעות SSH בחזרה למופע הלקוח:

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

בתוך מופע הלקוח, מנסים שוב לשלוח את פקודת ה-curl למופע השרת.

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

עכשיו פקודת curl מצליחה, וזה אומר שיש לכם נגישות מקצה לקצה ממופע הלקוח למופע השרת של ULA. הקישוריות הזו אפשרית עכשיו רק באמצעות שימוש בנתיבים מותאמים אישית של IPv6 עם כתובת ה-hop הבא כ-hops הבאים.

פלט לדוגמה

<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 Server1!</h1></body></html>

כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

9. יצירה ובדיקה של מסלול לשער אינטרנט

בזמן שאתם מגדירים את ה-Lab הזה, בואו נבדוק גם את הפונקציונליות של מאפיין ה-next-hop החדש: next-hop-gateway.

הפעלת פקודת curl מהלקוח למופע של שרת GUA

כדי לראות את ההתנהגות לפני שמוסיפים מסלולים חדשים. מריצים פקודת curl ממופע הלקוח אל כתובת ה-IP של server2.

ב-Cloud Shell, מתחברים למופע הלקוח:

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

בתוך מופע הלקוח, מבצעים curl לנקודת הקצה של IPv6

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

פקודת ה-curl הזו אמורה להגיע לזמן קצוב לתפוגה (timeout) כי לרשת ה-VPC של הלקוח יש רק נתיב של תת-רשת משלה ונתיב לרשת ה-VPC של server1. כדי להגיע לטווח כתובות ה-GUA של VPC server2, צריך להשתמש בשער האינטרנט שמוגדר כברירת מחדל דרך מסלול מותאם אישית.

כדי להמשיך ב-codelab, צריך לצאת מסשן ה-SSH.

הוספת נתיב שער מותאם אישית ב-VPC של הלקוח

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute routes create client-to-server2-route \
   --project=$projectname \
   --destination-range=$server_subnet2 \
   --network=client-vpc \
   --next-hop-gateway=default-internet-gateway

מתחברים באמצעות SSH בחזרה למופע הלקוח:

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

בתוך מופע הלקוח, חוזרים על אותה פקודת curl

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

פקודת curl הזו אמורה להצליח עכשיו ולהחזיר את הודעת ה-hello המותאמת אישית, מה שמצביע על כך שהצלחתם להגיע לכתובת ה-IPv6 של השרת השני דרך שער האינטרנט שמוגדר כברירת מחדל.

פלט לדוגמה:

<user id>@client-instance:~$ curl -m 5.0 -g -6 'http://[2600:1900:4000:71fd:0:0:0:0]:80/'
<!doctype html><html><body><h1>Hello World! From Server2!</h1></body></html>

יוצאים מהסשן של SSH כדי לעבור לקטע הניקוי של ה-Lab.

10. הסרת המשאבים

ניקוי המכונות

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute instances delete client-instance --zone us-central1-a --quiet --project=$projectname

gcloud compute instances delete server-instance1 --zone us-central1-a --quiet --project=$projectname

gcloud compute instances delete server-instance2 --zone us-central1-a --quiet --project=$projectname

gcloud compute instances delete gateway-instance --zone us-central1-a --quiet --project=$projectname

ניקוי תת-רשתות

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks subnets delete client-subnet --region=us-central1 --quiet --project=$projectname

gcloud compute networks subnets delete server-subnet1 --region=us-central1 --quiet --project=$projectname

gcloud compute networks subnets delete server-subnet2 --region=us-central1 --quiet --project=$projectname

ניקוי הכללים של חומת האש

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute firewall-rules delete allow-iap-client  --quiet --project=$projectname
gcloud compute firewall-rules delete allow-iap-server1  --quiet --project=$projectname
gcloud compute firewall-rules delete allow-iap-server2  --quiet --project=$projectname
gcloud compute firewall-rules delete allow-gateway-client  --quiet --project=$projectname
gcloud compute firewall-rules delete allow-client-server1  --quiet --project=$projectname
gcloud compute firewall-rules delete allow-client-server2  --quiet --project=$projectname

ניקוי של נתיבים מותאמים אישית

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute routes delete client-to-server1-route  --quiet --project=$projectname
gcloud compute routes delete client-to-server2-route  --quiet --project=$projectname
gcloud compute routes delete server1-to-client-route  --quiet --project=$projectname

ניקוי רשתות VPC

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks delete client-vpc --quiet --project=$projectname
gcloud compute networks delete server-vpc1 --quiet --project=$projectname
gcloud compute networks delete server-vpc2 --quiet --project=$projectname

11. מזל טוב

השתמשתם בהצלחה בנתיבי IPv6 סטטיים מותאמים אישית עם next-hops שהוגדרו ל-next-hop-gateway , ‏ next-hop-instance ו-next-hop-address. בנוסף, אימתתם תקשורת IPv6 מקצה לקצה באמצעות המסלולים האלה.

מה השלב הבא?

כדאי לעיין ב-Codelabs הבאים…

קריאה נוספת וסרטונים

מסמכי עזר