כונן ממופה דרך VPN בין אתרים: DNS, SMB ונתיב UNC
גילוי ברשת אינו חוצה קישור מנותב, אבל נתיב UNC בעל שם כן חוצה. הפנו את ה-DNS לשרת, פתחו SMB בשני הכיוונים ואז מפו את הכונן.
העמוד רשת בסייר מציג התקנים שהודיעו על עצמם במקטע המקומי, ומנהרה מנותבת אינה נושאת אף אחת מההודעות האלה. לכן שרת יכול להיות נגיש לחלוטין בזמן שהחלון מול המשתמש נשאר ריק. נתיב UNC בעל שם אינו תלוי בגילוי כלל, והפתרון הוא לגרום לשם להיפתר ולפורט להשיב. החלון הריק הוא סימפטום של שכבה שגויה, לא של שיתוף שבור.
גילוי אינו אותו דבר כמו נגישות
Windows מאתר מחשבים קרובים באמצעות פרוטוקולים שנועדו לתחום שידור, ואז מציג את מה שמצא כרשימת נוחות. שום דבר ברשימה הזו אינו נדרש לגישה לקבצים ב-SMB. לקוח שיודע את שם השרת ומגיע ל-TCP 445 יפתח את השיתוף, בין אם המחשב יופיע אי פעם תחת רשת ובין אם לאו.
שתי השכבות נכשלות באופן בלתי תלוי, ולכן "אני לא רואה את זה" ו"אני לא מצליח לפתוח" ראויים לבדיקות שונות. מבט ברשימה מספר על הגילוי; פתיחת הנתיב מספרת על השירות.
תנו שם לשרת לפני שאתם מפים את השיתוף
פרסמו את שרת הקבצים ב-DNS עם הכתובת שיש לו בצד השני, והפנו את אתר הלקוח לפותרת שיכולה להשיב עבור האזור הזה. שם מלא נמנע מתלות ברשימת סיומות חיפוש מקומית, שהיא הסיבה הרגילה לכך ששם קצר עובד באתר אחד ונכשל באחר.
אם הסביבה משתמשת ב-Active Directory, פתרון שמות הוא גם חלק מהאימות: הלקוח צריך להגיע לבקר דומיין עבור Kerberos, ושעון שסטה יותר מדי יגרום לחילופי הכרטיסים להיכשל. זו בעיה אחרת מנגישות SMB והיא נראית כמו שגיאת אישורים. בדקו את בקר הדומיין לפני שתקלידו שוב את הסיסמה.
| Layer | What it needs | Symptom when missing |
|---|---|---|
| Name resolution | A DNS answer for the server name | Path cannot be found, ping by IP still works |
| Transport | TCP 445 open in both directions | Connection times out or is refused |
| Authentication | A reachable domain controller and correct clock | Access is denied after the port connects |
| Authorization | Share permission and filesystem permission | The share opens but the folder is inaccessible |
ניתוב וסינון בשני הכיוונים
מנהרה בין אתרים זקוקה לקידומת המרוחקת בטבלת הניתוב המקומית ולקידומת המקומית בזו המרוחקת, וחומת האש בכל צד חייבת להתיר את התעבורה שמגיעה. תצורה חד-כיוונית יוצרת חיבור שנפתח ואינו משיב לעולם, מה שמשתמשים מתארים כשיתוף איטי. בדקו תחילה את מוני המנהרה עצמה. אם חבילות יוצאות ושום דבר אינו חוזר, חפשו את נתיב החזרה או את המסנן המרוחק.
ב-WireGuard, כתובות ה-IP המותרות של העמית ומסלולי מערכת ההפעלה חייבים להתאים לתכנון הזה. המנהרה נושאת חבילות; היא לא מספקת רשומות DNS או הרשאות שיתוף באף אחד מהצדדים.
בססו את כלל חומת האש על רשת המקור האמיתית שתתחבר, ורשמו את החריגה. אם התכנון מתרגם כתובות במקום כלשהו בנתיב, הכלל חייב להשתמש במקור המתורגם, וכתובת הלקוח המקורית אינה נראית עוד ביומנים.
אמתו זהות, ואז מפו את הכונן
רדו בשכבות באמצעות פקודות ולא בחלון הסייר:
Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:noהפקודה השנייה מוכיחה את נתיב ה-TCP, לא את הזכות לקרוא משהו. השלישית היא המקום שבו מופעלים האימות וההרשאה, וכשל שם אמור לשלוח אתכם להרשאות השיתוף ומערכת הקבצים, ולא חזרה לנתב.
שמרו על חתימת SMB ועל מדיניות האימות הקיימת ללא שינוי. הפעלה מחדש של SMB1 או העברת שידורי גילוי דרך המנהרה אינן נחוצות לנתיב מפורש, ו-TCP 445 צריך להישאר בנתיב הפרטי ולא בהעברה הפונה לאינטרנט. תנו למשתמשים קיצור דרך מנוהל או כונן ממופה לשם המאושר, ועמוד הרשת הריק מפסיק להיות חשוב.