מדוע שם שרת מתורגם לכתובת ה-VPN שלו לאחר חיוג נכנס

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

שתי כתובות, שם אחד, שלושה תנאים

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

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

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

קראו את הרשומה לפני שתשנו את הרשם

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

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

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

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

תקנו את המפרסם או את הרשומה, אבל דעו מה

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

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

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

אמתו מרשת הלקוח שנכשלה

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

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

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

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