סקירה כללית על גישה לשירותים פרטיים ב-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 משתמשים בטווחי CIDR של /24 כיחידת טווח של כתובות IP, יש כמה תנאים שבהם נדרשים טווחי /24 נפרדים.

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

מה השלב הבא?