שיתוף SMB נכשל רק דרך VPN: חתימה או התנגשות רשתות משנה?
שיתוף שעובד ברשת המקומית עלול להיכשל רק דרך המנהרה. הפרידו בין דחיית חתימה, רשת משנה חופפת והפעלה ישנה של SMB.
כונן ממופה שעובד במשרד ופג תוקפו בבית לא נותן לכם כמעט שום מידע שימושי בפני עצמו. המנהרה בבירור מעבירה מנות, אחרת שום דבר לא היה מגיע לשרת. מה שנכשל נמצא באחד משלושה רבדים: השם נפתר לכתובת הלא נכונה, הלקוח סירב לחתום על ההפעלה, או הפעלה ישנה שרדה את החיבור שנשא אותה. לכל אחד תיקון אחר, ושניים מהשלושה בצד הלקוח.
שלושה כשלים נושאים את אותה שגיאה
אות הכונן לא אומר איזה רובד נשבר, וטקסט השגיאה בדרך כלל כללי מספיק כדי להתאים לכל השלושה. הפרידו ביניהם בשתי שאלות מהירות: האם השרת עונה בכתובת ה-IP שלו, והאם פורט 445 מקבל חיבור?
התשובות האלה נותנות טבלת החלטה במקום ניחוש. אם ה-IP עובד והשם לא, זה מצביע על פתרון השמות. אם שניהם עובדים וההתחברות נדחית, זה מצביע על החתימה. אם שניהם עובדים וקריאת קובץ נתקעת אחרי נפילת מנהרה, זה מצביע על הפעלה ישנה.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
עברו עליהם בסדר הזה, כי שם שנפתר למארח הלא נכון הופך כל בדיקה מאוחרת יותר לחסרת משמעות.
פתרו את השם לפני שאתם נוגעים בשיתוף
אם השרת עונה בכתובת שלו ושם השיתוף פג תוקפו, המנהרה עושה את עבודתה והלקוח מחפש במקום הלא נכון. בגישה מרחוק, שתי סיבות מסבירות את רוב זה.
הראשונה היא חפיפת כתובות. כשהמשרד משתמש ב-192.168.70.0/24 והנתב הביתי מחלק את אותו טווח, שם מארח שנפתר ל-192.168.70.20 עלול להצביע על התקן מקומי במקום על השרת שמאחורי המנהרה. Windows עשוי אז לשלוח את הבקשה מקומית, לדחות את המסלול או לפתור למדפסת שבמקרה יש לה את הכתובת הזו. התיקון הוא למספר מחדש צד אחד, לא להוסיף מסלול נוסף.
השנייה היא היקף DNS. מתאם VPN בלי שרת DNS פנימי, או עם כזה שאינו נגיש דרך המנהרה, משאיר שמות קצרים לפותר ציבורי. קראו את רשומות ה-DNS של המתאם ושאלו ישירות את השם הפנימי לפני שאתם נוגעים בשיתוף:
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15אם השאילתה הזו מחזירה את הכתובת הצפויה, פתרון השמות מוכרע והבעיה גבוהה יותר במחסנית.
קראו את דרישת החתימה בשני הקצוות
שרת נגיש שדוחה כל התחברות הוא סימן לאי-התאמה במדיניות ולא לתקלת רשת. Windows יכול לדרוש חתימת SMB בלקוח, ושרת או NAS שלא חותם לא יכול להשלים את ההפעלה, לא משנה כמה המנהרה בריאה.
אפשר לקרוא את הגדרת הלקוח בלי לחפש בעורך המדיניות:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionהערך המתאים בצד השרת נמצא בקונפיגורציית ה-SMB של השרת, והשניים חייבים להסכים. במקרה שדווח, בלקוח הדרישה הייתה מופעלת על ידי מדיניות מקומית בעוד השרת לא חתם כלל; כיבויה והרצת gpupdate /force החזירו את השיתוף מיד. זהו צעד אבחוני לאישור הסיבה, לא תיקון קבוע.
העדיפו להפעיל את החתימה בשני הקצוות היכן שהשרת תומך בכך. שינוי הגדרת אבטחה כדי ששיתוף יעבוד צריך להירשם עם הערך הקודם והסיבה, כדי שאיש לא יצטרך לגלות אותו מחדש בביקורת הבאה.
נקו את ההפעלה הישנה לפני כיוונון הטיימרים
שיתוף שנתקע רק אחרי שה-VPN נופל ומתחבר מחדש בדרך כלל מחזיק הפעלה שהשרת כבר השליך. השרת סוגר הפעלות SMB לא פעילות לפי טיימר Autodisconnect תחת LanmanServer\Parameters, שברירת מחדל הוא 15 דקות, בעוד שלקוח יש SessTimeout משלו תחת LanmanWorkstation\Parameters. הפסקה ארוכה מהערכים האלה משאירה כל קצה עם תפיסה שונה של ההפעלה.
שחזרו זאת בסדר קבוע כדי שהתוצאה תאמר משהו: חברו את המנהרה, פתחו את השיתוף, נתקו את המנהרה לשתי דקות, החזירו אותה ואז נסו לקרוא קובץ. אם ההרכבה מתאוששת מעצמה, הניחו לטיימרים. אם היא נתקעת עד שמרכיבים מחדש, חברו את השיתוף מחדש אחרי שהמנהרה עלתה במקום להרכיב אותו לפני שהוא קיים, ובדקו אם עוזר ההרכבה מנסה שוב.
העלאת פסקי הזמן היא צעד אחרון סביר לקישור לא יציב, אבל היא מטפלת בסימפטום. לקוח שממתין יותר להפעלה שהשרת שכח עדיין ממתין.
סיימו בקריאת קובץ אחד דרך ההרכבה ואז בניתוק והחזרה של המנהרה פעם נוספת. מבחן הקבלה הזה מכסה את כל שלושת הרבדים בבת אחת, והוא המבחן היחיד שמתאים למה שהמשתמש באמת עושה.