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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • אתם יכולים להשתמש באילוץ constraints/compute.restrictVpcPeering של מדיניות הארגון כדי להגביל את חיבורי ה-Peering לארגון, לתיקייה או לפרויקט.

    אם משתמשים באילוץ הזה, יצירת חיבור פרטי לשירות של Google תיכשל, אלא אם מוסיפים את הארגון של הבעלים של השירות המנוהל של Google‏ (under:organizations/433637338589) לרשימת allowedValues של האילוץ.

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

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

תמחור

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

מגבלות

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

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