גישה לשירותים פרטיים

גישה לשירותים פרטיים מאפשרת לכם להגיע לשירותים שמארחים ב-VPC – שירותים שפועלים במופעי Compute Engine ברשת VPC – בלי לחשוף את התעבורה לאינטרנט הציבורי.

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

מכיוון שהתעבורה עוברת באופן פנימי ברשת של Google, מופעים ברשת ה-VPC יכולים להגיע לשירות באמצעות כתובות ה-IPv4 הפנימיות שלהם. למכונות שלכם יכולות להיות כתובות IP חיצוניות, אבל הן לא נדרשות לגישה לשירותים פרטיים ולא נעשה בהן שימוש.

שירותים נתמכים

השירותים הבאים של Google שמתארחים ב-VPC תומכים בגישה לשירותים פרטיים:

גישה לשירותים פרטיים וקישור בין רשתות VPC שכנות (peering)

בחיבור פרטי, הרשת של בעלים של שירות מנוהל והרשת שלכם מקושרות באמצעות VPC Network Peering. כדי שהניתוב בין שתי הרשתות יפעל בצורה תקינה, שתי הרשתות צריכות להשתמש בטווחי כתובות IP שונים. כדי למנוע חפיפות, יוצרים בתוך הרשת טווחים מוקצים לשימוש בחיבור הפרטי.

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

למידע על בחירת טווח מוקצה, ראו בחירת טווח כתובות IP לטווח המוקצה.

תהליך העבודה של גישה לשירותים פרטיים

כשמשתמשים בגישה לשירותים פרטיים, המשאבים נפרסים גם ברשת ה-VPC וגם ברשת של ספק השירות. השלבים הבאים מתארים את התהליך:

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

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

    2. יוצרים חיבור פרטי לבעלים של השירות המנוהל, ומציינים את טווח הכתובות שהוקצה שיצרתם.

    3. אתם מקצים מופע שירות – לדוגמה, מופע Cloud SQL – שמפנה לחיבור הפרטי שיצרתם.

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

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

    2. בפרויקט הזה, הבעלים של שירות מנוהל יוצר רשת VPC שמוקדשת לכם.

    3. ברשת הזו, הבעלים של השירות המנוהל יוצר תת-רשת. טווח כתובות ה-IP של תת-הרשת הזו נבחר מתוך הטווח שהוקצה שסיפקתם. בדרך כלל, הבעלים של השירות המנוהל בוחר טווח כתובות CIDR של /29 עד /24. אי אפשר לבחור או לשנות את טווח כתובות ה-IP של תת-הרשת של ספק השירות.

    4. למופע השירות מוקצית כתובת IP מתת-הרשת החדשה.

  3. החיבור הפרטי הופך לפעיל.

    1. נוצר חיבור VPC Network Peering.

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

    3. מכונות וירטואליות ברשת יכולות לתקשר עם מופע השירות באמצעות כתובת ה-IP הפנימית שלו. התעבורה עוברת כולה בתוך הרשת של Google ולא דרך האינטרנט הציבורי.

אחרי שיוצרים את הפריסה הראשונית, אפשר לבצע את הפעולות הבאות:

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

  • מחיקת משאבים: רשת משנה ברשת של ספק השירות נמחקת רק כשמוחקים את כל משאבי השירות שבה. למידע על מחיקת משאבים, אפשר לעיין במסמכי התיעוד של ספק השירות הרלוונטי.

דוגמה

בתרשים הבא מוצג שימוש בחיבור פרטי כדי לגשת למכונות של שירות.

משאבים ברשת של צרכן שירות יכולים לגשת למכונה של Cloud SQL באמצעות גישה לשירותים פרטיים.
גישה לשירותים פרטיים (לחצו כדי להגדיל).

בדוגמה הזו, ברשת ה-VPC של צרכן השירות הוקצה טווח הכתובות 10.240.0.0/16 לשירותי Google, ונוצר חיבור פרטי שמשתמש בטווח שהוקצה.

  • לחיבור הפרטי מוקצה 10.240.0.0/16 הטווח שהוקצה.

  • ‫Google יוצרת פרויקט ורשת VPC בשביל המשאבים של צרכן השירות. רשתות ה-VPC מחוברות באמצעות קישור בין רשתות VPC שכנות (peering).

  • הבעלים של השירות המנוהל יוצר רשת משנה שמשתמשת בטווח כתובות ה-IP‏ 10.240.0.0/24.

  • למכונה של Cloud SQL מוקצית כתובת ה-IP‏ 10.240.0.2.

  • אחרי שיוצרים את תת-הרשת, הרשת של צרכן השירות מייבאת מסלולים מרשת השירות.

  • ברשת ה-VPC של צרכן השירות, בקשות עם יעד 10.240.0.2 מנותבות לחיבור הפרטי לרשת של ספק השירות.

  • צרכן השירות פורס מופע שירות לשירות אחר של Google ב-europe-west1. מכיוון ש-Google היא הבעלים של שירות מנוהל, אפשר להשתמש באותו פרויקט ובאותה רשת. עם זאת, מכיוון שהמופע נמצא באזור אחר, נדרשת תת-רשת חדשה. ‫Google יוצרת תת-רשת חדשה שמשתמשת בטווח כתובות ה-IP‏ 10.240.10.0/24 ומקצה למופע השירות את כתובת ה-IP‏ 10.240.10.2.

היכולת להגיע למופעי שירות

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

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

גישה דרך NCC

בשירותים מסוימים שזמינים דרך גישה לשירותים פרטיים, אפשר להשתמש ב-NCC כדי להפוך את השירות לנגיש ל-spokes אחרים ב-hub על ידי יצירת producer VPC spoke. מידע נוסף, כולל אילו שירותים נתמכים, זמין במאמר בנושא מרכזי רשת וירטואלית של יצרנים.

גישה דרך VPC משותף

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

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

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

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

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

מידע נוסף זמין במאמר בנושא הגדרת קישוריות היברידית.

רשת של בעלים של שירות מנוהל

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

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

מידע נוסף על הצד של בעלים של שירות מנוהל זמין במאמר הפעלת גישה לשירותים פרטיים במסמכי העזרה של Service Infrastructure. המסמכים האלה מיועדים למטרות מידע בלבד, ולא נדרשים כדי להפעיל או להשתמש בגישה לשירותים פרטיים.

הגבלת חיבורים פרטיים באמצעות מדיניות הארגון

אתם יכולים להשתמש באילוצים מותאמים אישית של מדיניות הארגון כדי להגדיר הגבלות לחיבורים פרטיים. לדוגמה, הגדרת אילוצים מותאמים אישית עם סוג המשאב servicenetworking.googleapis.com/Connection מאפשרת לכם לבצע את הפעולות הבאות:

  • ציון רשתות VPC שאפשר להתחבר אליהן באמצעות חיבורים פרטיים
  • הגדרת הגבלות על השמות של טווחי כתובות שהוקצו שאפשר להשתמש בהם כדי ליצור חיבורים פרטיים

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

תמחור

למידע על התמחור של גישה לשירותים פרטיים, אפשר לעיין בקטע גישה לשירותים פרטיים במחירון של VPC.

מגבלות

המגבלות הבאות חלות על הגישה לשירותים פרטיים:

  • חיבור פרטי מיושם כחיבור VPC Network Peering, ולכן ההתנהגויות והאילוצים של חיבורי Peering חלים גם על חיבורים פרטיים. לדוגמה, מכיוון ש-VPC Network Peering לא טרנזיטיבי, חיבור פרטי לא זמין לרשתות VPC מקושרות.

    מידע נוסף זמין במאמרים בנושא VPC Network Peering, מגבלות של VPC Network Peering ומכסות ומגבלות.

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

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

  • אין תמיכה בשימוש בטווחים של כתובות IPv6 עם גישה לשירותים פרטיים.

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