מידע על גישה לממשקי Google API גלובליים דרך נקודות קצה (endpoints)

במאמר הזה מוסבר על נקודות הקצה של Private Service Connect שמשמשות לגישה לממשקי Google APIs גלובליים.

כברירת מחדל, אם יש לכם אפליקציה שמשתמשת בשירות של Google, כמו Cloud Storage, האפליקציה מתחברת לשם ה-DNS שמוגדר כברירת מחדל לאותו שירות, כמו storage.. שמות ברירת המחדל של DNS לשירותי Google מנותבים לכתובות IP שניתנות לניתוב באופן ציבורי. עם זאת, תעבורת הנתונים שנשלחת ממשאביGoogle Cloud לכתובות ה-IP האלה נשארת ברשת של Google.

באמצעות Private Service Connect, אתם יכולים ליצור נקודות קצה פרטיות באמצעות כתובות IP פנימיות גלובליות ברשת ה-VPC שלכם. אפשר להקצות שמות DNS לכתובות ה-IP הפנימיות האלה עם שמות בעלי משמעות כמו storage-vialink1.p. ו-bigtable-adsteam.p.. השמות וכתובות ה-IP האלה הם פנימיים ברשת ה-VPC וברשתות המקומיות שמחוברות אליה באמצעות מנהרות Cloud VPN או צירופים ל-VLAN. אתם יכולים לקבוע איזו תנועה תעבור לכל נקודת קצה, ולהוכיח שהתנועה נשארת ב- Google Cloud.

האפשרות הזו נותנת גישה לכל Google APIs והשירותים של Google שכלולים בחבילות ה-API.

איור 1. ‫Private Service Connect מאפשר לשלוח תנועה אל Google APIs באמצעות נקודת קצה (endpoint) פרטית ברשת ה-VPC (לחצו להגדלה).

תכונות ותאימות

בטבלה הבאה מפורטות התכונות שנתמכות בנקודות קצה (endpoints) שמשמשות לגישה לממשקי Google API גלובליים.

הגדרות אישיות	פרטים
הגדרת הצרכן (נקודת קצה)
זמינות גלובלית	משתמש בכתובת IP פנימית גלובלית
תנועה ב-Cloud Interconnect
תנועה ב-Cloud VPN
גישה דרך קישור בין רשתות VPC שכנות (peering)
הפצת חיבורים דרך NCC (גרסת טרום-השקה (Preview))
הגדרת DNS אוטומטית
גרסת ה-IP	IPv4
מפיק
שירותים נתמכים	ממשקי Google API גלובליים נתמכים

הערה: אם מגדירים נקודות קצה של Private Service Connect לממשקי Google API גלובליים בהיקפי שירות של VPC Service Controls, נקודות קצה שנוצרו לפני 1 בספטמבר 2026 לא נתמכות וצריך ליצור אותן מחדש.

גישה משולבת

אפשר לגשת לנקודות קצה של Private Service Connect שמשמשות לגישה לממשקי Google API ממארחים מקומיים מחוברים נתמכים. למידע נוסף, קראו את המאמר גישה לנקודת הקצה ממארחים מקומיים.

הגדרת DNS אוטומטית באמצעות Service Directory

נקודות הקצה רשומות ב-Service Directory. Service Directory היא פלטפורמה לאחסון, לניהול ולפרסום של שירותים. כשיוצרים נקודת קצה כדי לגשת לממשקי ה-API ולשירותים של Google, בוחרים אזור ומרחב שמות של Service Directory.

אזור ב-Service Directory

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

כשיוצרים את נקודת הקצה הראשונה ל-Google APIs ברשת VPC, האזור שנבחר משמש כאזור ברירת המחדל לכל נקודות הקצה הבאות שנוצרות באותה רשת. אם לא הוגדר אזור לרשת ולא ציינתם אזור, האזור יוגדר כ-us-central1. כל נקודות הקצה ברשת צריכות להשתמש באותו אזור של מדריך השירותים.

מרחב שמות של Service Directory

כשיוצרים את נקודת הקצה הראשונה ל-Google APIs ברשת VPC, מרחב השמות שנבחר משמש כמרחב השמות שמוגדר כברירת מחדל לכל נקודות הקצה הבאות שנוצרות ברשת הזו. אם לא הוגדר מרחב שמות לרשת ולא ציינתם מרחב שמות, המערכת תשתמש במרחב שמות שהיא תיצור. כל נקודות הקצה ברשת חייבות להשתמש באותו מרחב שמות של Service Directory. מרחב השמות שתבחרו צריך לשמש רק לנקודות קצה שמשמשות לגישה לממשקי Google API. אפשר להשתמש באותו מרחב שמות לנקודות קצה בכמה רשתות.

כשיוצרים נקודת קצה, נוצרות הגדרות ה-DNS הבאות:

• נוצר אזור DNS פרטי של Service Directory בשביל p..

• רשומות DNS נוצרות ב-p. בשביל חלק מממשקי ה-API והשירותים הנפוצים של Google שזמינים באמצעות Private Service Connect, ויש להם שמות DNS שנגמרים ב- כברירת מחדל. לדוגמה, אם שם נקודת הקצה הוא xyz, רשומות DNS נוצרות בשביל storage-xyz.p.,‏ compute-xyz.p. וממשקי API נפוצים אחרים בחבילת ה-API.

  במאמר יצירת רשומות DNS מוסבר איך ליצור רשומות DNS לממשקי API ולשירותים שאין להם רשומת DNS ב-p..

השירותים הזמינים משתנים בהתאם לבחירה שלכם בחבילת ה-API all-apis או vpc-sc.

לכל רשת VPC שמכילה נקודת קצה נוצר תחום DNS אחד של Service Directory.

אפשר לגשת לשמות ה-DNS של נקודת קצה בכל האזורים ברשת ה-VPC.

פענוח DNS

לקוחות באותה רשת VPC כמו נקודת הקצה יכולים לשלוח שאילתות לתחומי ה-DNS הפרטיים שנוצרו באופן אוטומטי כשהם פותרים שמות מארחים, וגם לכל תחום פרטי שאתם יוצרים באופן ידני. אם מכונה של Compute Engine שולחת בקשה לשירות דרך נקודת קצה (לדוגמה, אל storage-xyz.p.googleapis.com), הלקוח שולח שאילתה לתחום ה-DNS הפרטי המתאים כדי לפענח את שם המארח, ומקבל את כתובת ה-IP של נקודת הקצה של Private Service Connect.

עם זאת, אם לקוח מחפש שם מארח שלא קיים בתחום ה-DNS הפרטי, השאילתה מועברת לשרתי ה-DNS הציבוריים של Google. רשומות ה-DNS הציבוריות של googleapis.com (ודומיינים אחרים של Google) כוללות רשומת תו כללי לחיפוש, כלומר כל שמות המארחים מחזירים כתובת IP. לדוגמה, אם אין לכם תחום DNS פרטי ל-p.googleapis.com ברשת ה-VPC, ואתם מבצעים חיפוש DNS ל-storage-xyz.p.googleapis.com, שם המארח יתורגם לכתובות IP ציבוריות ששייכות ל-Cloud Front Ends, ולא לכתובת ה-IP הפנימית של נקודת הקצה של Private Service Connect.

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

ממשקי API נתמכים

כשיוצרים נקודת קצה כדי לגשת לממשקי ה-API ולשירותים של Google, בוחרים את חבילת ממשקי ה-API שצריכים גישה אליה – כל ממשקי ה-API (all-apis) או VPC-SC (vpc-sc):

• החבילה all-apis מספקת גישה לרוב Google APIs והשירותים של Google, כולל כל נקודות הקצה של השירות *..

• החבילה vpc-sc מספקת גישה לממשקי API ולשירותים שתומכים ב-VPC Service Controls.

הערה: החבילות האלה מספקות גישה לאותם ממשקי API שזמינים דרך כתובות ה-VIP של גישה פרטית ל-Google – all-apis מקבילה ל-private. ו-vpc-sc מקבילה ל-restricted..

חבילות ה-API תומכות רק בפרוטוקולים מבוססי-HTTP דרך TCP ‏(HTTP,‏ HTTPS ו-HTTP/2). אין תמיכה בפרוטוקולים אחרים, כולל MQTT ו-ICMP.

חבילת API	שירותים נתמכים	דוגמה לשימוש
all-apis	מאפשרת גישה לרוב ממשקי ה-API והשירותים של Google, גם אם הם לא נתמכים על ידי VPC Service Controls. כולל גישה ל-API של מפות Google,‏ Google Ads,‏ Google Cloudורוב ממשקי ה-API האחרים של Google, כולל הרשימות שבהמשך. לא תומך באפליקציות אינטרנט של Google Workspace כמו Gmail ו-Google Docs. לא תומך באתרים אינטראקטיביים. שמות דומיינים תואמים: ‫accounts.google.com (תומך רק בנתיבים שנדרשים לאימות OAuth של חשבונות שירות. אימות של חשבונות משתמשים הוא אינטראקטיבי ולא נתמך) *.aiplatform-notebook.cloud.google.com *.aiplatform-notebook.googleusercontent.com appengine.google.com *.appspot.com *.backupdr.cloud.google.com backupdr.cloud.google.com *.backupdr.googleusercontent.com backupdr.googleusercontent.com *.cloudfunctions.net *.cloudproxy.app *.composer.cloud.google.com *.composer.googleusercontent.com *.datafusion.cloud.google.com *.datafusion.googleusercontent.com *.dataproc.cloud.google.com dataproc.cloud.google.com *.dataproc.googleusercontent.com dataproc.googleusercontent.com *.developerconnect.dev dl.google.com gcr.io או *.gcr.io *.googleapis.com לא כולל נקודות קצה אזוריות ונקודות קצה במספר אזורים של *.rep.googleapis.com. *.gke.goog gstatic.com או *.gstatic.com *.kernels.googleusercontent.com *.ltsapis.goog *.notebooks.byoid.googleusercontent.com *.notebooks.cloud.google.com notebooks.cloud.google.com *.notebooks.googleusercontent.com packages.cloud.google.com pkg.dev או *.pkg.dev pki.goog או *.pki.goog *.run.app source.developers.google.com storage.cloud.google.com	כדאי לבחור באפשרות all-apis במקרים הבאים: אתם לא משתמשים ב-VPC Service Controls. אתם משתמשים ב-VPC Service Controls, אבל אתם צריכים גם לגשת לממשקי API ולשירותים של Google שלא נתמכים על ידי VPC Service Controls. ^1
vpc-sc	מאפשר גישה ל-API אל ממשקי API ושירותים של Google שנתמכים על ידי VPC Service Controls. חסימת הגישה לממשקי API ולשירותים של Google שלא תומכים ב-VPC Service Controls. לא תומך בממשקי API של Google Workspace או באפליקציות אינטרנט של Google Workspace כמו Gmail ו-Google Docs.	בוחרים באפשרות vpc-sc כשצריכים גישה רק לממשקי API ולשירותים של Google שנתמכים על ידי VPC Service Controls. החבילה vpc-sc לא מאפשרת גישה לממשקי API ולשירותים של Google שלא תומכים ב-VPC Service Controls. ^1

¹ אם אתם צריכים להגביל את המשתמשים רק ל-Google APIs ולשירותים שתומכים ב-VPC Service Controls, השתמשו ב-vpc-sc כי הוא מספק צמצום סיכונים נוסף מפני זליגת נתונים. שימוש ב-vpc-sc מונע גישה לממשקי API ולשירותים של Google שלא נתמכים על ידי VPC Service Controls. למידע נוסף, קראו את המאמר הגדרת קישוריות פרטית במסמכי התיעוד של VPC Service Controls.

הדרישות לגבי כתובות IP

כשמגדירים את Private Service Connect לממשקי Google APIs גלובליים, צריך לספק כתובת IP לשימוש בנקודת הקצה.

הכתובת נכללת במכסת הפרויקט לכתובות IP פנימיות גלובליות.

כתובת ה-IP צריכה לעמוד בדרישות הבאות:

• היא חייבת להיות כתובת IP אחת ולא טווח כתובות.

• היא חייבת להיות כתובת IPv4 תקינה. היא יכולה להיות כתובת RFC 1918 או כתובת שהיא לא RFC 1918. אין תמיכה בכתובות IPv6.

• הוא לא יכול להיות בטווח של רשתות המשנה שהוגדרו ברשת ה-VPC.

• הוא לא יכול להיות בטווח כתובות ה-IP הראשי או המשני של אף רשת משנה ברשת ה-VPC, או ברשת שמחוברת לרשת ה-VPC באמצעות קישור בין רשתות VPC שכנות (peering).

• הוא לא יכול לחפוף לנתיב סטטי מותאם אישית של /32 ברשת ה-VPC המקומית. לדוגמה, אם לרשת ה-VPC יש נתיב סטטי בהתאמה אישית ל-10.10.10.10/32, אי אפשר לשמור את הכתובת 10.10.10.10 ל-Private Service Connect.

• הוא לא יכול לחפוף לנתיב סטטי מותאם אישית של קישור /32, אם הגדרתם את הרשת המקושרת לייצא נתיבים מותאמים אישית ואת רשת ה-VPC לייבא נתיבים מותאמים אישית.

• הוא לא יכול להיות בתוך אף אחד מטווחי ה-IP של המצב האוטומטי (ב-10.128.0.0/9) אם רשת ה-VPC המקומית היא רשת VPC במצב אוטומטי או אם היא מקושרת לרשת VPC במצב אוטומטי.

• הוא לא יכול להיות בתוך טווח כתובות IP שהוקצה ברשת ה-VPC המקומית. עם זאת, היא יכולה להיות בטווח כתובות IP שהוקצה ברשת VPC שמקושרת לרשתות שכנות.

• היא לא יכולה להיות בתוך טווח פנימי, אלא אם שומרים את כתובת ה-IP מטווח פנימי לנקודות קצה של Private Service Connect באותה רשת VPC.

• אם נקודת קצה חופפת לנתיב דינמי בהתאמה אישית שהיעד שלו הוא אותו /32, נקודת הקצה מקבלת עדיפות.

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

תרחישים לדוגמה

אפשר ליצור כמה נקודות קצה באותה רשת VPC. אין הגבלה על רוחב הפס הכולל שנשלח לנקודת קצה ספציפית. בגלל שנקודות הקצה משתמשות בכתובות IP פנימיות גלובליות, כל משאב ברשת ה-VPC או ברשת המקומית שמחוברת באמצעות מנהרות Cloud VPN או חיבורי Cloud Interconnect יכול להשתמש בהן.

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

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

• אתם יכולים להגדיר כלל של חומת אש במכונה וירטואלית שמונע את כל תעבורת הנתונים לאינטרנט, אבל תעבורת הנתונים שנשלחת לנקודות קצה של Private Service Connect עדיין תגיע ל-Google.

• אם יש לכם מארחים מקומיים שמחוברים ל-VPC באמצעות מנהרת Cloud VPN או צירוף ל-VLAN, אתם יכולים לשלוח חלק מהבקשות דרך המנהרה או ה-VLAN, ולשלוח בקשות אחרות דרך האינטרנט הציבורי. ההגדרה הזו מאפשרת לעקוף את המנהרה או את ה-VLAN בשביל שירותים כמו Google Books, שלא נתמכים בגישה פרטית ל-Google.

  כדי ליצור את ההגדרה הזו, יוצרים נקודת קצה (endpoint) של Private Service Connect, מפרסמים את כתובות ה-IP של נקודת הקצה באמצעות פרסומי ניתוב בהתאמה אישית של Cloud Router ומפעילים מדיניות העברה נכנסת של Cloud DNS. האפליקציה יכולה לשלוח בקשות מסוימות דרך מנהרת Cloud VPN או דרך הצירוף ל-VLAN באמצעות שם נקודת הקצה, ובקשות אחרות דרך האינטרנט באמצעות שם ה-DNS שמוגדר כברירת מחדל.

• אם מחברים את הרשת המקומית לרשת ה-VPC באמצעות כמה חיבורי VLAN, אפשר לשלוח חלק מהתנועה מהרשת המקומית דרך VLAN אחד ואת השאר דרך חיבורים אחרים, כמו שמוצג באיור 2. כך תוכלו להשתמש ברשת רחבה משלכם במקום בזו של Google, ולשלוט בתנועת הנתונים כדי לעמוד בדרישות גיאוגרפיות.

  כדי ליצור את ההגדרה הזו, יוצרים שתי נקודות קצה. יוצרים פרסום ניתוב בהתאמה אישית לנקודת הקצה הראשונה בסשן ה-BGP של Cloud Router שמנהל את ה-VLAN הראשון, ויוצרים פרסום ניתוב אחר בהתאמה אישית לנקודת הקצה השנייה בסשן ה-BGP של Cloud Router שמנהל את ה-VLAN השני. מארחים מקומיים שמוגדרים להשתמש בשם של נקודת הקצה שולחים תנועה דרך הצירוף המתאים ל-VLAN.

• אפשר גם להשתמש בכמה צירופים ל-VLAN בטופולוגיה פעילה/פעילה. אם אתם מפרסמים את אותה כתובת IP של נקודת קצה באמצעות פרסומי ניתוב בהתאמה אישית לסשנים של BGP ב-Cloud Routers שמנהלים את רשתות ה-VLAN, חבילות שנשלחות ממערכות מקומיות לנקודות הקצה מנותבות דרך רשתות ה-VLAN באמצעות ECMP.

  

  איור 2. באמצעות הגדרה של Private Service Connect, ‏Cloud Router ומארחים מקומיים, אתם יכולים לקבוע באיזה צירוף ל-VLAN להשתמש כדי לשלוח תנועה אל Google APIs (לחצו להגדלה).

VPC משותף

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

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

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

אם יוצרים את ההגדרה הזו, צריך להקצות לאדמין של פרויקט השירות תפקיד כמו "משתמש ברשת Compute"‏ (roles/compute.networkUser) בפרויקט המארח. התפקיד הזה כולל את ההרשאות הנדרשות compute.networks.use ו-compute.addresses.use.

אי אפשר ליצור את ההגדרה הזו באמצעות מסוף Google Cloud , אלא צריך להשתמש ב-Google Cloud CLI או ב-API.

תמחור

התמחור של Private Service Connect מתואר בדף התמחור של VPC.

מכסות

מספר נקודות הקצה של Private Service Connect שאפשר ליצור כדי לגשת ל-Google APIs נשלט על ידי המכסה PSC Google APIs Forwarding Rules per VPC Network. מידע נוסף זמין במאמר בנושא מכסות.

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

אדמינים של מדיניות הארגון יכולים להשתמש באילוץ constraints/compute.disablePrivateServiceConnectCreationForConsumers כדי להגדיר את קבוצת סוגי נקודות הקצה שמשתמשים לא יכולים ליצור להם כללי העברה.

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

המאמרים הבאים

• מגדירים את Private Service Connect כדי לגשת לממשקי ה-API ולשירותים של Google.