הנתב כלקוח SMB לעומת מעביר מנות: מה מתאים

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

העברה וסיום הן משימות שונות

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

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

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

מה באמת דרוש להרכבת CIFS בליבה

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

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

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

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

האישורים וזהות המקור שונים מאלה של מחשב נייד

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

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

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

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

למי שייכת התקלה כשהשיתוף נעלם

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

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

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

בדקו את ההחלטה מול המשימה בפועל

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

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

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

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