ה-VPN שלך לא הופך את Cosmos DB לפרטי בעצמו
VPN מביא את המחשב הנייד שלך אל הרשת, לא אל תוך מסד הנתונים. ראו מה חייבים לעשות נקודת הקצה הפרטית, אזור ה-DNS, מצב החיבור והגישה לחשבון.
אתם מחברים את המחשב הנייד ל-VNet דרך VPN, פותחים את כתובת ה-URL של חשבון Cosmos DB, והבקשה עדיין יוצאת דרך האינטרנט הציבורי. המנהרה עשתה את שלה. מה שהיא לא עשתה הוא ליצור נקודת קצה פרטית, לפרסם את רשומת ה-DNS הפרטית או לכבות גישה ציבורית, כי אלה שלושה שינויים נפרדים בחשבון ולא תכונות של חיבור הרשת שלכם. הדוגמה הזו משתמשת ב-Azure Cosmos DB עבור NoSQL, בנקודת קצה פרטית ב-VNet ובמחשב נייד שמחובר לאותו VNet דרך VPN, והיא משאירה את כתובת האפליקציה ללא שינוי.
המיתוס: להיות ב-VPN הופך את מסד הנתונים לפרטי
להיות ב-VNet אומר רק שהחבילות שלכם יכולות להגיע לכתובות פרטיות באותו VNet. זה לא אומר דבר על היכן שם החשבון נפתר, וזה לא אומר דבר על האם החשבון עדיין מקבל תעבורה ציבורית.
נקודת קצה פרטית היא משאב נפרד עם הכתובת שלו, שלב האישור שלו וחיווט ה-DNS שלו. עד שהיא קיימת ומאושרת, השם נפתר לנקודת הקצה הציבורית והתעבורה שלכם הולכת לשם ללא קשר למנהרה.
מה באמת גורם לשם להיפתר באופן פרטי
השאירו את נקודת הקצה הרגילה של החשבון מה-SDK, משהו כמו https://ACCOUNT.documents.azure.com. DNS פרטי אמור לפתור את השם הזה דרך שרשרת Private Link לכתובות הפרטיות של נקודת הקצה. אל תחליפו אותו בכתובת URL מספרית ואל תכבו בדיקות תעודות, כי זה מחליף בעיית DNS בבעיית אבטחה.
| Example choice | Value |
|---|---|
| Cosmos API | NoSQL |
| Private endpoint subresource | Sql |
| Private DNS zone | privatelink.documents.azure.com |
| SDK connection mode | Gateway |
הערכים האלה ספציפיים ל-API של NoSQL. ממשקי Cosmos API אחרים אינם רשומות ניתנות להחלפה באותה דוגמה, והעתקת שם תת-המשאב מ-API אחרת מייצרת נקודת קצה שלעולם לא נפתרת.
צרו ואשרו את נקודת הקצה דרך זרימת העבודה המורשית של Azure, ואז השתמשו באינטגרציה שלה עם קבוצת אזורי DNS פרטיים. המחשב הנייד צריך פותר שיכול לענות עבור האזור הזה, בין ישירות ובין דרך העברה מאושרת, ומסלול לקוח VPN לכל כתובת רלוונטית של נקודת הקצה.
לנקודת קצה פרטית יכולות להיות יותר מכתובת אחת, כולל רשומות גלובליות ואזוריות. תחזקו את אינטגרציית ה-DNS כשאזורי החשבון משתנים במקום לנעוץ כתובת אחת בקובץ hosts, וזכרו שתשובה מפותר ציבורי לא קשור אינה מוכיחה דבר על המסלול הפרטי. אם אתם מעבירים DNS דרך רכזת, ודאו שהמעביר עונה לפני שאתם מדבגים את הלקוח. מעביר מיושן מחזיר את התשובה הציבורית, שנראית בדיוק כמו נקודת קצה חסרה.
מצב Gateway ומצב Direct אינם ניתנים להחלפה
מצב Gateway שולח בקשות שירות דרך HTTPS על TCP 443. לכן מדיניות חומת אש ל-443 בלבד עובדת איתו ולכן הדוגמה הזו בוחרת בו בכוונה.
למצב Direct דרך Private Link יש דרישות קישוריות שונות, כולל טווח פורטי TCP רחב יותר שהתיעוד של החשבון מפרט. אסור לעשות שימוש חוזר שקט במדיניות שנכתבה למצב Gateway עבור לקוח במצב Direct, אחרת ה-SDK יתחבר ואז ייתקע בפעולת הנתונים הראשונה.
בחרו מצב אחד, רשמו אותו יחד עם החשבון, והתאימו את מדיניות הרשת אליו. צוותים שמחליפים מצבים במהלך פתרון תקלות בדרך כלל מסיימים עם סט חוקי חומת אש שלא מספק אף אחד מהשניים.
כיבוי גישה ציבורית הוא מתג נפרד
אם החשבון אמור להיות פרטי בלבד, כבו גישה לרשת הציבורית דרך ההגדרה הנתמכת של החשבון ואמתו את התוצאה. אל תתייחסו לקיומה של נקודת קצה פרטית כאל החלטת הגישה המלאה, כי חשבון עם נקודת קצה פרטית וגישה ציבורית מופעלת עדיין עונה באינטרנט.
אמתו מחוץ ל-VPN וגם מבפנים. בקשה מרשת שאמורה להיות מוחרגת היא הבדיקה שמוכיחה שההגדרה נכנסה לתוקף, וזו הבדיקה שרוב חלונות השינוי מדלגים עליה.
נגישות אינה הרשאה
פעולת SDK מורשית מהמחשב הנייד ב-VPN היא בדיקת הקבלה, תוך שימוש בכתובת ה-URL הרגילה של החשבון ובזהות המיועדת. נגישות VPN אינה מעניקה הרשאות נתונים של Cosmos; מישור הנתונים בודק את התפקידים או המפתחות שלו עצמו.
אחר כך הריצו את הדחיות: זהות אחרת ומסלול רשת שאמור כבר לא להגיע לחשבון. אם אחד מהם מצליח, הגבול שתיעדתם אינו הגבול שבניתם.
רשמו ארבע עובדות בסיום: הכתובות הפרטיות של נקודת הקצה, אזור ה-DNS שעונה עבור שם החשבון, מצב החיבור עם דרישות הפורטים שלו והאם גישה ציבורית כבויה. ארבעת אלה מסבירים את ההגדרה לאדם הבא, וכל אחד מהם נכשל באופן עצמאי.