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

1. מבוא

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

מה תלמדו

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

הדרישות

פרויקט ב-Google Cloud

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

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

ב-Codelab הזה נעשה שימוש במשתנים (‎ $variables) כדי להקל על הטמעת ההגדרה של 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 כוללת

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

כדי ש-VPC של הלקוח יוכל לגשת לשרת, תשתמשו בנתיב מותאם אישית עם next-hop-ilb שמצביע על ILB (באמצעות השם של ה-ILB) לפני קבוצה של מכשירי שער עם כמה כרטיסי רשת, שנמצאים בין שני ILB. כדי לספק ניתוב חזרה למופע הלקוח (אחרי מחיקת מסלול ברירת המחדל ::‎/0), תשתמשו במסלול מותאם אישית עם next-hop-ilb (באמצעות הכתובת של ILB) שמצביע על ILB.

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

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

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

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

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

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

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

export client_subnet=$(gcloud compute networks subnets \
    describe client-subnet \
    --project $projectname \
    --format="value(internalIpv6Prefix)" \
    --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 של השרת

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

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

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

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

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

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

מריצים את הפקודה הבאה כדי להקליט את רשת המשנה שהוקצתה במשתנה סביבה

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

הפעלת מכונת VM של שרת

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

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

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

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

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

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

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

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

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

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

gcloud compute ssh server-instance \
    --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 Server Instance!</h1></body></html>' | sudo tee /var/www/html/index.html

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

5. יצירת מופעים של שערים

יצירת תבנית של הגדרות מכונה של שער עם כמה כרטיסי רשת

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

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'

יצירת קבוצה של מופעי מכונה של שער עם כמה כרטיסי NIC

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

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

אימות של מופעי שער

כדי לוודא שסקריפט לטעינה בזמן ההפעלה שלנו הועבר בצורה נכונה ושטבלת הניתוב v6 תקינה. SSH to one of the gateway instances

ב-Cloud Shell, מריצים את הפקודה הבאה כדי לראות את רשימת מופעי השער:

gcloud compute instances list \
    --project=$projectname \
    --zones=us-central1-a \
    --filter name~gateway \
    --format 'csv(name)'

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

ב-Cloud Shell, מתחברים לאחת ממכונות השער.

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

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

sudo sysctl net.ipv6.conf.all.forwarding

הפקודה צריכה להחזיר את הערך '1', שמציין שהעברת IPv6 מופעלת.

אימות טבלת הניתוב של 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.

6. יצירת רכיבים של מאזן עומסים

כדי ליצור מסלולים בשני ה-VPC, צריך ליצור מאזני עומסים פנימיים מסוג passthrough בשני הצדדים של מופעי השער כדי להעביר את תעבורת הנתונים.

מאזני העומסים שנוצרו ב-Codelab הזה מורכבים מ

בדיקת תקינות: ב-Codelab הזה ניצור בדיקות תקינות פשוטות שמכוונות ליציאה 22. שימו לב שבדיקות התקינות לא יפעלו כמו שהן פרוסות (כדי שהן יפעלו צריך להוסיף כללים לחומת האש כדי לאפשר בדיקות תקינות וליצור מסלולים מיוחדים במופעי השער). מכיוון שה-Codelab הזה מתמקד בהעברת IPv6, נסתמך על התנהגות ברירת המחדל של מאזני עומסים פנימיים מסוג pass-through בנוגע לחלוקת התעבורה כשכל הקצוות העורפיים לא תקינים, כלומר, העברה לכל הקצוות העורפיים כמוצא אחרון.
שירות קצה עורפי: נשתמש בפרוטוקול TCP לשירות הקצה העורפי. אבל מאחר שמאזני העומסים נוצרים למטרות ניתוב, כל הפרוטוקולים מועברים בלי קשר לפרוטוקול של השירות לקצה העורפי.
כלל העברה: אנחנו יוצרים כלל העברה לכל VPC .
כתובת IPv6 פנימית: ב-Codelab הזה, נגדיר שכלל ההעברה יקצה כתובות IPv6 באופן אוטומטי מרשת המשנה

יצירת בדיקת תקינות

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

gcloud compute health-checks create tcp tcp-hc-22 \
    --project=$projectname \
    --region=us-central1 \
    --port=22

יצירת שירותים לקצה העורפי

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

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

הוספה של קבוצת מופעים לשירות Backend

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

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

יצירת כללי העברה

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

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

כדי לתעד את כתובות ה-IPv6 של שני כללי ההעברה, מריצים את הפקודות הבאות ב-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. יצירה ובדיקה של נתיבים למאזני עומסים (באמצעות כתובת מאזן העומסים)

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

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

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

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

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

server-instance,fd20:3df:8d5c:0: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 הזו אמורה להגיע לזמן קצוב לתפוגה כי ל-Client VPC עדיין אין נתיב ל-Server VPC.

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

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

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

הערה: למאזני עומסים פנימיים מסוג העברת סיגנל ללא שינוי ב-IPv6 מוקצות כתובות ‎ /96. צריך להסיר את המסכה ‎ /96 מהכתובת לפני שמעבירים אותה לפקודה הבאה. (בהמשך מוסבר על החלפה במקום ב-bash)

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

gcloud compute routes create client-to-server-route \
   --project=$projectname \
   --destination-range=$server_subnet \
   --network=client-vpc \
   --next-hop-ilb=${fraddress_client//\/96}

מתחברים באמצעות 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 של השרת עדיין אין נתיב חזרה ל-VPC של הלקוח דרך מופע השער.

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

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

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

gcloud compute routes create server-to-client-route \
   --project=$projectname \
   --destination-range=$client_subnet \
   --network=server-vpc \
  --next-hop-ilb=${fraddress_server//\/96}

מתחברים באמצעות 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 עם איזון עומסים פנימי של הצעד הבא בתור הצעדים הבאים.

פלט לדוגמה

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

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

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

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

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

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

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

gcloud compute routes delete client-to-server-route  --quiet --project=$projectname
gcloud compute routes delete server-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 -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

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

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

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

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

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

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

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

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

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

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

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

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

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

ניקוי רכיבי איזון עומסים

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

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

ניקוי מכונות ותבניות של הגדרות מכונה

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

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

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

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

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

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

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

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

ניקוי רשתות VPC

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

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

10. מזל טוב

השתמשתם בהצלחה במסלולי IPv6 סטטיים מותאמים אישית עם קפיצות ביניים שהוגדרו ל-next-hop-ilb. בנוסף, אימתתם תקשורת IPv6 מקצה לקצה באמצעות המסלולים האלה.

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

1. מבוא

מה תלמדו

הדרישות

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

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

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

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

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

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

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

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

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

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

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

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

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

הפעלת מכונת VM של שרת

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

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

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

5. יצירת מופעים של שערים

יצירת תבנית של הגדרות מכונה של שער עם כמה כרטיסי רשת

יצירת קבוצה של מופעי מכונה של שער עם כמה כרטיסי NIC

אימות של מופעי שער

6. יצירת רכיבים של מאזן עומסים

יצירת בדיקת תקינות

יצירת שירותים לקצה העורפי

הוספה של קבוצת מופעים לשירות Backend

יצירת כללי העברה

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

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

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

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

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

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

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

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

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

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

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

ניקוי רכיבי איזון עומסים

ניקוי מכונות ותבניות של הגדרות מכונה

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

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

ניקוי רשתות VPC

10. מזל טוב

מה השלב הבא?

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

מסמכי עזר