שיתוף ה-CIFS שלכם נכשל דרך VPN בגלל סדר ה-nsswitch

המנהרה פעילה. שרת הקבצים עונה ל-ping לפי כתובת. אחר כך mount.cifs עם שם המארח יושב שם זמן מה ומדווח שהמארח אינו נגיש, ואתם מתחילים לבנות מחדש פרופיל VPN שמעולם לא היה הבעיה. ב-Linux ‏glibc מפענח את השם לפני שקיימת ולו חבילת SMB אחת, והסדר באותו resolver יכול לסיים את החיפוש לפני ש-DNS נשאל בכלל. זה המסלול שאני עובר, החל מהפקודה שנכשלה ולא מהלקוח.

קראו את הכשל במקום הנכון

שני כלים הולכים בדרכים שונות לאותו שם, והשוואה ביניהם עולה פקודה אחת. getent עובר דרך מחסנית שירותי השמות המוגדרת; host ו-dig שואלים את DNS ישירות ומתעלמים מאותה מחסנית. אם השאילתה הישירה מחזירה כתובת ו-getent לא מחזיר דבר, שרת ה-DNS נגיש וזו תצורת ה-resolver שלכם שנכשלת.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

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

שורת hosts היא רצף שנעצר מוקדם

ה-resolver של glibc קורא את /etc/nsswitch.conf ועובר על הערך hosts: משמאל לימין. הפצות רבות מספקות שורה שבה חיפוש multicast בא ראשון עם פעולת חזרה מוקדמת מחוברת. הפעולה אינה קישוט: כש-mDNS עונה “not found”, ‏[NOTFOUND=return] מסיים את כל החיפוש, ולכן השם הארגוני לעולם אינו נשלח ל-resolver שה-VPN דחף. שום דבר לא מתעד זאת, כי לא נשלחה שום שאילתה שה-resolver יוכל לדחות. לכן ה-mount נראה תלוי ואז מדווח על מארח לא נגיש.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

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

resolver אינו תחום חיפוש

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

בדקו את שתי הצורות לפני עריכת הפרופיל, כי שני הכשלים מצביעים לכיוונים שונים. במארח עם systemd-resolved לקישור המנהרה יש שרתים ותחומי ניתוב משלו, ולכן קראו את הקישור ולא את הקובץ הגלובלי.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

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

קונטיינרים נושאים עותק משלהם של התשובה

קונטיינר שנבנה מתמונה כללית מגיע בדרך כלל עם resolv.conf קבוע. שינויי resolver שנעשו במארח אינם מגיעים אליו, וגם לא תחום החיפוש, ולכן משימת build שמעלה שיתוף דרך המנהרה נכשלת בעוד אותה פקודה עובדת מחוץ לקונטיינר. תנו לקונטיינר הגדרות DNS וחיפוש משלו בקובץ ה-compose או בארגומנטים של run, ולא רק בפרופיל המארח.

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

ורק אז הסתכלו על השיתוף ועל המסנן

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

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

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

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