שאלת ראיון לסיסטם: יש אינטרנט, אז למה תיקיית הרשת לא נפתחת?

יום ראשון, תשע בבוקר. משתמש מהכספים מתקשר: ״אני לא מצליח להיכנס לתיקייה של המחלקה. אתמול הכול עבד, והאינטרנט דווקא עובד מצוין״. ב־Help Desk זו עוד קריאה בתור. בראיון לתפקיד סיסטם זו הזדמנות להראות איך אתם חושבים כשאין עדיין תשובה.

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

שלב 1: לפני הפקודות — מה בדיוק לא עובד?

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

• ▸היקף: האם עמית מאותה מחלקה מצליח לפתוח את אותה תיקייה מהמחשב שלו? אם כולם נפגעו, עולה החשד לתשתית או לשרת — לא רק לפרופיל המשתמש.
• ▸מיקום: האם המשתמש במשרד או מחובר דרך VPN? חיבור לאינטרנט אינו מבטיח ניתוב לרשת הפנימית או שימוש בשרתי ה־DNS הארגוניים.
• ▸סוג הכשל: האם אי אפשר לפתוח את התיקייה, או שאפשר לקרוא אבל לא לשמור? כשל בכתיבה בלבד מכוון גם להרשאות, מכסה או מקום פנוי.
• ▸נתיב: מה הכתובת האמיתית מאחורי אות הכונן? אם זה נתיב DFS, ייתכן שהגישה עוברת דרך מרחב שמות והפניה לשרת אחר. לא מניחים שהשם בכונן הוא בהכרח שרת הקבצים עצמו.

שלב 2: מפרידים בין כונן ממופה לתיקייה עצמה

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

\\fs01.corp.example\Finance

שלב 3: בודקים DNS — אבל לא נותנים ל־ping להטעות

אפשר להשוות ping לפי שם ולפי כתובת IP כבדיקה ראשונית, אבל לא לקפוץ למסקנה. אם השם לא נפתר או נפתר לכתובת שגויה, יש כיוון ברור ל־DNS. לעומת זאת, היעדר תשובה ל־ping לא מוכיח שהשרת נפל: ייתכן ש־ICMP חסום. וגם אם מתקבלת תשובה — עדיין לא בדקנו את שירות שיתוף הקבצים.

Resolve-DnsName fs01.corp.example
ipconfig /all
Test-NetConnection fs01.corp.example -Port 445
Test-NetConnection 10.20.30.40 -Port 445

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

שלב 4: האם בכלל מגיעים לשירות הקבצים?

בתרחיש Windows ארגוני רגיל, SMB משתמש ב־TCP 445. תוצאה חיובית ב־Test-NetConnection אומרת שחיבור TCP ליעד ולפורט הצליח — לא שההזדהות או ההרשאות הצליחו. תוצאה שלילית מחייבת לבדוק ניתוב, VPN, חומת אש, זמינות שרת ושירות שמאזין. לא מאפסים סיסמה כדי לתקן פורט חסום.

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

שלב 5: זהות והרשאה הן שתי שאלות שונות

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

אחר כך בודקים הרשאות שיתוף וגם הרשאות NTFS. בגישה דרך הרשת צריך שהפעולה המבוקשת תהיה מותרת בשתי השכבות. חברות בקבוצה עם הרשאת קריאה לא מעניקה כתיבה, והרשאת שיתוף רחבה לא עוקפת NTFS מוגבל. בודקים הרשאות אפקטיביות, קבוצות מקוננות, ירושה ו־Deny רלוונטי — לא רק שורה אחת עם שם המשתמש.

whoami /user
whoami /groups
net use
Get-SmbConnection

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

שלב 6: רק הכונן נעלם? עכשיו מגיעים ל־GPO

אם הנתיב הישיר עובד, בודקים איך הכונן נוצר: מיפוי ידני, סקריפט כניסה או Group Policy Preferences. במיפוי דרך GPO בודקים האם המדיניות חלה על המשתמש, סינון אבטחה, תנאי Item-level targeting, שיוך ל־OU וגישה לבקר דומיין. שינוי חברות בקבוצה יכול להשפיע גם על תנאי המיפוי, לא רק על הרשאות התיקייה.

gpresult /r /scope user
gpresult /h "$env:TEMP\gp-report.html"
gpupdate /target:user /force

אפשר להריץ גם gpupdate /force כשצריך לרענן את מדיניות המשתמש והמחשב. אבל הפקודה אינה מתקנת נתיב שגוי, DNS תקול, הרשאות חסרות או מדיניות שלא חלה מלכתחילה. בודקים את תוצאת הרענון ואת יומן GroupPolicy; אם נדרשת יציאה או הפעלה מחדש, מתאמים עם המשתמש ולא קוטעים עבודה.

שלב 7: שירותים מקומיים ולוגים — בלי ריסטארט על עיוור

שירות Workstation אחראי בצד הלקוח לחיבורי SMB. בודקים את מצבו, ובכשלי פתרון שם גם את DNS Client ואת האירועים המתאימים. בצד שרת הקבצים רלוונטי גם שירות Server. מצב שירות הוא ראיה אחת: שירות פעיל לא מבטיח שהכול תקין, ושירות שנעצר מחייב להבין מה עצר אותו.

Get-Service -Name LanmanWorkstation,Dnscache

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

כך זה נשמע בראיון אמיתי

״אני קודם מבקש את השגיאה המדויקת ובודק למי עוד זה קורה. אחר כך מנסה את הנתיב הישיר כדי להפריד בין מיפוי לבין גישה לשיתוף. בודק פתרון שם וחיבור ל־445, ואז זהות והרשאות בשיתוף וב־NTFS. אם הגישה הישירה עובדת, מתמקד ב־GPO. כל צעד אמור לשלול השערה, ובסוף אני מוודא שהמשתמש שוב פותח ושומר בהתאם להרשאות שלו — ומתעד מה היה השורש.״

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

הסגירה המקצועית: לא רק ״אצלי נפתח״

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

שאלות המשך שכדאי להתכונן אליהן

• ▸השרת עונה ל־ping, אבל TCP 445 לא נגיש. מה הבדיקה הזאת מוכיחה, ומה היא עדיין לא מוכיחה?
• ▸המשתמש פותח את התיקייה, אבל לא יכול לשמור. איך תבדילו בין הרשאות, מכסה ומקום פנוי?
• ▸הוספתם משתמש לקבוצה הנכונה והוא עדיין מקבל גישה נדחית. אילו חיבורים וטוקנים צריכים להתעדכן?
• ▸הנתיב הישיר עובד, אבל הכונן נעלם אחרי מעבר מחלקה. איך תבדקו את המדיניות ואת תנאי המיפוי?

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