נקודת קצה פרטית, אותו שם שרת: מחרוזות חיבור של Azure SQL

Private Link משנה היכן חיבור נוחת, לא כיצד החיבור נקרא. עבור Azure SQL Database ההבחנה הזו היא כל התכנון: השרת הלוגי שומר על שמו, ונקודת הקצה הפרטית מספקת רשומת רשת שאליה השם נפתר. החלפת השם בכתובת IP היא השינוי היחיד ששובר TLS, פרטי התחברות וכלים בו-זמנית. שתי מחרוזות חיבור יכולות להיראות שקולות ולהתנהג אחרת לגמרי.

שמרו על orders-db.database.windows.net ותנו ללקוח תשובה פרטית עבורו.

לשם ולכתובת יש תפקידים שונים

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

ההנחיה של Microsoft ל-Azure SQL דורשת את שם השרת הרגיל מהלקוחות. IP ישיר, וכך גם השם עם הקידומת privatelink, אינו יעד התחברות שניתן להחליף. כלים שמקבלים IP יקבלו אותו ואז ייכשלו ב-TLS או באימות, מה שמסתיר את הטעות האמיתית. הכשלים האלה נקראים כמו בעיות פרטי התחברות עד שמסתכלים על שם המארח בשגיאה.

מה האזור הפרטי באמת משנה

אזור ה-DNS הפרטי רושם כתובת אחת עבור השרת בתוך מרחב השמות privatelink, והאזור מקושר לרשת הווירטואלית שאמורה להשתמש בו. הפתרון זז; מחרוזת החיבור לא. הצורה שלמטה היא המחשה, לא רשומה להדביק באזור ציבורי.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

תחזקו את הרשומה ואת קישור האזור שלה כתשתית, עם בעלים ותאריך סקירה.

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

לקוחות מחוץ ל-Azure צריכים נתיב אל האזור הזה

לקוח VPN יושב מחוץ לפותר של Azure, ולכן האזור הפרטי חייב להיות נגיש מהנתיב ההיברידי. מעביר DNS של Azure או Azure DNS Private Resolver יכולים לשרת שאילתות שמגיעות דרך הרשת ההיא. ההנחיה של Microsoft היא להעביר את אזור השירות הציבורי הרלוונטי דרך הסידור הזה במקום להניח שלקוחות שואלים את השם privatelink ישירות. לקוחות שאינם יכולים לפתור את התשובה הפרטית נופלים בחזרה לזו הציבורית בלי להתלונן.

שמרו על היקף ההעברה מכוון, כי החלפת אזור ציבורי בשימוש שוברת שמות שההחלפה אינה מכילה.

הקצו בסדר ששומר על הזהות קבועה

לשלבים יש בעלים נפרדים: צרו ואשרו את נקודת הקצה, ספקו את נתיב ה-VPN, שלבו DNS פרטי, ואז קנפגו את הלקוח עם שם השרת הרגיל שלו. עשיית DNS לפני הנתיב מייצרת פסקי זמן שנראים כמו כשלי DNS. עשיית הלקוח אחרון משאירה משתנה אחד בתנועה בכל פעם. לכל שלב יש תוצאה ניתנת לצפייה, ולכן אף אחד מהם לא צריך להיבדק בניחוש.

סמל VPN מחובר אינו בוחר יעד פרטי בעצמו.

מה נקודת קצה פרטית אינה מכבה

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

בדקו גם איזו מדיניות חיבור השרת משתמש.

Redirect שולח את הלקוח ליציאה על הצומת לאחר חיבור שער ראשוני, מה שמשנה מה רשת הלקוח חייבת לאפשר. Proxy שומר את התעבורה על השער. לחיצת יד TCP מוצלחת ביציאה אחת אינה כל תהליך העבודה של ההתחברות.

זהו Azure SQL Database, לא SQL Managed Instance, שיש לה מודל קישוריות משלה ואין לה סיפור נקודת קצה פרטית מקביל. בשני המקרים, שמרו שלושה דברים מתויגים בנפרד: השם, רשומת הרשת ופרטי ההתחברות. שינוי היכן חיבור נוסע לא אמור לשנות לעולם באיזה שירות הלקוח חושב שהוא מדבר.