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

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

  • לחיבור הפרטי מוקצה 10.240.0.0/16 הטווח שהוקצה. מתוך ההקצאה הזו,שירותי Google Cloud יכולים ליצור רשתות משנה שבהן מוקצים משאבים חדשים.
  • Google Cloud בצד השירותים של החיבור הפרטי, Google Cloud נוצר פרויקט ללקוח. הפרויקט מבודד, כלומר אף לקוח אחר לא משתף אותו, והלקוח מחויב רק על המשאבים שהוא מקצה.
  • כל Google Cloud שירות יוצר רשת משנה שבה הוא מקצה משאבים. טווח כתובות ה-IP של תת-הרשת הוא בדרך כלל בלוק CIDR‏ /24 שנבחר על ידי השירות ומגיע מטווח כתובות ה-IP שהוקצה. אי אפשר לשנות את רשת המשנה של ספק השירות. שירות מספק משאבים חדשים בתת-רשתות אזוריות קיימות שנוצרו בעבר על ידי אותו שירות. אם רשת משנה מלאה, השירות יוצר רשת משנה חדשה באותו אזור.
  • מכונות וירטואליות ברשת של הלקוח יכולות לגשת למשאבי שירות בכל אזור אם השירות תומך בכך. יכול להיות שחלק מהשירותים לא תומכים בתקשורת בין אזורים. מידע נוסף זמין במאמרי העזרה של השירות הרלוונטי.
  • עלויות העברת נתונים יוצאת לתנועה חוצה אזורים, שבה מופעלת תקשורת בין מופע של מכונה וירטואלית לבין משאבים באזור אחר, עדיין חלות.
  • כתובת ה-IP‏ 10.240.0.2 מוקצית למכונה של Cloud SQL. ברשת ה-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, ‏ 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)
  • התחברות באמצעות Cloud SQL Auth Proxy כשירות

מידע נוסף על חיבור של כמה רשתות 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 פרטית כדי להתחבר לאותה מכונת 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 ל-Cloud SQL Auth Proxy. מידע נוסף.
חיבור לרשת (VPC) מאפליקציית serverless כדי להתחבר ממקור Serverless, כמו סביבת ברירת המחדל ב-App Engine,‏ Cloud Run או פונקציות Cloud Run, האפליקציה או הפונקציה מתחברות ישירות למופע באמצעות חיבור לרשת (VPC) מאפליקציית serverless בלי 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 מגביל את הגישה למשאבים בתוך גבולות הגזרה מבחוץ. רק לקוחות ומשאבים בתוך גבולות הגזרה יכולים ליצור אינטראקציה אחד עם השני. מידע נוסף זמין בסקירה כללית על 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 בין פרויקטים, וגם אי אפשר להעביר אותם בין רשתות שמארחים פרויקטים שונים.

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