גישה ל-UNC במכולות Windows: קודם השם, אחר כך הזהות
סייר המארח אינו מוכיח לא את נתיב ה-DNS של המכולה ולא את זהות ה-SMB שלה. בדקו את פתרון השמות ואת פורט 445 בתוך המכולה לפני ההרשאות.
מכולת Windows שזקוקה לשיתוף בצד השני של המנהרה שלכם נכשלת בשתי דרכים בלתי תלויות, וסייר המארח אינו מוכיח אף אחת מהן. למכולה יש נקודת קצה רשתית משלה וזהות תהליך משלה. שם שנפתר בשולחן העבודה והפעלה ששרת הקבצים מקבל שם מתארים את שולחן העבודה, לא את עומס העבודה.
סייר המארח אינו ראיה
פתיחת השיתוף במארח משתמשת בלקוח ה-DNS של המארח, בטבלת הניתוב של המארח ובחשבון שאליו התחבר המארח. תהליך של מכולה אינו יורש אף אחד מאלה באופן משתמע, גם כשהמכולה פועלת באותו מחשב ולקוח ה-VPN פועל שם גם כן. הגבול הראשון הוא נתיב הרשת: האם המכולה יכולה לפתור את השם, והאם היא יכולה לפתוח הפעלת TCP לפורט ה-SMB. השני הוא הזהות: האם שרת הקבצים מקבל את מה שהמכולה מציגה, עם ההרשאות שעומס העבודה זקוק להן.
התייחסות לשניהם כבעיה אחת מייצרת את הלולאה המוכרת של הרחבת כללי חומת אש כדי לתקן את מה שלמעשה הוא תשובת סירוב גישה מהשיתוף.
עקבו אחר הבקשה של המכולה עצמה
את הרשת של מכולות Windows מנהלת שירות רשת המארח, שיוצר נקודות קצה עם מרחב שמות רשת משלהן. המצב שבחרתם קובע אם נקודת הקצה מתורגמת, מגושרת או מחוברת לרשת משותפת עם המארח. ההחלטה הזו משנה שני דברים בבת אחת: מה המכולה יכולה לפתור, ואיזו כתובת מקור רואה שרת הקבצים.
אשרו מה המכולה עצמה צופה לפני שתשנו משהו. שם שנפתר בחוץ עלול להיכשל בפנים, כי תצורת ה-DNS של המכולה אינה זו של המארח, ונקודת קצה מתורגמת עלולה להציג מקור שכללי שרת הקבצים אינם מצפים לו.
docker exec -it app powershell -Command "Resolve-DnsName files.corp.example" docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445" docker exec -it app powershell -Command "Get-NetIPConfiguration"
אם הפתרון נכשל, תקנו את ה-DNS בתצורת הרשת במקום להחליף כתובת. החלפת השם בכתובת IP עלולה לשנות את התנהגות האימות וזהות השרת, מה שהופך בעיה אחת לשתיים. המדיניות של לקוח ה-VPN עצמו היא הדבר הבא שכדאי לבדוק, כי היא עשויה להתייחס אחרת לשני סוגי מקורות: תהליכי המארח, וכן תעבורה שמקורה במכולה.
הזהות היא החלטה נפרדת
אות כונן שממופה על ידי משתמש אינטראקטיבי אינו ממשק יישום. הוא קיים בהפעלת התחברות אחת, ותהליך של מכולה אינו חלק ממנה. השתמשו בנתיב UNC ותנו לעומס העבודה זהות שמודל הפריסה תומך בה. במקום שהדומיין תומך בכך, חשבון שירות מנוהל קבוצתי (gMSA) מספק זהות מנוהלת באמצעות מפרט אישורים.
מדריך ה-gMSA למכולות של Microsoft מתאר את סידור מפרט האישורים ואת דרישותיו המוקדמות, הכוללות חברות בדומיין ומארח שמסוגל לאחזר את האישור. החשבון, האחזור, זהות התהליך בתוך המכולה והרשאות השיתוף חייבים כולם להסתדר יחד. התחברות VPN אינה הזהות הזו, ואפיית סיסמה בתוך תמונה כדי לשחזר את הפעלת המשתמש במארח יוצרת חשיפה מתמשכת.
השאירו את השלב הכושל גלוי
כשל פתרון, סירוב חיבור וסירוב גישה זקוקים לראיות שונות. אלה בהתאמה שאלת DNS, שאלת ניתוב או סינון, ושאלת אימות או הרשאות. קראו את התגובה שהמכולה קיבלה ולא את שגיאת היישום הכללית.
בדקו עם הזהות של עומס העבודה עצמו ובדקו גם סירוב.
תכננו את ההתחברות מחדש
נתיבי VPN נופלים. כשהמנהרה חוזרת, נקודת קצה עשויה לחזור עם כתובת מתורגמת אחרת, והפעלת SMB קיימת עשויה להיות מתה בלי שהיישום ישים לב. טפלו בזה ביישום: שחזרו את הנתיב ואת הזהות, נסו שוב את הפעולה, ויישרו פעולת קובץ עם תוצאה לא ידועה במקום להניח ששום דבר לא קרה.
רשמו את מצב הרשת, מקור ה-DNS וסידור הזהות בהערות הפריסה. בדיוק שלוש העובדות האלה יהיו נושא הכשל הבא.