למה Samba דוחה לקוחות VPN שמצליחים להגיע לשרת

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

ארבע שכבות שנכשלות עם אותה הודעה

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

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

מצאו את כתובת המקור ש-smbd באמת רואה

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

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

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

קראו את רשימת ההיתרים כפי ש-Samba קורא אותה

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

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

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

שנו את הקובץ ששורד אתחול

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

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

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

בדקו לקוח מורשה אחד ולקוח מוחרג אחד

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

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

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