DNS של Azure P2S נכשל כאשר ה-resolver נמצא ב-VNet מקושרת

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

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

תארו לעצמכם מחשב נייד שמנהר אל שער ב-VNet2, כאשר בקר התחום שמשרת DNS יושב ב-VNet1.

שתי טופולוגיות, הבדל אחד

שימו את ה-resolver בתוך הרשת הווירטואלית של השער עצמו והשם ייפתר ברגע שהמנהור עולה. שום הגדרת קישור אינה משתתפת באותה חיפוש.

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

צד א': לאפשר מעבר שער אצל בעל השער

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

הגדירו Allow gateway transit בקישור של VNet2 לכיוון VNet1. המאפיין שייך לאובייקט הקישור ולא למשאב השער, לכן קוראים ומשנים אותו בלהב הקישור. זה כל צד א'.

צד ב': להשתמש בשערים מרוחקים אצל העמית

החצי השני הוא תמונת הראי: בקישור של VNet1 בחזרה ל-VNet2 הפעילו Use remote gateways. הפעלת אותו דגל בשני הקצוות, או רק באחד, משאירה נתיב חצי בנוי ואת הסימפטום המקורי ללא שינוי. רק הרשת עם שער ה-VPN מתירה מעבר, והעמית הוא הצד שמשתמש בו.

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

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

לראות את הזוג זה לצד זה היא הדרך המהירה ביותר לתפוס הגדרה הפוכה. קישור שמדווח AllowGatewayTransit false בצד השער מסביר את כל הכשל בלי ללכוד חבילה.

מה הלקוח חייב עדיין לקבל

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

שאלו את ה-resolver מהמחשב הנייד המחובר לפני שתשנו משהו אחר.

nslookup dc01.corp.example 10.1.0.4

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

השוו את אותו חוזה בצד אתר-לאתר

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

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

לפני שאתם מאשימים את השער

Windows מחזיק רשימת resolvers לכל מתאם, לכן ודאו מה ממשק המנהור באמת קיבל לפני שאתם מאשימים את השער.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

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

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

מאמרים קשורים