Azure P2S VPN לא מצליח לפתור שם של נקודת קצה פרטית

אתם מתחברים למנהרת point-to-site, עושים ping לכתובת הפרטית, פותחים את האפליקציה ומקבלים במקום זה 403 או שגיאת תעודה. שני הסימפטומים מצביעים על DNS, אבל אלו תקלות שונות: האחד אומר שהלקוח פתר את הכתובת הציבורית, והשני אומר שהוא פתר את הכתובת הפרטית ואז הציע שם שהתעודה אינה מכסה. עברו על הבדיקות שלמטה לפי הסדר ועצרו בכשל הראשון, כי רשומת hosts או תשובה ששמורה במטמון יכולות לגרום לכל בדיקה מאוחרת לעבור מהסיבה הלא נכונה. אני שומר את הסדר הזה בקובץ טקסט לצד פרופילי ה-VPN שלי, כי התיקון לא משנה דבר במנהרה ומשנה הכול במה שהלקוח יודע.

התחילו בכתובת שהלקוח באמת מקבל

שאלו את הפותר ישירות במקום לסמוך על האפליקציה. ב-Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net מראה איזה מבט קיבל הלקוח. תשובה ציבורית משמעה ששום דבר בהמשך לא יגיע לנקודת הקצה; הכתובת הפרטית של נקודת הקצה משמעה ש-DNS הסתיים והבדיקה הבאה היא החיבור עצמו.

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

בדקו את האזור, את הקישור שלו ואת הרשומה לפני המנהרה

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

שמות אזורים שייכים לשירותים, לא לקישורים פרטיים באופן כללי. App Service משתמש בדרך כלל ב-privatelink.azurewebsites.net, לאחסון ול-SQL יש מרחבי שמות משלהם, והשאלת אזור של שירות אחר יוצרת אזור שקיים ולא עונה שום דבר שימושי.

תנו ללקוח פותר שהוא באמת יכול להגיע אליו

168.63.129.16 עונה ממכונות וירטואליות של Azure ואינו שרת DNS עבור מחשב נייד בצד השני של מנהרת point-to-site. הלקוח זקוק לפותר נגיש דרך המנהרה: נקודת קצה נכנסת של Azure DNS Private Resolver, מעביר בתוך הרשת הווירטואלית, או רשומות שרת DNS שנישאות בפרופיל לקוח ה-VPN כדי שהלקוח ישאל את הרשת הווירטואלית ישירות.

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

אם אתם מעבירים במקום לדחוף הגדרות, העבירו את מרחב השמות שהאזור הפרטי מחזיק בו, privatelink.azurewebsites.net ולא את כל azurewebsites.net. מעביר מותנה שבולע את כל הסיומת של האב שולח כל חיפוש של השירות ל-Azure, כולל אלה שאמורים להישאר מקומיים.

השתמשו בשם שעבורו הונפקה התעודה

כשהכתובת נכונה, התקלה השנייה מגיחה. האחסון ו-App Service מפרסמים כינוי privatelink, והכינוי הזה אינו בהכרח השם בתעודה. העלאת AzCopy שמוענה ל-privatelink.blob.core.windows.net נכשלה באימות; אותה העלאה ל-<account>.blob.core.windows.net/<container> נפתרה לכתובת הפרטית ועברה, ולכן היא נשארה בנתיב הפרטי בלי שום עקיפה.

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

סדר של ארבעה שלבים שמבודד כל שכבה

1. ודאו שלקוח ה-VPN יש כתובת ממאגר point-to-site ומסלול לכתובת הפרטית של נקודת הקצה.
2. פתרו את השם המדויק שהאפליקציה משתמשת בו והשוו את התשובה לכתובת נקודת הקצה.
3. פתחו חיבור TCP לנקודת הקצה בפורט של השירות, ואז קראו את שם התעודה שמוצג בחיבור הזה.
4. רק עכשיו בדקו הרשאה, כי מסלול עובד ותעודה תקפה עדיין לא נותנים גישה למשאב.

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

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

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

לאן שייכת רשומת hosts

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

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

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