שמות מארח של VPN נכשלים, כתובות IP עובדות: היכן לחפש

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

שם שואל שאלה שכתובת אינה שואלת

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

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

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

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

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

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

Get-DnsClientNrptPolicy
ipconfig /all

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

סיומות מסבירות שמות קצרים שנכשלים

שם בעל תווית אחת מורחב עם רשימת הסיומות של החיבור לפני שהשאילתה נשלחת. אם ה-VPN לא מספק את הסיומת הפנימית, fileserver לעולם לא הופך ל-fileserver.corp.example, והשאילתה יוצאת כשם שאף מפענח ציבורי לא מכיר. דחיפת הסיומת, או הקלדת השם המלא, בודקת את ההשערה בלי לשנות דבר בשרת.

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

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

NetBIOS ו-WINS הם מנגנון אחר

SMB ישן עדיין יכול לחפש שם חשוף עם שירות השמות NetBIOS, שעונה בשידור או דרך שרת WINS. השידור נשאר בתוך תחום שידור אחד ועוצר בנתב הראשון, ולכן אינו יכול לעבור מנהרה; WINS עובד מפני שלקוח יש כתובת יוניקאסט שאליה להירשם ואותה לשאול. לכן VPN שנושא IP בלבד עדיין יכול לתמוך בשמות ישנים כשה-WINS מוגדר ונגיש.

nbtstat -n
nbtstat -R

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

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