השיתוף המקומי של Samba נעלם לאחר ש-OpenVPN דחף DNS

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

חמש בדיקות, בסדר שמסלק את מרב האפשרויות בכל שלב.

מי עונה על השם הקצר

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

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

למה Samba מאמינה לתשובה שגויה

Samba מפענחת שמות באמצעות רצף קבוע שנקבע על ידי name resolve order. ברוב ההפצות ברירת המחדל כוללת את host, כלומר DNS, והוא פועל לפני מנגנונים המיועדים רק לרשת המקומית כמו שידור NetBIOS. לכן מנהרה שדוחפת פותר מקבלת זכות סירוב ראשונה על כל שם שיתוף, כולל שמות חד-תווית שמעולם לא היו אמורים לצאת מהבניין.

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

התוצאה היא שיתוף שנעלם בלי תיבת שגיאה. שום דבר ברצף הזה אינו כשל ניתוב VPN, ולכן פינג ל-NAS עדיין עובד בעוד גלישה אליו אינה עובדת.

שני תיקונים בהיקפים שונים

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

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

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

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

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

הסיומת יכולה להסביר הכול

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

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

הוכיחו זאת אחרי התחברות מחדש

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

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

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