NetBIOS מעל VPN: שם, דאטגרם והפעלה הם שירותים נפרדים
הסלוגן על נתבים רחב מדי. בדקו איזה משלושת השירותים היישום שלכם משתמש בו, והאם הוא פותר שמות בשידור או בשרת.
«NetBIOS לא עובר נתבים» חוזר ונאמר כאילו הכריע את התכנון. הוא לא. חיפוש שם בשידור נשאר בדרך כלל בתוך תחום השידור שלו, אבל שירותי NetBIOS יכולים להשתמש גם בתעבורת IP מכוונת שמנותבת היטב. השאלה המועילה אינה אם NetBIOS עובר נתבים; היא איזה משלושת השירותים שלו היישום שלכם משתמש בו.
ממשק תוכנה, לא פרוטוקול חוט אחד
RFC 1001 מתאר את NetBIOS כממשק שתוכניות מתכנתות מולו, עם כמה שכבות תעבורה מתחתיו. מודל ה-TCP/UDP שלו מפריד בין שירות השמות, הפצת דאטגרמים ושירות ההפעלה, והוא תומך במפורש בפעולה עם שידור IP או בלעדיו.
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
הטבלה הזאת היא הסיבה שהסלוגן נכשל. שירות הפעלה בין שני מארחים בעלי שם הוא שיחת IP; דאטגרם שידור אינו כזה. תכנון VPN אחד יכול לספק את הראשון ולא את השני, ובדיקה שמוכיחה את הראשון אינה אומרת דבר על השני.
סוגי הצמתים קובעים מה הלקוח מבקש
מודלי הצמתים של שידור, נקודה לנקודה ומשולב ב-RFC 1001 מתארים כיצד מארח פותר שמות: בשאילת הרשת המקומית, בשאילת שרת שמות ישירות, או בניסיון של האחד ואחר כך של האחר. המודל משפיע על איזו תעבורה יש לאפשר, ולא על האם היישום עובד בכלל.
סידור מנוהל עם שרת שמות נותן ללקוחות נתיב נקודה לנקודה, אבל רק ללקוחות שמוגדרים להשתמש בו. הצבת שרת במקום כלשהו ברשת אינה גורמת ליישום להיוועץ בו, ולקוח שנותר במצב שידור ימשיך לשאול את הקטע המקומי ויגיע לפסק זמן. כתובת השרת חייבת להגיע לתצורת הלקוח, דרך נתיב הניהול שהלקוח הזה מכבד.
לכן רשמו שלוש תצפיות עבור היישום הנדון: כיצד הוא הופך את שם השרת לכתובת, האם הגילוי או העברת ההודעות משתמשים בשידור או בנקודת קצה מכוונת, ואיזו כתובת ואיזו תעבורה משתמשת ההפעלה בפועל. אלה עובדות בלתי תלויות, ולכל אחת תיקון משלה. פתרון שם מוצלח אחד הוא ראיה רק לגבי הראשון.
NetBIOS מעל TCP/IP אינו NetBEUI
שני אלה מתבלבלים מפני ששניהם מכונים מיושנים. NetBIOS מעל TCP/IP נושא את שירותיו בתוך מנות IP, שמוסר נתיב מנותב כבר מעביר. NetBEUI הוא פרוטוקול שכבה 2 שאינו ניתן לניתוב, ומנהרת IP אינה מעבירה מסגרות Ethernet שרירותיות רק מפני שהיא מעבירה IP.
הוספת נתיב IP אינה יכולה להפוך מסגרת שאינה IP ליישום IP. אם יישום באמת תלוי בהתנהגות שכבה 2, האפשרויות הן שירות שכבה 2 תחום במפורש או החלפת היישום; אין שינוי ניתוב שמחליף את אחד מהם.
בחרו בשינוי הקטן ביותר שמספק את המשימה
שיתוף SMB קיים שאליו מגיעים דרך שם DNS מאושר ונתיב UNC מפורש אינו זקוק להרחבת Ethernet. משימת שירות הקבצים וחוויית הגלישה הן דרישות שונות, ורק השנייה תלויה ברשימת השכנים. הגעה לשיתוף לפי שם פותרת את המשימה בלי למתוח את תחום השידור דרך מנהרה.
הגלישה היא החלק שבדרך כלל נכשל, והוא נכשל בשקט. מכונה יכולה לפתוח שיתוף לפי נתיב בזמן שרשימת המחשבים הקרובים נשארת ריקה, מפני שהרשימה מתמלאת בגילוי שידור והנתיב משתמש ב-DNS. ההחלטה שדרושה לכם הרשימה היא דרישה אחרת מההחלטה שדרוש לכם הקובץ. רשמו מה המשתמש ביקש באמת לפני שאתם מתכננים משהו.
כשיישום מיושן באמת דורש שידור או מסגרות שאינן IP, בחנו שירות שכבה 2 תחום עם בעלים בשם, או החליפו את היישום. גשר מרחיב את תחום הכשל המשותף ואת גבול המדיניות, וזו החלטת ארכיטקטורה ולא תיבת סימון שכתוב עליה NetBIOS. תעדו את הפעולות המדויקות שהמנהרה צריכה לשאת, ומנהל יוכל להעריך את הבקשה במקום לנחש לגבי «כל רשת Windows».