מידע על שימוש בכתובת IP פרטית

בדף הזה מוסבר איך להשתמש בכתובת IP פרטית עם Cloud SQL. הוראות מפורטות להגדרת מכונת Cloud SQL לשימוש בכתובת IP פרטית מופיעות במאמר הגדרת כתובת IP פרטית.

פתרונות Terraform לרשתות Cloud SQL מפורטים במאמר פתרונות פשוטים להגדרת רשתות בענן.

סקירה כללית

כדי להגדיר מכונת Cloud SQL לשימוש בכתובת IP פרטית, צריך גישה לשירותים פרטיים. גישה לשירותים פרטיים מאפשרת ליצור חיבורים פרטיים בין רשת ה-VPC לבין רשת ה-VPC הבסיסית של ספק השירות Google Cloud . Google Cloud יחידות שמציעות שירותים, כמו Cloud SQL, נקראות ספקי שירותים. כל Google Cloud שירות יוצר תת-רשת שבה הוא מקצה משאבים. טווח כתובות ה-IP של רשת המשנה הוא בדרך כלל בלוק CIDR של ‎ /24 שנבחר על ידי השירות ומגיע מטווח כתובות ה-IP שהוקצה.

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

משתמשים בגישה לשירותים פרטיים כדי להתחבר למכונות Cloud SQL:

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

טווחים של כתובות IP שהוקצו

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

גודל הטווח שהוקצה

צריך להקצות טווחי כתובות IP גדולים מספיק ל-Cloud SQL ולשארGoogle Cloud השירותים המנוהלים שאתם מתכננים להשתמש בהם. שירות Cloud SQL וכל שירות אחר של Google Cloud דורשים בלוקים ייעודיים של כתובות IP מתוך הטווחים שהוקצו. הגודל המינימלי הוא בלוק אחד של ‎ /24 (256 כתובות), אבל הגודל המומלץ הוא בלוק של ‎ /16 (65,536 כתובות).

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

מסכה של רשת משנה כתובות מכונות Cloud SQL שאפשר להשתמש בהן
/2425650
/23512100
/221024200
/212048400
/204096800

מתי כדאי להשתמש בטווחים נפרדים של CIDR‏ /24

מכיוון ש-Cloud SQL משתמש בטווחים של CIDR‏ /24 כיחידת טווח IP, יש כמה תנאים שבהם נדרשים טווחים נפרדים של /24.

  • הפרדה אזורית: אם יוצרים שתי מכונות Cloud SQL בשני אזורים נפרדים, צריך להקצות לפחות שני טווחי CIDR נפרדים של ‎ /24. אפשר להשתמש בכל יחידה של טווח כתובות IP רק עבור מופעים של Cloud SQL באזור אחד.
  • הפרדה מחייבת של ארכיטקטורת הרשת: אי אפשר לשתף יחידת טווח כתובות IP עם מופעים באותו פרויקט שמשתמשים בארכיטקטורת הרשת הישנה, אם יוצרים מופעים באמצעות הדגל --enforce-new-sql-network-architecture (או שדה ה-API המקביל). המופעים שיוצרים באמצעות ארכיטקטורת הרשת החדשה דורשים טווחי /24 ייעודיים משלהם בכל אזור.

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

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

אחרי שתגדירו גישה לשירותים פרטיים, תוכלו ליצור מכונת Cloud SQL שמוגדרת לשימוש בכתובת IP פרטית, או להגדיר כתובת IP פרטית למכונת Cloud SQL קיימת. הוראות מפורטות זמינות במאמר בנושא הגדרת כתובת IP פרטית.

בכל פעם שמשנים חיבור קיים, צריך גם לעדכן את vpc-peerings.

דרישות לגבי כתובת IP פרטית

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

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

  • אם אתם מתחברים מ-GKE, אתם צריכים להשתמש ב-GKE 1.8 ואילך באשכול VPC-native.

דרישות API ו-IAM

כדי ליצור ולנהל חיבור פרטי לשירות עבור כתובת IP פרטית, צריך להפעיל את Service Networking API.

כדי לקבל את ההרשאות שנדרשות ליצירה ולניהול של חיבור גישה לשירותים פרטיים, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד אדמין של רשת Compute (roles/compute.networkAdmin) בפרויקט שבו אתם מתכננים לארח את מכונת Cloud SQL. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

ההרשאות הנדרשות

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

  • compute.addresses.create
  • compute.addresses.list
  • compute.globalAddresses.create
  • compute.globalAddresses.createInternal
  • compute.globalAddresses.list
  • compute.networks.list
  • compute.networks.use
  • servicenetworking.services.addPeering
  • serviceusage.services.list

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

כדי לקבל את ההרשאות שדרושות ליצירה ולניהול של נקודות קצה של Private Service Connect, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ Compute Network Admin (אדמין של רשת Compute) ‏(roles/compute.networkAdmin) בפרויקט שבו אתם מתכננים ליצור את נקודות הקצה של Private Service Connect ולהתחיל את החיבור למופע Cloud SQL. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

ההרשאות הנדרשות

כדי ליצור ולנהל נקודות קצה של Private Service Connect, נדרשות ההרשאות הבאות:

  • networkconnectivity.serviceConnectionPolicies.list
  • networkconnectivity.serviceConnectionPolicies.create

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

דוגמה

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

תרשים שמציג סקירה כללית של הגדרת כתובת IP פרטית.

  • לחיבור הפרטי מוקצה 10.240.0.0/16 הטווח שהוקצה. מתוך ההקצאה הזו, Google Cloud שירותים יכולים ליצור רשתות משנה שבהן מוקצים משאבים חדשים.
  • ב Google Cloud צד השירות של החיבור הפרטי Google Cloud ,נוצר פרויקט עבור הלקוח. הפרויקט מבודד, כלומר אף לקוח אחר לא משתף אותו, והלקוח מחויב רק על המשאבים שהוא מקצה.
  • כל Google Cloud שירות יוצר תת-רשת שבה הוא מקצה משאבים. טווח כתובות ה-IP של תת-הרשת הוא בדרך כלל בלוק /24 CIDR שנבחר על ידי השירות ומגיע מטווח כתובות ה-IP שהוקצה. אי אפשר לשנות את רשת המשנה של ספק השירות. שירות מספק משאבים חדשים ברשתות משנה אזוריות קיימות שנוצרו בעבר על ידי אותו שירות. אם רשת משנה מלאה, השירות יוצר רשת משנה חדשה באותו אזור.
  • מכונות וירטואליות ברשת של הלקוח יכולות לגשת למשאבי שירות בכל אזור אם השירות תומך בכך. יכול להיות שחלק מהשירותים לא תומכים בתקשורת בין אזורים. מידע נוסף זמין במאמרי העזרה של השירות הרלוונטי.
  • עלויות העברת נתונים יוצאת לתנועה חוצת-אזורים, שבה מכונה וירטואלית מתקשרת עם משאבים באזור אחר, עדיין חלות.
  • למכונה של Cloud SQL מוקצית כתובת ה-IP‏ 10.240.0.2. ברשת ה-VPC של הלקוח, בקשות עם יעד 10.240.0.2 מנותבות לחיבור הפרטי לרשת של ספק השירות. אחרי שהבקשה מגיעה לרשת השירות, רשת השירות מכילה מסלולים שמפנים את הבקשה למשאב הנכון.
  • תעבורת הנתונים בין רשתות VPC עוברת באופן פנימי ברשת של Google Cloud, ולא דרך האינטרנט הציבורי.

בעיות ברשת

מערכת Cloud SQL מקצה רשת משנה עם חלוקה ל-24 מטווח כתובות ה-IP של הגישה לשירותים פרטיים לכל אזור. לדוגמה, אם מציבים מופעים של SQL Server בשני אזורים, צריך לוודא שטווח כתובות ה-IP שהוקצה כולל לפחות שתי רשתות משנה בגודל ‎ /24.

חיבורים למכונת Cloud SQL באמצעות כתובת IP פרטית מקבלים הרשאה אוטומטית לטווח כתובות RFC 1918. כך, כל הלקוחות הפרטיים יכולים לגשת למסד הנתונים בלי לעבור דרך שרת ה-proxy ל-Cloud SQL Auth.

כברירת מחדל, שירות Cloud SQL לא לומד נתיבי תת-רשתות שאינם RFC 1918 מה-VPC. כדי לייצא נתיבים שהם לא RFC 1918, צריך לעדכן את ה-peering של הרשת ל-Cloud SQL.

אבטחה

תנועת הגולשים דרך גישה לשירותים פרטיים מסופקת עם רמת הצפנה מסוימת. מידע נוסף זמין במאמר בנושא הצפנה ואימות ברשתות הווירטואליות שלGoogle Cloud.

אפשר להגדיר את שרת ה-proxy ל-Cloud SQL Auth להתחבר באמצעות כתובת IP פרטית, והוא מספק אימות באמצעות פרטי כניסה ל-IAM והצפנה מקצה לקצה באמצעות אישור SSL/TLS מתחלף.

אם דרישות האבטחה שלכם מחייבות אישורי SSL/TLS בניהול עצמי, אתם יכולים לקרוא את ההוראות במאמר הגדרת SSL/TLS.

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

קישוריות לכמה רשתות VPC

‫Cloud SQL תומך בכתובות IP פרטיות באמצעות גישה לשירותים פרטיים. כשיוצרים מכונת Cloud SQL, המערכת יוצרת אותה בענן וירטואלי פרטי (VPC) משלה, שנקרא Cloud SQL VPC. כדי להפעיל כתובת IP פרטית, צריך להגדיר קישור בין רשתות שכנות בין ה-VPC של Cloud SQL לבין רשת ה-VPC שלכם. כך המשאבים ברשת ה-VPC יכולים לגשת לכתובות ה-IP הפנימיות של משאבי Cloud SQL ברשת ה-VPC של Cloud SQL.

באמצעות קישור בין רשתות VPC שכנות (peering),‏ Cloud SQL מטמיע גישה לשירותים פרטיים באופן פנימי, וכך מאפשר לכתובות IP פנימיות להתחבר בין שתי רשתות VPC, בלי קשר לשאלה אם הן שייכות לאותו פרויקט או לאותו ארגון. עם זאת, מכיוון שקישור בין רשתות VPC שכנות הוא לא טרנזיטיבי, הוא משדר מסלולים רק בין שתי רשתות ה-VPC שמקושרות ישירות. אם יש לכם VPC נוסף, לא תהיה לו גישה למשאבי Cloud SQL באמצעות החיבור שהוגדר עם ה-VPC המקורי.

כדי לעקוף את המגבלה הזו ולחבר את מכונת Cloud SQL לכמה רשתות VPC באמצעות כתובות IP פרטיות, אפשר להשתמש באפשרויות החיבור הבאות:

  • התחברות באמצעות מסלולים מפורסמים בהתאמה אישית
  • חיבור באמצעות שרת proxy ביניים (SOCKS5)
  • התחברות באמצעות שרת proxy ל-Cloud SQL Auth כשירות

מידע נוסף על חיבור של כמה רשתות VPC זמין במאמר חיבור המכונה לכמה רשתות VPC.

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

כשמנהלים מכונות Cloud SQL באמצעות כתובת IP פרטית, יכול להיות שהנושאים הבאים יעניינו אתכם:

נושא קבוצת הדיון
רשתות VPC משותפות אפשר ליצור מופעי Cloud SQL עם כתובות IP פרטיות ברשת VPC משותפת. עם זאת, אי אפשר להקצות כתובת IP פרטית ברשת VPC משותפת למופע Cloud SQL קיים.
אזורים אפשר להתחבר באמצעות כתובת IP פרטית בין אזורים.
רשתות מדור קודם אי אפשר להתחבר לכתובת ה-IP הפרטית של מופע Cloud SQL מרשת מדור קודם. רשתות מדור קודם לא תומכות בקישור בין רשתות VPC שכנות או בגישה לשירותים פרטיים.
הסרת כתובת IP פרטית אחרי שמגדירים מכונת Cloud SQL לשימוש בכתובת IP פרטית, אי אפשר להסיר את האפשרות של כתובת IP פרטית מהמכונה הזו.
כתובת IP פרטית וציבורית אתם יכולים להשתמש גם בכתובת IP ציבורית וגם בכתובת IP פרטית כדי להתחבר לאותה מכונת Cloud SQL. אף אחת משיטות החיבור לא משפיעה על השנייה.
מכונות קיימות של Cloud SQL אפשר להגדיר מכונה כך שתשתמש בכתובת IP פרטית בזמן יצירת המכונה. אפשר גם להגדיר מופע קיים לשימוש בכתובת IP פרטית. הגדרה של מופע קיים לשימוש בכתובת IP פרטית, או שינוי הרשת שאליה הוא מחובר, גורמים להפעלה מחדש של המופע, וכתוצאה מכך להשבתה של כמה דקות.
כתובות IP סטטיות במקרה של כתובות IP ציבוריות ופרטיות, הכתובת הנכנסת של מופע Cloud SQL היא סטטית ולא משתנה. הכתובת היוצאת לא תמיד סטטית, למעט כתובות IP ציבוריות יוצאות של עותקים של שרתים חיצוניים, שהן תמיד סטטיות.
עותקים עותק משוכפל יורש את סטטוס כתובת ה-IP הפרטית שלו מהמופע הראשי. אי אפשר להגדיר כתובת IP פרטית ישירות בעותק משוכפל. אם אתם מתחברים לרפליקה באמצעות כתובת IP פרטית, אתם לא צריכים ליצור חיבור VPC פרטי נוסף לרפליקה, כי היא גם מקבלת את החיבור מהמופע הראשי.
שרת proxy ל-Cloud SQL Auth כדי להתחבר למכונת Cloud SQL באמצעות כתובת IP פרטית, שרת ה-proxy ל-Cloud SQL Auth צריך להיות במשאב עם גישה לאותה רשת VPC כמו המכונה. אם שני סוגי ה-IP מופעלים במופע, שרת ה-proxy של Cloud SQL Auth משתמש כברירת מחדל בכתובת ה-IP הציבורית. כדי לוודא שנעשה שימוש בכתובת IP פרטית, צריך להעביר את הדגל -ip_address_types=PRIVATE לשרת ה-proxy של Cloud SQL Auth. מידע נוסף.
חיבור לרשת (VPC) מאפליקציית serverless כדי להתחבר ממקור Serverless, כמו הסביבה הרגילה של App Engine,‏ Cloud Run או פונקציות Cloud Run, האפליקציה או הפונקציה מתחברות ישירות למופע באמצעות Serverless VPC Access בלי Cloud SQL Auth Proxy.
קישור בין רשתות VPC שכנות (peering) חיבור שמשתמש בגישה לשירותים פרטיים מסתמך על קישור בין רשתות VPC שכנות (peering). עם זאת, לא יוצרים את הקישור בין רשתות שכנות (peering) של VPC באופן מפורש, כי הקישור הוא פנימי ל- Google Cloud. אחרי שיוצרים את החיבור של הגישה לשירותים פרטיים, אפשר לראות את ה-VPC Network Peering הבסיסי שלו בדף VPC Network Peering במסוףGoogle Cloud , אבל לא מומלץ למחוק אותו אלא אם רוצים להסיר את החיבור הפרטי.

מידע נוסף על שיתוף פעולה בין רשתות VPC
VPC Service Controls ‫VPC Service Controls משפר את היכולת שלכם לצמצם את הסיכון לזליגת נתונים. בעזרת VPC Service Controls, יוצרים גבולות גזרה מסביב למכונה של Cloud SQL. VPC Service Controls מגביל את הגישה למשאבים בתוך גבולות הגזרה מבחוץ. רק לקוחות ומשאבים בתוך ה-perimeter יכולים לקיים אינטראקציה זה עם זה. מידע נוסף זמין במאמר סקירה כללית על VPC Service Controls. כדאי גם לעיין במגבלות של Cloud SQL כשמשתמשים ב-VPC Service Controls. כדי להשתמש ב-VPC Service Controls עם Cloud SQL, אפשר לעיין במאמר בנושא הגדרת VPC Service Controls.
קישור מעבר בין רשתות שכנות (peering) מתאפשרת תקשורת רק בין רשתות שכנות שיש ביניהן קישור ישיר (direct peering). אין תמיכה בקישור מעבר בין רשתות שכנות (peering). במילים אחרות, אם רשת ה-VPC ששמה N1 מקושרת לרשתות השכנות N2 ו-N3, אבל N2 ו-N3 לא מקושרות בקישור ישיר, רשת ה-VPC ששמה N2 לא יכולה לתקשר עם רשת ה-VPC ששמה N3 באמצעות קישור בין רשתות VPC שכנות.

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

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