חיבור למכונה של Cloud SQL מחוץ ל-VPC שלה

בדף הזה מוסבר איך להתחבר למופע Cloud SQL מחוץ לענן הווירטואלי הפרטי (VPC) שהוגדר לו.

לפני שמתחילים

לפני שמתחילים, חשוב לבצע את הפעולות הבאות:

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

מידע על חיבורים חיצוניים

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

במצבים הבאים, צריך להתחבר למכונה מחוץ ל-VPC מחובר:

  • האפליקציה שלכם פועלת מחוץ ל-VPC שבו השתמשתם כדי להתחבר למופע באמצעות גישה לשירותים פרטיים או Private Service Connect.

  • האפליקציה שלכם פועלת ב-VPC שנמצא מחוץ לרשת של Google.

  • האפליקציה שלכם פועלת במחשב שנמצא במקום אחר באינטרנט הציבורי.

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

בהתאם לצרכים שלכם, אנחנו ממליצים על הפתרונות הבאים ליצירת חיבורים חיצוניים:

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

  • בסביבות ייצור שדורשות זמינות גבוהה, כדאי ליצור חיבור קבוע בין ה-VPC לבין האפליקציה באמצעות Cloud VPN או Cloud Interconnect.

בקטעים הבאים מתוארים הפתרונות האלה.

התחברות דרך מכונה וירטואלית מתווכת

כדי ליצור חיבור למכונה של Cloud SQL מחוץ ל-VPC שלה באמצעות כלים בקוד פתוח ומינימום משאבים נוספים, מריצים שירות proxy במכונה וירטואלית (VM) מתווכת שמוגדרת ב-VPC הזה. אתם יכולים להגדיר מכונה וירטואלית חדשה או להשתמש במכונה וירטואלית שכבר פועלת ב-VPC של מופע Cloud SQL.

כפתרון בניהול עצמי, השימוש במכונה וירטואלית (VM) כמתווך בדרך כלל זול יותר וזמן ההגדרה קצר יותר מאשר שימוש במוצר Network Connectivity. אבל יש גם חסרונות: הזמינות, האבטחה וקצב העברת הנתונים של החיבור תלויים במכונה הווירטואלית המתווכת, שצריך לתחזק כחלק מהפרויקט.

התחברות דרך IAP

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

ארכיטקטורה של שרת proxy לאימות זהויות (IAP)

בתרשים הזה, IAP משמש כשער בין הלקוח החיצוני שנמצא מחוץ ל-VPC לבין המכונה הווירטואלית המתווכת שנמצאת ב-VPC. הלקוח יוצר מנהרת SSH ל-IAP. שרת proxy ל-Cloud SQL Auth מצפין את התנועה בין המכונה הווירטואלית לבין מכונת Cloud SQL. באמצעות שני ה-Proxy האלה, נוצרת תקשורת בין הלקוח לבין המופע.

כדי להגדיר גישה ל-IAP למופע שלכם, פועלים לפי השלבים הבאים:

  1. בלקוח החיצוני, מתקינים את ה-CLI של gcloud.

  2. ב-VM המתווך, מורידים ומתקינים את שרת ה-proxy ל-Cloud SQL Auth.

  3. במכונת ה-VM המתווכת, מפעילים את שרת ה-proxy ל-Cloud SQL Auth.

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

  4. ב Google Cloud פרויקט, מפעילים את העברת ה-TCP של IAP.

    כשמגדירים את כלל חומת האש החדש, מאפשרים תעבורת TCP נכנסת ליציאה 22 (SSH). אם אתם משתמשים ברשת שמוגדרת כברירת מחדל בפרויקט עם כלל default-allow-ssh שאוכלס מראש ומופעל, לא צריך להגדיר כלל נוסף.

  5. מגדירים העברת יציאות בין הלקוח החיצוני לבין מכונת ה-VM המתווכת באמצעות SSH דרך IAP:

    gcloud compute ssh VM_NAME \
--tunnel-through-iap \
--zone=ZONE_NAME \
--ssh-flag="-L 1433:localhost:1433"

    מחליפים את הפרטים הבאים:

    • ‫VM_NAME: שם המכונה הווירטואלית
    • ‫ZONE_NAME: שם האזור שמשויך למכונה הווירטואלית

  6. בקליינט החיצוני, בודקים את החיבור באמצעות קליינט של SQL Server.

חיבור דרך שרת SOCKS proxy

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

מידע נוסף על שימוש ב-SOCKS proxy כדי להתחבר למופע Cloud SQL זמין במאמר חיבור באמצעות שרת proxy ביניים (SOCKS5).

קישור באמצעות מאגר

אם אתם צריכים להתקין ולהפעיל את שרת ה-proxy ל-Cloud SQL Auth במכונת ה-VM המתווכת, במקום בלקוח חיצוני, אתם יכולים להפעיל חיבורים מאובטחים אליה על ידי שיוך שלה לשרת proxy שמודע לפרוטוקול, שנקרא גם pooler. ‫ADO.NET הוא כלי פופולרי לניהול מאגרים של SQL Server בקוד פתוח.

בפתרון הזה, מריצים את שרת ה-proxy ל-Cloud SQL Auth ואת מאגר החיבורים במכונה הווירטואלית המתווכת. הלקוח או האפליקציה שלכם יכולים להתחבר ישירות למאגר באמצעות SSL בצורה מאובטחת, בלי להפעיל שירותים נוספים. ‫Pooler מעביר שאילתות של PostgreSQL למכונה שלכם ב-Cloud SQL דרך שרת proxy ל-Cloud SQL Auth.

לכל מכונת Cloud SQL יש כתובת IP פנימית נפרדת, ולכן כל שירות proxy יכול לתקשר רק עם מכונה ספציפית אחת: המכונה הראשית, מכונת הגיבוי או מאגר לקריאה. לכן, בכל מופע צריך להפעיל שירות pooler נפרד עם אישור SSL שהוגדר בצורה מתאימה.

חיבור דרך Cloud VPN או Cloud Interconnect

לעבודה בסביבת ייצור שדורשת זמינות גבוהה (HA), מומלץ להשתמש במוצר Google Cloud Network Connectivity, כמו Cloud VPN או Cloud Interconnect, בהתאם לצרכים של השירות החיצוני ולטופולוגיית הרשת. לאחר מכן מגדירים את Cloud Router כך שיפרסם את המסלולים המתאימים.

מידע נוסף על פתרונות Network Connectivity זמין במאמר בחירת מוצרים של Network Connectivity.

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