Private Service Connect 66

1. מבוא

Private Service Connect משנה את האופן שבו ארגונים צורכים שירותים בסביבה העסקית של Google Cloud, ומספק תמיכה מלאה בכתוביות IPv6 לצד IPv4. הוא משלב אבטחה משופרת, קישוריות פשוטה, ביצועים משופרים וניהול מרוכז, והוא פתרון אידיאלי לעסקים שמחפשים מודל יעיל, אמין וחזק לצריכת שירותים, מודל שעומד בדרישות העתיד של הרשתות. בין שאתם יוצרים ענן היברידי, משתפים שירותים בארגון או ניגשים לשירותים של צד שלישי, PSC מציע דרך חלקה ומאובטחת לנצל את מלוא הפוטנציאל של Google Cloud, תוך ניצול היתרונות של IPv6.

מה תלמדו

• היתרונות העיקריים של PSC 66
• תרגום נתמך של Private Service Connect 66
• סקירה כללית על ULA ב-Dual Stack
• דרישות הרשת
• יצירת שירות הפקה ב-Private Service Connect
• יצירת נקודת קצה מסוג Private Service Connect
• יצירת קישוריות לנקודת הקצה של Private Service Connect ממכונה וירטואלית עם שתי ערימות

מה צריך להכין

• פרויקט ב-Google Cloud עם הרשאות בעלים

2. מה תפַתחו

תיצורו רשת ייעודית לבעלים של שירות מנוהל כדי לפרוס שרת אינטרנט של Apache כשירות שפורסם דרך Private Service Connect ‏ (PSC). אחרי הפרסום, עליכם לבצע את הפעולות הבאות כדי לאמת את הגישה לשירות של הבעלים:

• מ-VPC של צרכן, מכונה וירטואלית של GCE עם שתי ערימות (dual-stack), מטרגטים את נקודת הקצה (endpoint) של PSC ב-IPv6 כדי להגיע לשירות של היצרן.

היתרונות העיקריים של PSC 66

• שילוב חלק: PSC משתלב בצורה חלקה עם רשתות VPC שמוגדרות ל-IPv6, ומאפשר לכם ליהנות מהיתרונות של כתובות IPv6 בקישורי השירות.
• תמיכה בשכבת כפולה: PSC תומך בהגדרות של שכבת כפולה, ומאפשר שימוש בו-זמנית ב-IPv4 וב-IPv6 באותו VPC, כך שהרשת שלכם תהיה גמישה ומותאמת לעתיד.
• מעבר פשוט יותר: PSC מפשט את המעבר ל-IPv6 ומאפשר לכם לאמץ את IPv6 בהדרגה לצד התשתית הקיימת של IPv4.
• תמיכה בבעלים: הבעלים חייבים להשתמש בשכבת תמיכה כפולה, וכתוצאה מכך נוצר נקודת קצה של PSC לצרכן ב-IPv6 בלבד.

3. תמיכה בתרגום של Private Service Connect 64 ו-66

שיקולים לגבי הצרכנים

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

שיקולים ליוצרי תוכן

גרסת ה-IP של כלל ההעברה של הבעלים של השירות קובעת את גרסת ה-IP של הקובץ המצורף עם השירות ואת התעבורה היוצאת מהקובץ המצורף עם השירות. גרסת ה-IP של צירוף השירות יכולה להיות IPv4 או IPv6, אבל לא את שניהם. יוצרים יכולים להשתמש בכתובת IPv4 אם תת-הרשת של הכתובת היא סטאק יחיד. יוצרים יכולים להשתמש בכתובת IPv4 או IPv6 אם תת-הרשת של הכתובת היא dual-stack.

גרסת ה-IP של כתובת ה-IP של כלל ההעברה של הבעלים צריכה להיות תואמת לסוג הסטאק של תת-הרשת של NAT של צירוף השירות.

• אם כלל ההעברה של הבעלים הוא IPv4, תת-הרשת של NAT יכולה להיות עם סטאק יחיד או עם סטאק כפול.
• אם כלל ההעברה של הבעלים הוא IPv6, תת-הרשת של NAT חייבת להיות עם שתי שכבות.

השילובים הנתמכים הם:

• צירוף של נקודת קצה IPv4 לשירות IPv4
• צירוף של נקודת קצה IPv6 לשירות IPv6
• צירוף של נקודת קצה מסוג IPv6 לשירות מסוג IPv4. בתצורה הזו, Private Service Connect מתרגם באופן אוטומטי בין שתי גרסאות ה-IP.

אין תמיכה בתכונות הבאות:

ב-Private Service Connect אין תמיכה בחיבור של נקודת קצה מסוג IPv4 לקובץ מצורף עם שירות מסוג IPv6. במקרה כזה, יצירת נקודת הקצה נכשלת עם הודעת השגיאה הבאה:

כלל העברה של Private Service Connect עם כתובת IPv4 לא יכול לטרגט קובץ מצורף של שירות IPv6.

4. סקירה כללית על ULA ב-Dual Stack

ב-Google Cloud יש תמיכה ביצירה של תת-רשתות IPv6 פרטיות מסוג ULA ומכונות וירטואליות. ב-RFC 4193 מוגדר סכימה של כתובות IPv6 לתקשורת מקומית, שמתאימה במיוחד לתקשורת בתוך VPC. אי אפשר לנתב כתובות ULA באופן גלובלי, ולכן המכונות הווירטואליות מבודדות לחלוטין מהאינטרנט ומספקות התנהגות דומה ל-RFC-1918 באמצעות IPv6. ב-Google Cloud אפשר ליצור תחילית ULA של רשת VPC ב-/48, כך שכל תת-הרשתות של ULA IPv6 ב-/64 יוקצו מטווח הרשת של VPC.

בדומה לכתובות IPv6 חיצוניות ייחודיות גלובליות שנתמכות ב-Google Cloud, כל תת-רשת שתומכת ב-ULA IPv6 תקבל תת-רשת ‎ /64 מטווח ה-ULA של רשת ה-VPC ‎ /48, וכל מכונה וירטואלית תקבל כתובת ‎ /96 מתת-הרשת הזו.

ב-RFC4193 מוגדר מרחב כתובות IPv6 בטווח fc00::/7. אפשר להקצות כתובות ULA ולהשתמש בהן באופן חופשי ברשתות או באתרים פרטיים. Google Cloud מקצה את כל כתובות ה-ULA מטווח fd20::/20. אפשר לנתב את הכתובות האלה רק במסגרת רשתות VPC, ולא ניתן לנתב אותן באינטרנט הגלובלי של IPv6.

כתובות ULA שהוקצו על ידי Google Cloud הן ייחודיות בכל רשתות ה-VPC. מערכת Google Cloud מוודאת שאף שתי רשתות VPC לא יקבלו את אותה קידומת ULA. כך ניתן למנוע את הבעיה של טווחים חופפים ברשתות VPC.

אתם יכולים לאפשר ל-Google Cloud להקצות באופן אוטומטי את /48 לרשת שלכם, או לבחור קידומת ספציפית של IPv6 /48. אם תחילית ה-IPv6 שציינתם כבר הוקצה ל-VPC אחר או ברשת המקומית, תוכלו לבחור טווח אחר.

ב-codelab, Google Cloud תקצה באופן אוטומטי /48, וכתוצאה מכך תקבלו טווח כתובות ULA ייחודי גלובלי.

5. דרישות הרשת

בהמשך מפורטות דרישות הרשת לרשת הצרכנים ולרשת היוצרים:

רשת הצרכן (כל הרכיבים נפרסו ב-us-central1)

רכיבים	תיאור
VPC	כדי להשתמש ברשתות עם שתי שכבות צריך VPC במצב מותאם אישית עם ULA מופעל
נקודת קצה של PSC	נקודת קצה (endpoint) של PSC ב-IPV6 שמשמשת לגישה לשירות ה-Producer
רשתות משנה	שתי שכבות
GCE	שתי שכבות

רשת הבעלים(כל הרכיבים נפרסו ב-us-central1)

רכיבים	תיאור
VPC	כדי להשתמש ברשתות עם שתי שכבות צריך VPC במצב מותאם אישית עם ULA מופעל
PSC NAT Subnet	שתי שכבות. חבילות מרשת ה-VPC של הצרכן מתרגמות באמצעות NAT מקור (SNAT), כך שכתובות ה-IP המקוריות שלהן מומרות לכתובות IP מקור מתת-הרשת של NAT ברשת ה-VPC של היצרן.
כלל העברה של PSC	שתי שכבות. מאזן עומסי רשת פנימי מסוג passthrough
בדיקת תקינות	כלל תעבורת נתונים נכנסת (ingress) שרלוונטי למכונות שמאזן העומסים מאזן עליהן, שמאפשר תעבורת נתונים ממערכות בדיקת התקינות של Google Cloud‏ (2600:2d00:1:b029::/64).
שירות לקצה העורפי	שירות לקצה העורפי משמש כגשר בין מאזן העומסים לבין המשאבים בקצה העורפי. במדריך, שירות הקצה העורפי משויך לקבוצת המכונות הלא מנוהלות.
קבוצת מופעים לא מנוהלת	תמיכה במכונות וירטואליות שדורשות הגדרה או כוונון אישיים. אין תמיכה בשימוש אוטומטי ב-Cloud TPU.

6. טופולוגיית ה-Codelab

7. הגדרה ודרישות

הגדרת סביבה בקצב אישי

1. נכנסים למסוף Google Cloud ויוצרים פרויקט חדש או משתמשים מחדש בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או חשבון Google Workspace, עליכם ליצור חשבון.

• שם הפרויקט הוא השם המוצג של המשתתפים בפרויקט. זוהי מחרוזת תווים שלא משמשת את Google APIs. תמיד תוכלו לעדכן אותו.
• מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שמגדירים אותו. מסוף Cloud יוצר מחרוזת ייחודית באופן אוטומטי. בדרך כלל לא משנה מה המחרוזת הזו. ברוב ה-codelabs תצטרכו להפנות למזהה הפרויקט (בדרך כלל מזהים אותו בתור PROJECT_ID). אם המזהה שנוצר לא מוצא חן בעיניכם, תוכלו ליצור מזהה אקראי אחר. לחלופין, אפשר לנסות כתובת משלכם ולבדוק אם היא זמינה. לא ניתן לשנות את השם אחרי השלב הזה, והוא יישאר למשך כל פרק הזמן של הפרויקט.
• לידיעתכם, יש ערך שלישי, מספר פרויקט, שחלק מממשקי ה-API משתמשים בו. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי העזרה.

שימו לב: מזהה הפרויקט הוא ייחודי גלובלי, ואף אחד אחר לא יוכל להשתמש בו אחרי שתבחרו בו. אתם היחידים שמשתמשים במזהה הזה. גם אם מוחקים פרויקט, אי אפשר להשתמש שוב במזהה שלו

הערה: אם אתם משתמשים בחשבון Gmail, תוכלו להשאיר את מיקום ברירת המחדל כפי שהוא – ללא ארגון. אם אתם משתמשים בחשבון Google Workspace, בחרו מיקום שמתאים לארגון שלכם.

2. בשלב הבא, כדי להשתמש במשאבים או ב-API של Cloud, תצטרכו להפעיל את החיוב במסוף Cloud. השלמת הקודלאב הזה לא תעלה הרבה, אם בכלל. כדי להשבית את המשאבים ולמנוע חיובים אחרי סיום המדריך, אפשר למחוק את המשאבים שיצרתם או למחוק את הפרויקט. משתמשים חדשים ב-Google Cloud זכאים להשתתף בתוכנית תקופת ניסיון בחינם בסך 300$.

הפעלת Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל בסדנת הקוד הזו נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת ב-Cloud.

במסוף Google Cloud, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:

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

המכונה הווירטואלית הזו כוללת את כל הכלים הדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, משפרת מאוד את ביצועי הרשת ואת האימות. אתם יכולים לבצע את כל העבודה בקודלאב הזה בדפדפן. אין צורך להתקין שום דבר.

8. לפני שמתחילים

הפעלת ממשקי API

ב-Cloud Shell, מוודאים שמזהה הפרויקט מוגדר:

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=us-central1
echo $project
echo $region

מפעילים את כל השירותים הנדרשים:

gcloud services enable compute.googleapis.com

9. יצירת רשת VPC של יוצר

רשת VPC

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

gcloud compute networks create producer-vpc --subnet-mode custom --enable-ula-internal-ipv6

Google מקצה רשת משנה ייחודית ברמה הגלובלית בגודל /48 ל-VPC של הצרכן. כדי להציג את ההקצאה:

במסוף Cloud, עוברים אל:

רשתות VPC

יצירת תת-רשתות

תת-הרשת של PSC תשויך לקובץ המצורף של השירות ב-PSC לצורך תרגום כתובות רשת (NAT). בתרחישי לדוגמה בסביבת הייצור, צריך להגדיר את תת-הרשת הזו בהתאם כדי לתמוך בכמות התנועה הנכנסת מכל נקודות הקצה של PSC המצורפות. מידע נוסף זמין במסמכי התיעוד בנושא הגדרת גודל של תת-רשת NAT ב-PSC.

יוצרים ב-Cloud Shell את תת-הרשת של NAT ב-PSC:

gcloud compute networks subnets create producer-nat-dual-stack-subnet --network producer-vpc --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL

בשלב מאוחר יותר תצטרכו לקבל ולתעד את כתובת ה-IPv6 של producer-nat-dual-stack-subnet, שתשמש ליצירת כלל חומת אש נכנסת כדי לאפשר ל-PSC NAT subnet גישה לקצה העורפי של מאזן העומסים.

הערה: הערך של IPv6 ישתנה כי כתובות IPv6 ULA הן ייחודיות ברמה הגלובלית.

ב-Cloud Shell, מקבלים את תת-הרשת של PSC NAT IPv6.

gcloud compute networks subnets describe producer-nat-dual-stack-subnet --region=us-central1 | grep -i internalIpv6Prefix:

התוצאה הצפויה:

user@cloudshell$ gcloud compute networks subnets describe producer-nat-dual-stack-subnet --region=us-central1 | grep -i internalIpv6Prefix:
internalIpv6Prefix: fd20:b4a:ea9f:2:0:0:0:0/64

יוצרים ב-Cloud Shell את תת-הרשת של כלל ההעברה של הבעלים:

gcloud compute networks subnets create producer-dual-stack-fr-subnet --network producer-vpc --range 172.16.20.0/28 --region $region --enable-private-ip-google-access --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL

יוצרים ב-Cloud Shell את תת-הרשת של המכונה הווירטואלית של הבעלים:

gcloud compute networks subnets create producer-dual-stack-vm-subnet --network producer-vpc --range 172.16.30.0/28 --region $region --enable-private-ip-google-access --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL

יצירת שער NAT ציבורי

למכונה הווירטואלית של הבעלים נדרש חיבור לאינטרנט כדי להוריד את Apache, אבל למכונה של GCE אין כתובת IP חיצונית. לכן, Cloud NAT יספק תעבורת נתונים יוצאת (egress) לאינטרנט להורדת החבילה.

יוצרים את Cloud Router ב-Cloud Shell:

gcloud compute routers create producer-cloud-router --network producer-vpc --region us-central1

ב-Cloud Shell, יוצרים את שער Cloud NAT שמאפשר תעבורת נתונים יוצאת (egress) לאינטרנט:

gcloud compute routers nats create producer-nat-gw --router=producer-cloud-router --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1

יצירת מדיניות חומת אש ברשת וכללי חומת אש

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

gcloud compute network-firewall-policies create producer-vpc-policy --global

gcloud compute network-firewall-policies associations create --firewall-policy producer-vpc-policy --network producer-vpc --name producer-vpc --global-firewall-policy

כדי לאפשר ל-IAP להתחבר למכונות הווירטואליות, יוצרים כלל של חומת אש שמאפשר:

• רלוונטי לכל מכונות ה-VM שרוצים לגשת אליהן באמצעות IAP.
• הכלל מאפשר תעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP 35.235.240.0/20. הטווח הזה מכיל את כל כתובות ה-IP שמשמשות את IAP להעברת TCP.

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

gcloud compute network-firewall-policies rules create 1000 --action ALLOW --firewall-policy producer-vpc-policy --description "SSH with IAP" --direction INGRESS --src-ip-ranges 35.235.240.0/20 --layer4-configs tcp:22  --global-firewall-policy

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

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

gcloud compute network-firewall-policies rules create 2000 --action ALLOW --firewall-policy producer-vpc-policy --description "allow traffic from health check probe range" --direction INGRESS --src-ip-ranges 2600:2d00:1:b029::/64 --layer4-configs tcp:80 --global-firewall-policy

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

מעדכנים את כלל חומת האש <insert-your-psc-nat-ipv6-subnet> עם תת-הרשת של IPv6 PSC NAT שהתקבלה מוקדם יותר בקודלאב.

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

gcloud compute network-firewall-policies rules create 2001 --action ALLOW --firewall-policy producer-vpc-policy --description "allow traffic from PSC NAT subnet" --direction INGRESS --src-ip-ranges <insert-your-psc-nat-ipv6-subnet> --global-firewall-policy --layer4-configs=tcp

יצירת המכונה הווירטואלית של הבעלים

יוצרים ב-Cloud Shell את שרת האינטרנט של apache-vm:

gcloud compute instances create producer-vm \
    --project=$project \
    --machine-type=e2-micro \
    --image-family debian-12 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=producer-dual-stack-vm-subnet \
    --stack-type=IPV4_IPV6 \
    --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install apache2 -y
      sudo service apache2 restart
      echo 'Welcome to Producer-VM !!' | tee /var/www/html/index.html
      EOF"

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

gcloud compute instance-groups unmanaged create producer-instance-group --zone=us-central1-a

gcloud compute instance-groups unmanaged add-instances producer-instance-group  --zone=us-central1-a --instances=producer-vm

gcloud compute health-checks create http hc-http-80 --port=80

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

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

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

gcloud compute backend-services create producer-backend-svc --load-balancing-scheme=internal --protocol=tcp --region=us-central1 --health-checks=hc-http-80

gcloud compute backend-services add-backend producer-backend-svc --region=us-central1 --instance-group=producer-instance-group --instance-group-zone=us-central1-a

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

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

gcloud compute addresses create producer-fr-ipv6-address \
    --region=us-central1 \
    --subnet=producer-dual-stack-fr-subnet \
    --ip-version=IPV6

בסינטקס הבא, יוצרים כלל העברה (מאזן עומסים של רשת פנימית) עם כתובת IPv6 מוגדרת מראש producer-fr-ipv6-address שמשויכת לשירות הקצה העורפי, producer-backend-svc

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

gcloud compute forwarding-rules create producer-fr --region=us-central1 --load-balancing-scheme=internal --network=producer-vpc --subnet=producer-dual-stack-fr-subnet --address=producer-fr-ipv6-address --ip-protocol=TCP --ports=all --backend-service=producer-backend-svc --backend-service-region=us-central1 --ip-version=IPV6

יצירת צירוף לשירות

יוצרים את Service Attachment ב-Cloud Shell:

gcloud compute service-attachments create ipv6-producer-svc-attachment --region=$region --producer-forwarding-rule=producer-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-nat-dual-stack-subnet

בשלב הבא, מקבלים את הקובץ המצורף של השירות שמופיע ב-URI של selfLink שמתחיל ב-projects, ומתעדים אותו כדי להגדיר את נקודת הקצה של PSC בסביבת הצרכן.

selfLink: projects/<your-project-id>/regions/us-central1/serviceAttachments/ipv4-producer-svc-attachment

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

gcloud compute service-attachments describe ipv6-producer-svc-attachment --region=$region

דוגמה לפלט הצפוי

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2024-08-27T05:59:17.188-07:00'
description: ''
enableProxyProtocol: false
fingerprint: EaultrFOzc4=
id: '8752850315312657226'
kind: compute#serviceAttachment
name: ipv6-producer-svc-attachment
natSubnets:
- https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1/subnetworks/producer-nat-dual-stack-subnet
pscServiceAttachmentId:
  high: '1053877600257000'
  low: '8752850315312657226'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1/serviceAttachments/ipv6-producer-svc-attachment
targetService: https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1/forwardingRules/producer-fr

במסוף Cloud, עוברים אל:

Network Services‏ → Private Service Connect‏ → Published Services

11. יצירת רשת VPC של צרכן

רשת VPC

ב-Cloud Shell, יוצרים את VPC של הצרכן עם IPv6 ULA מופעל:

gcloud compute networks create consumer-vpc \
    --subnet-mode=custom \
    --enable-ula-internal-ipv6

Google מקצה רשת משנה ייחודית ברמה הגלובלית בגודל /48 ל-VPC של הצרכן. כדי להציג את ההקצאה:

במסוף Cloud, עוברים אל:

רשתות VPC

יצירת תת-רשת

ב-Cloud Shell, יוצרים את תת-הרשת של GCE בשכבת התשתית הכפולה:

gcloud compute networks subnets create consumer-dual-stack-subnet --network consumer-vpc --range=192.168.20.0/28 --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL --region $region --enable-private-ip-google-access

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

gcloud compute networks subnets create psc-dual-stack-endpoint-subnet --network consumer-vpc --range=192.168.21.0/28 --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL --region $region --enable-private-ip-google-access

יצירת מדיניות חומת אש ברשת וכללי חומת אש

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

gcloud compute network-firewall-policies create consumer-vpc-policy --global

gcloud compute network-firewall-policies associations create --firewall-policy consumer-vpc-policy --network consumer-vpc --name consumer-vpc --global-firewall-policy

gcloud compute network-firewall-policies rules create 1000 --action ALLOW --firewall-policy consumer-vpc-policy --description "SSH with IAP" --direction INGRESS --src-ip-ranges 35.235.240.0/20 --layer4-configs tcp:22  --global-firewall-policy

ברשת של הצרכן נדרשת רק גישה ל-SSH דרך IAP.

12. יצירת מכונה וירטואלית, נקודת קצה מסוג PSC ובדיקת קישוריות בשכבת TCP/IP כפולה

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

ב-Cloud Shell, יוצרים את המכונה של GCE בשכבת התשתית הכפולה ברשת המשנה בשכבת התשתית הכפולה:

gcloud compute instances create consumer-vm-ipv4-ipv6 --zone=us-central1-a --subnet=consumer-dual-stack-subnet --no-address --stack-type=IPV4_IPV6

יצירת כתובת IPv6 סטטית של נקודת קצה מסוג PSC

ב-Cloud Shell, יוצרים כתובת IPv6 סטטית לנקודת הקצה של PSC:

gcloud compute addresses create psc-ipv6-endpoint-ip --region=$region --subnet=psc-dual-stack-endpoint-subnet --ip-version=IPV6

איך מקבלים את כתובת ה-IPv6 הסטטית של נקודת הקצה מסוג PSC

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

gcloud compute addresses describe psc-ipv6-endpoint-ip --region=us-central1 | grep -i address:

הערה: הערך של IPv6 ישתנה כי כתובות IPv6 ULA הן ייחודיות ברמה הגלובלית.

פלט לדוגמה:

user@cloudshell$ gcloud compute addresses describe psc-ipv6-endpoint-ip --region=us-central1 | grep -i address:
address: 'fd20:799:4ea3:1::'

יצירת נקודת הקצה של PSC ב-IPv6

ב-Cloud Shell, יוצרים את נקודת הקצה (endpoint) של PSC על ידי עדכון מזהה ה-URI של SERVICE ATTACHMENT במזהה ה-URI שצילמתם כשיצרתם את Service Attachment.

gcloud compute forwarding-rules create psc-ipv6-endpoint --region=$region --network=consumer-vpc --address=psc-ipv6-endpoint-ip --target-service-attachment=[SERVICE ATTACHMENT URI]

אימות נקודת הקצה של PSC

עליכם לוודא שהבעלים של ה-PSC אישר את נקודת הקצה. במסוף Cloud, עוברים אל:

Network Services‏ (שירותי רשת) → Private Service Connect‏ (Private Service Connect) → Connected Endpoints (נקודות קצה מחוברות)

בדיקת הקישוריות

ב-Cloud Shell, מתחברים באמצעות SSH למכונה של GCE עם שתי ערימות (dual-stack), consumer-vm-ipv4-ipv6.

gcloud compute ssh --zone us-central1-a "consumer-vm-ipv4-ipv6" --tunnel-through-iap --project $project

עכשיו, אחרי שנכנסתם למכונה של GCE בשכבת תאומים, מריצים את הפקודה curl לנקודת הקצה של PSC, psc-ipv6-endpoint, באמצעות כתובות ה-IPv6 שזוהו בשלב הקודם.

curl -6 http://[insert-your-ipv6-psc-endpoint]

הפלט אמור להיראות כך:

user@consumer-vm-ipv4-ipv6$ curl -6 http://[fd20:799:4ea3:1::]
Welcome to Producer-VM !!

בתוך המכונה הווירטואלית consumer-vm-ipv4-ipv6 ב-GCE, יוצאים מהמכונה באמצעות exit כדי לחזור ל-Cloud Shell.

exit

הפלט אמור להיראות כך:

user@consumer-vm-ipv4-ipv6:~$ exit
logout
Connection to compute.715101668351438678 closed.

13. שלבי הניקוי

מחיקת רכיבי מעבדה ממסוף Cloud Shell אחד

gcloud compute forwarding-rules delete psc-ipv6-endpoint --region=us-central1 -q

gcloud compute instances delete consumer-vm-ipv4-ipv6 --zone=us-central1-a -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy=consumer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=consumer-vpc-policy  --name=consumer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete consumer-vpc-policy --global -q

gcloud compute addresses delete psc-ipv6-endpoint-ip --region=us-central1 -q

gcloud compute networks subnets delete consumer-dual-stack-subnet psc-dual-stack-endpoint-subnet --region=us-central1 -q

gcloud compute networks delete consumer-vpc -q

gcloud compute service-attachments delete ipv6-producer-svc-attachment --region=us-central1 -q

gcloud compute forwarding-rules delete producer-fr --region=us-central1 -q

gcloud compute backend-services delete producer-backend-svc --region=us-central1 -q

gcloud compute health-checks delete hc-http-80 -q

gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy  --name=producer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete producer-vpc-policy --global -q

gcloud compute instance-groups unmanaged delete producer-instance-group --zone=us-central1-a -q

gcloud compute instances delete producer-vm --zone=us-central1-a -q

gcloud compute routers nats delete producer-nat-gw --router=producer-cloud-router --router-region=us-central1 -q

gcloud compute routers delete producer-cloud-router --region=us-central1 -q

gcloud compute addresses delete producer-fr-ipv6-address --region=us-central1 -q

gcloud compute networks subnets delete producer-dual-stack-fr-subnet  producer-dual-stack-vm-subnet producer-nat-dual-stack-subnet --region=us-central1 -q

gcloud compute networks delete producer-vpc -q

14. מזל טוב

מזל טוב, הגדרתם ואימתתם את Private Service Connect 64.

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

Cosmopup חושב שהקורסים של Codelab הם מדהימים!!

מה השלב הבא?

כדאי לעיין בחלק מהקורסים האלה ב-Codelab…

• שימוש ב-Private Service Connect לפרסום ולצריכה של שירותים באמצעות GKE
• שימוש ב-Private Service Connect לפרסום ולצריכה של שירותים
• התחברות לשירותים מקומיים דרך Hybrid Networking באמצעות Private Service Connect ומאזן עומסים פנימי של שרת TCP Proxy
• גישה לכל ה-codelabs שפורסמו בנושא Private Service Connect

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

• סקירה כללית על Private Service Connect

• סוגי מאזני העומסים הנתמכים

מסמכי עזר

• תרגום של גרסאות IP
• תמיכה ב-IPv6
• סקירה כללית על מאזן עומסים פנימי מסוג passthrough
• סקירה כללית על בדיקות תקינות
• איך מפרסמים שירות באמצעות Private Service Connect