כתובת IP פרטית של Cloud SQL דרך VPN: המסלול שאיש לא מייצא
כתובת IP פרטית של Cloud SQL עובדת מרשת מחוברת ב-VPN, אבל רק כאשר גם קידומת הלקוח וגם טווח השירות שורדים שני גבולות ניתוב.
צוותים רבים מאמינים שכתובת IP פרטית של Cloud SQL עובדת רק מתוך ה-VPC, והאמונה מחזיקה מעמד מפני שהכשל נראה כמו בעיית מסד נתונים. Google מתעדת גישה מרשתות המחוברות דרך Cloud VPN או Cloud Interconnect. מה שהרשתות האלה צריכות אינו תכונת מסד נתונים מיוחדת, אלא שני חילופי מסלולים שקל להשאיר חצי מוגדרים. המנהרה עולה, מכונות החישוב עונות, והחיבור למסד הנתונים נגמר בזמן המתנה — בדיוק השילוב ששולח אנשים לקונסולה הלא נכונה.
מיתוס: IP פרטי פירושו פרטי ל-VPC
גישה לשירותים פרטיים היא VPC peering בין הרשת שלך לרשת של מפיק בבעלות Google. הטווח שהוקצה לשירות נמצא בצד המפיק, וכתובת המופע נמצאת בתוכו. ה-peering הזה הוא הסיבה לכך שמסד נתונים בפרויקט שלך יכול לשבת על כתובת שה-VPC שלך מנתב אליה בלי שאף תת-רשת מפורשת שלך תכיל אותה.
מכיוון שזה peering, יש לו גם התנהגות של peering, כולל החלק שבו מסלולים מותאמים אישית לא עוברים אוטומטית.
מיתוס: מנהרה שעובדת נושאת איתה את מסלול מסד הנתונים
שני טווחים חייבים לשרוד את המסע. הראשון הוא קידומת הלקוח: הרשת המקומית שלך חייבת להיות מוכרת ל-Cloud Router עם קידומות מסוימות, כי מסלול ברירת מחדל לא יכול לספק את הייבוא שרשת המפיק צריכה לנתיב החזרה. השני הוא טווח השירות שהוקצה, שהצד החיצוני חייב ללמוד כדי שלחבילות שלו אל מסד הנתונים יהיה לאן ללכת. אלה מסלולים שונים המתוחזקים בגבולות שונים, ותיקון האחד משאיר את השני שבור.
בצד של Google זה אומר הפעלת Export custom routes בחיבורי ה-peering הרלוונטיים והוספת טווח השירות שהוקצה למסלולים המפורסמים של Cloud Router עבור המנהרה.
שמור על הפרסומים שכבר קיימים. הוספת טווח השירות לא אמורה להסיר את מסלולי ה-VPC שאותה הפעלת BGP נושאת עבור תעבורה אחרת, וסט פרסומים שמוחלף כולו הוא תקלה שנייה שמסתתרת מאחורי הראשונה. בדוק גם את המסלולים האפקטיביים במכשיר החיצוני, כי היכולת להגיע לשער ה-VPN או לתת-רשת אחרת מוכיחה רק תעבורה.
מיתוס: Cloud SQL Auth Proxy פותר את הרשת
The Auth Proxy מספק אימות נתמך ותעבורה מוצפנת בין היישום שלך למופע. הוא לא יוצר מסלול. פרוקסי שמופעל במארח בלי נתיב לרשת הפרטית ייכשל בדיוק כמו חיבור ישיר, והלוגים שלו יהיו פחות מועילים לגבי הסיבה. העברת הפרוקסי למארח שיש לו קישוריות משנה איזה קטע של הנתיב חייב לעבוד, וזו החלטת תכנון אמיתית ולא עקיפה.
מה שהוא לא עושה הוא לאפשר למחשב נייד מנותק להגיע למופע פרטי בלבד.
מיתוס: Private Service Connect פועל לפי אותם כללים
Private Service Connect משתמש בנקודת קצה בתת-הרשת שלך ובסידור DNS שאתה שולט בו, כך שהמסלול אליו הוא מסלול רגיל לכתובת שבבעלותך. הגדרות ייצוא של peering לא חלות על התכנון הזה, והעתקת שינויי peering לפריסת PSC מוסיפה סיכון בלי להוסיף נגישות.
שניהם נותנים כתובת פרטית; הדמיון נגמר שם.
בדוק את הנתיב בסדר הנכון
מהלקוח החיצוני, בדוק קודם את נקודת הקצה TCP של מסד הנתונים. לחיצת יד TCP שהושלמה משמעה שהניתוב, חומת האש והמאזין כולם במקום, והבדיקה הבאה היא פעולה מאומתת מורשית. דחיית אימות היא למעשה חדשות טובות בשלב הזה, כי היא מוכיחה שמאזין של מסד הנתונים ענה. פסק זמן של ICMP לא אומר כמעט דבר על גישה למסד הנתונים, כי מסלולים רבים מפילים אותו בעודם מעבירים TCP בלי בעיה.
אם טווחי הלקוחות שלך מחוץ ל-RFC 1918, עיין בדרישות הנוספות לייצוא מסלולים ולהרשאות רשת לפני שתסיק שהתכנון אינו נתמך.
רשום ארבעה אובייקטים עם החיבור: הקידומת החיצונית, טווח השירות שהוקצה, חיבורי ה-peering המעורבים והנתב שמפרסם. ארבעת אלה מסבירים את כל הנתיב הפרטי, והם מחליפים את האגדה ש-Cloud SQL או שתמיד צריך פרוקסי או שאי אפשר להגיע אליו דרך VPN בכלל.