מידע על שימוש בכתובת 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 באזור אחד.
  • הפרדה מדור קודם של PostgreSQL: בפרויקט רשת עם ארכיטקטורת הרשת הישנה, מכונות PostgreSQL לא יכולות לחלוק את אותה יחידת טווח כתובות IP עם מכונות MySQL או SQL Server. למופעי PostgreSQL נדרשים טווחי /24 ייעודיים משלהם בכל אזור.
  • הפרדה מחייבת של ארכיטקטורת הרשת: אי אפשר לשתף את אותה יחידת טווח כתובות 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 (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 של הגישה לשירותים פרטיים לכל אזור. לדוגמה, אם רוצים למקם מכונות PostgreSQL בשני אזורים, צריך לוודא שטווח כתובות ה-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, ‏ Cloud SQL יוצר את המכונה בענן וירטואלי פרטי (VPC) משלו, שנקרא Cloud SQL VPC. כדי להפעיל כתובת IP פרטית, צריך להגדיר קישור בין רשתות שכנות בין ה-VPC של Cloud SQL לבין רשת ה-VPC שלכם. כך המשאבים ברשת ה-VPC יכולים לגשת לכתובות ה-IP הפנימיות של משאבי Cloud SQL ברשת ה-VPC של Cloud SQL.

באמצעות VPC Network Peering,‏ Cloud SQL מיישם גישה פרטית לשירותים באופן פנימי, שמאפשרת לכתובות IP פנימיות להתחבר בין שתי רשתות VPC, בלי קשר לשאלה אם הן שייכות לאותו פרויקט או לאותו ארגון. עם זאת, מכיוון שקישור בין רשתות VPC שכנות (peering) הוא לא טרנזיטיבי, הוא משדר מסלולים רק בין שתי רשתות ה-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 פרטית ישירות ברפליקה. אם מתחברים לרפליקה באמצעות כתובת 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). עם זאת, לא יוצרים את ה-VPC Network Peering באופן מפורש, כי ה-Peering הוא פנימי ל- Google Cloud. אחרי שיוצרים את החיבור של הגישה לשירותים פרטיים, אפשר לראות את ה-VPC Network Peering הבסיסי שלו בדף VPC Network Peering במסוףGoogle Cloud , אבל לא מומלץ למחוק אותו אלא אם רוצים להסיר את החיבור הפרטי.

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

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

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