‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

1. מבוא

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

מה תלמדו

איך יוצרים מסלול מותאם אישית של IPv6 עם מכונת הצעד הבא של איזון עומסים פנימי על ידי ציון השם של איזון העומסים הפנימי
איך יוצרים מסלול מותאם אישית של IPv6 עם הצעד הבא next-hop-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 כוללת

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

כדי שרשת ה-VPC של הלקוח תוכל לגשת לשרת, תשתמשו בנתיב מותאם אישית עם next-hop-ilb שמצביע על ILB (באמצעות השם של ה-ILB) לפני קבוצה של מופעי שער multi-NIC, שנמצאים בין שני 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. יצירת מכונות שער

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

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

יצירת קבוצה של מופעי מכונה של שער עם multi-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 לאחת ממכונות השער

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

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

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

לחלופין, אפשר להפנות אל next-hop-ilb גם באמצעות השם של איזון העומסים במקום כתובת ה-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 הזו אמורה להגיע לזמן קצוב לתפוגה (timeout) כי ל-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניקוי רשתות VPC

10. מזל טוב

מה השלב הבא?

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

מסמכים לדוגמה