סקירה כללית על גישה לשירותים פרטיים ב-Cloud SQL

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

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

כתובות IP

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

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

כשמגדירים גישה לשירותים פרטיים, אפשר לבחור טווח קיים או להקצות טווח חדש. אם נותנים ל- Google Cloud להקצות את הטווח, כמו שמתואר בקטע הבא, Google Cloud מקצה טווח של אורך קידומת /24 בשם default-ip-range.

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

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

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

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

בדוגמה הזו, רשת ה-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 של תת-הרשת הוא בדרך כלל בלוק /24 Classless Inter-Domain Routing ‏ (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. כך, כל הלקוחות הפרטיים יכולים לגשת למסד הנתונים בלי לעבור דרך Cloud SQL Auth Proxy.

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

שיקולי אבטחה

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

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

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

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

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

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

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

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

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

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

מה השלב הבא?