Private Service Connect 64

1. מבוא

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

מה תלמדו

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

מה תצטרכו

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

2. מה תפַתחו

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

• מ-VPC של הצרכן, מופע GCE של IPv4, מכוונים לנקודת הקצה של PSC מסוג IPv4 כדי להגיע לשירות של היצרן.
• מ-VPC של הצרכן, מופע GCE עם סטאק כפול, מכוונים לנקודת הקצה של PSC מסוג IPv6 כדי להגיע לשירות של היצרן.

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

• שילוב חלק: ‏PSC משתלב בצורה חלקה עם רשתות VPC שהוגדרו ל-IPv6, ומאפשר לכם ליהנות מהיתרונות של כתובות IPv6 בחיבורי השירות שלכם.
• תמיכה בסטאק כפול:‏ PSC תומך בהגדרות של סטאק כפול, ומאפשר שימוש בו-זמני ב-IPv4 וב-IPv6 באותו VPC. כך מתקבלת גמישות והרשת מוכנה לשימוש עתידי.
• מעבר פשוט: PSC מאפשר מעבר פשוט ל-IPv6, כי אפשר להטמיע את IPv6 בהדרגה לצד תשתית IPv4 הקיימת.
• תמיכה ב-Producer: לא נדרש מ-Producer לאמץ dual-stack, במקום זאת ל-Consumer יש אפשרות לפרוס נקודת קצה (endpoint) של PSC מסוג IPv4 או IPv6.

3. תרגום נתמך של Private Service Connect 64 ו-66

שיקולים של צרכנים

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

שיקולים להפקה

גרסת ה-IP של כלל ההעברה של הבעלים של השירות המנוהל קובעת את גרסת ה-IP של קובץ השירות המצורף ושל התעבורה שיוצאת מקובץ השירות המצורף. גרסת ה-IP של קובץ השירות יכולה להיות IPv4 או IPv6, אבל לא שתיהן. מפיקים יכולים להשתמש בכתובת IPv4 אם תת-הרשת של הכתובת היא single-stack. מפיקים יכולים להשתמש בכתובת 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 בסטאק כפול

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

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

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

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

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

ב-Codelab,‏ Google Cloud יקצה אוטומטית ‎ /48, וכתוצאה מכך יתקבל טווח כתובות ULA ייחודי ברמה הגלובלית.

5. דרישות רשת

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

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

רכיבים	תיאור
VPC	כדי להשתמש ב-Dual-stack networking, צריך להגדיר VPC במצב מותאם אישית עם ULA מופעל
נקודת קצה של PSC	נקודת קצה (endpoint) של PSC מסוג IPv4 שמשמשת לגישה לשירות המנוהל נקודת קצה (endpoint) של IPV6 PSC שמשמשת לגישה לשירות המנוהל
רשתות משנה	‫IPv4 ו-Dual-stack
GCE	‫IPv4 ו-Dual-stack

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

רכיבים	תיאור
VPC	מצב מותאם אישית של VPC, ‏ ULA לא מופעל
רשת משנה של NAT ב-PSC	‫IPv4. מנות מרשת ה-VPC של הצרכן מתורגמות באמצעות NAT של המקור (SNAT), כך שכתובות ה-IP המקוריות של המקור מומרות לכתובות IP של המקור מרשת המשנה של ה-NAT ברשת ה-VPC של היצרן.
כלל העברה של נציבות שירות המדינה	IPv4. מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי
בדיקת תקינות	כלל תעבורה נכנסת שרלוונטי למופעים שמתבצע איזון עומסים ביניהם, שמאפשר תעבורה ממערכות בדיקת תקינות ב-Google Cloud‏ (130.211.0.0/22 ו-35.191.0.0/16).
שירות לקצה העורפי	שירות לקצה העורפי משמש כגשר בין מאזן העומסים לבין משאבי הקצה העורפי. במדריך, שירות ה-Backend משויך לקבוצת המופעים הלא מנוהלת.
קבוצת מופעים לא מנוהלת	יש תמיכה במכונות וירטואליות שנדרש עבורן שינוי הגדרות או כוונון. לא תומך בהתאמה אוטומטית של קנה המידה.

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

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

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

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

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

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

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

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

מפעילים את Cloud Shell

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

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

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

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

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

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

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

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

gcloud compute networks subnets create producer-psc-nat-subnet --network producer-vpc --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT

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

gcloud compute networks subnets create producer-psc-fr-subnet --network producer-vpc --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

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

gcloud compute networks subnets create producer-psc-vm-subnet --network producer-vpc --range 172.16.30.0/28 --region $region --enable-private-ip-google-access

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

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

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

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

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

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 130.211.0.0/22,35.191.0.0/16 --layer4-configs tcp:80 --global-firewall-policy

כלל חומת האש הבא מאפשר תעבורת נתונים מטווח תת-הרשת של 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 172.16.10.0/28 --global-firewall-policy --layer4-configs=tcp

יצירת מכונת ה-VM של היצרן

ב-Cloud Shell, יוצרים את שרת האינטרנט של Apache producer-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-psc-vm-subnet \
    --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

בתחביר הבא, יוצרים כלל העברה (מאזן עומסי רשת פנימי) עם כתובת IP מוגדרת מראש 172.16.2.3 שמשויכת לשירות הקצה העורפי, producer-backend-svc

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

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

יצירת קובץ מצורף לשירות

ב-Cloud Shell, יוצרים את קובץ ה-Service Attachment:

gcloud compute service-attachments create ipv4-producer-svc-attachment --region=$region --producer-forwarding-rule=producer-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-psc-nat-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 ipv4-producer-svc-attachment --region=$region

פלט לדוגמה

user@cloudshell:~ (projectid)$ gcloud compute service-attachments describe ipv4-producer-svc-attachment --region=$region
connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2024-08-26T07:08:01.625-07:00'
description: ''
enableProxyProtocol: false
fingerprint: USOMy1eQKyM=
id: '1401660514263708334'
kind: compute#serviceAttachment
name: ipv4-producer-svc-attachment
natSubnets:
- https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '85245007652455400'
  low: '1401660514263708334'
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/ipv4-producer-svc-attachment
targetService: https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1/forwardingRules/producer-fr

ב-Cloud Console, עוברים אל:

שירותי רשת ← Private Service Connect ← שירותים שפורסמו

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

רשת VPC

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

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

‫Google מקצה רשת משנה ייחודית ברמה הגלובלית (‎ /48) ל-Consumer VPC. כדי לראות את ההקצאה, מבצעים את הפעולות הבאות:

ב-Cloud Console, עוברים אל:

רשתות VPC

יצירת תת-רשת

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

gcloud compute networks subnets create consumer-v4-subnet --network consumer-vpc --range=192.168.10.0/28 --region $region --enable-private-ip-google-access

ב-Cloud Shell, יוצרים את תת-הרשת של נקודת הקצה (endpoint) של PSC מסוג IPv4:

gcloud compute networks subnets create psc-ipv4-endpoint-subnet --network consumer-vpc --range=192.168.11.0/28 --region $region --enable-private-ip-google-access

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

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 ובדיקת קישוריות IPv4

יצירת מכונה וירטואלית לבדיקה

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

gcloud compute instances create consumer-vm-ipv4 --zone=us-central1-a --subnet=consumer-v4-subnet --no-address

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

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

gcloud compute addresses create psc-ipv4-endpoint-ip --region=$region --subnet=psc-ipv4-endpoint-subnet --addresses 192.168.11.13

יצירה של נקודת קצה מסוג IPv4 PSC

ב-Cloud Shell, מעדכנים את מזהה ה-URI של קובץ השירות עם מזהה ה-URI שצילמתם כשנוצר קובץ השירות, כדי ליצור את נקודת הקצה של PSC.

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

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

צריך לוודא שהמפיק אישר את נקודת הקצה של ה-PSC. ב-Cloud Console, עוברים אל:

שירותי רשת → Private Service Connect ‏→ נקודות קצה מחוברות

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

ב-Cloud Shell, מתחברים באמצעות SSH למכונת GCE, ‏ consumer-vm-ipv4.

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

אחרי שמתחברים למופע GCE, מבצעים curl לנקודת הקצה של PSC, ‏ psc-ipv4-endpoint 192.168.11.13

בתוך מופע GCE של consumer-vm-ipv4, מבצעים curl:

curl 192.168.11.13

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

user@consumer-vm-ipv4:~$ curl 192.168.11.13
Welcome to Producer-VM !!

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

exit

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

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

13. יצירת מכונה וירטואלית, נקודת קצה של PSC ובדיקה של קישוריות בסטאק כפול

יצירת מכונת VM לבדיקת dual-stack

ב-Cloud Shell, יוצרים את מכונת GCE עם כתובות IPv4 ו-IPv6 ברשת המשנה עם כתובות IPv4 ו-IPv6:

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

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

ב-Cloud Shell, יוצרים כתובת IPv6 סטטית לנקודת הקצה (endpoint) של 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:2eb:7252:2::'

יצירה של נקודת קצה של PSC עם IPv6

ב-Cloud Shell, מעדכנים את מזהה ה-URI של קובץ השירות עם מזהה ה-URI שצילמתם כשנוצר קובץ השירות, כדי ליצור את נקודת הקצה של PSC.

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 Console, עוברים אל:

שירותי רשת → Private Service Connect ‏→ נקודות קצה מחוברות

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

ב-Cloud Shell, מתחברים באמצעות SSH למופע GCE עם סטאק כפול, consumer-vm-ipv4-ipv6, ומבצעים curl לנקודת הקצה של צרכני IPv6 של PSC, ‏ psc-ipv6-endpoint, כדי לאמת את הגישה לשירות המנוהל.

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

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

בתוך מופע GCE ‏consumer-vm-ipv4-ipv6, מבצעים curl לנקודת הקצה של PSC מסוג IPv6 שזוהתה בשלב 'קבלת כתובת IPv6 סטטית של נקודת הקצה של PSC'.

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

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

user@consumer-vm-ipv4-ipv6$ curl -6 http://[fd20:2eb:7252:2::]
Welcome to Producer-VM !!

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

exit

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

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

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

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

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

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

gcloud compute instances delete consumer-vm-ipv4 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-ipv4-endpoint-ip psc-ipv6-endpoint-ip --region=us-central1 -q

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

gcloud compute networks delete consumer-vpc -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 networks subnets delete producer-psc-fr-subnet  producer-psc-vm-subnet producer-psc-nat-subnet --region=us-central1 -q

gcloud compute networks delete producer-vpc -q

15. מזל טוב

הגדרתם ואימתתם בהצלחה את Private Service Connect 64.

יצרתם את התשתית של היצרן, ולמדתם איך ליצור נקודת קצה (endpoint) של צרכן מסוג IPv4 ו-IPv6 ברשת ה-VPC של הצרכן, שמאפשרת קישוריות לשירות של היצרן.

‫Cosmopup חושב ש-codelabs הם מדהימים!!

מה השלב הבא?

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

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

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

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

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

מסמכי עזר

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