שני LAN ב-NetBird: אילו עמיתים מנתבים ומי רשאי לדבר
רישום אינו מנתב LAN. בחרו עמית ניתוב אחד לכל אתר, השאירו את המיסוך, הגבילו את המדיניות, ואז למדו לכל שער LAN את הקפיצה הבאה.
עמדת עבודה ברשת ה-LAN המערבית פותחת דפדפן, מקלידה את הכתובת של יישום ברשת ה-LAN המזרחית וממתינה עד לפקיעת הזמן. כל מסך ב-NetBird אומר שהעמיתים מחוברים, וזה נכון ולא לעניין: להיות ברשת שכבה אחת אינו אותו דבר כמו להחזיק את שתי תת-הרשתות המקומיות ברשת אחת. המסלול שלהלן מתחיל בעמדת העבודה ההיא ומסתיים בבקשה שהתכנון דוחה בכוונה, וכל תחנה היא משהו שקוראים מהתקן ולא מנחשים. צפו שהחלק החסר יהיה מסלול או מדיניות, לא שכבת הרשת.
קראו קודם את הכשל מעמדת העבודה
לפני פתיחת מסוף הניהול, קבעו מה עמדת העבודה באמת שולחת. טבלת הניתוב שלה מחליטה אם החבילה הולכת לשער האתר, לממשק מקומי או לשום מקום, וההחלטה הזו גלויה בלי שום כלי שכבה. מכונה בלי מסלול לתחילית המרוחקת תיכשל, כמה שרישמת העמיתים תיראה בריאה. טווח שכבת הרשת והתחילית של האתר עצמו הם מרחבי כתובות שונים, והרישום הגדיר רק אחד מהם.
לאחר מכן הפרידו בין פתרון שמות לנגישות, כי הדפדפן מדווח על שניהם כאותה פקיעת זמן. חזרו על הבקשה לפי כתובת ממכונה שמריצה את לקוח NetBird, ואחר כך מעמדת עבודה רגילה שאינה מריצה אותו. אם המכונה הרשומה מצליחה והרגילה נכשלת, הפער הוא בניתוב המקומי; אם שתיהן נכשלות, המשיכו לקרוא לפני שתשנו מסלול.
בחרו עמית ניתוב אחד לכל אתר
עמית ניתוב הוא מארח שמייצג את ה-LAN שלו בשכבת הרשת, לכן בחרו מכונת Linux עם נגישות יציבה לתת-הרשת ולא עמדת העבודה שעל השולחן של מישהו. רשמו אותה בתהליך הרגיל והכניסו אותה לקבוצה הנקראת על שם התפקיד, כי משאב הרשת והמדיניות שניהם יפנו לאותה קבוצה. נציג אחד לכל אתר נשאר קריא; המון מתנדבים שמכריזים על אותה תחילית הופך כל שאלה מאוחרת לישיבת ניפוי תקלות. כתובתו של העמית בקטע המקומי חשובה כמו זהותו בשכבת הרשת, כי הכתובת הזו הופכת לקפיצה הבאה שאומרים לכל התקן רגיל.
כתבו את התוכנית לפני שנוגעים במסוף, כי שמות ותחיליות הם המקום שבו התכנונים האלה סוטים: תחילית, שער, כתובת עמית וקבוצה, לכל אתר. המערב הוא 10.52.0.0/24 שמשרת אותו 10.52.0.5 והמזרח הוא 10.63.0.0/24 שמשרת אותו 10.63.0.5; שתי הקבוצות הן west-routers ו-east-routers, ואף תחילית לא רשאית לחפוף לשנייה, לטווח שכבת הרשת או ליעד מנותב אחר.
צרו את המשאב, השאירו את המיסוך פועל
בלוח המחוונים הפרוס, צרו משאב רשת אחד לכל אתר וחברו אליו את קבוצת עמיתי הניתוב של אותו אתר. המשאב הוא התחילית והקבוצה היא המארח שעונה עליה, ושניהם חייבים להתקיים לפני שמכריזים על משהו. ודאו שלגרסה העצמאית הפרוסה יש בכלל את זרימת העבודה רשתות, כי ממשק ישן יותר עם אובייקט מסלול בשם דומה הוא תכונה אחרת.
השאירו את המיסוך מופעל. המדריך של NetBird לאתר-לאתר דורש אותו בסידור הזה, וכיבויו כדי שכל כתובת מקורית תישאר גלויה אינו אותו תכנון בקפיצה אחת פחות; הוא משנה מה בודקות בדיקות המקור והמדיניות של שכבת הרשת רואות. את התוצאה שווה לומר בפשטות: השירות המקבל רושם את עמית הניתוב כמקור, לא את עמדת העבודה הבודדת. אם רשימת ההיתרים או הביקורת של אותו שירות מצפה לכתובות עמדות עבודה, או שהציפייה משתנה או שהזהות חייבת להיאכף בגבול האתר לפני התרגום.
הסמיכו את היוזמים, לא את התחיליות
מסלול הופך כתובת לנגישה ומדיניות מחליטה מי רשאי להשתמש בה; אלה שני אובייקטים נפרדים עם בעלים נפרדים. כתבו את המדיניות מעומס העבודה לאחור: איזו קבוצה יוזמת, לאיזה משאב היא מכוונת ואיזה שירות TCP היא צריכה. רשת שמכריזה על שתי התחיליות לכל עמית רשום יצרה נגישות ולא הכריעה דבר.
אחר כך קראו מה כבר מותר, כי כלל חדש צר אינו מבטל כלל ישן רחב שיושב מעליו. כשגם המזרח צריך להתחיל חיבורים למערב, כתבו את הכיוון הזה כמדיניות משלו; תעבורת חזרה של הפעלה שהמערב פתח היא שאלה אחרת מלאפשר הפעלות חדשות מזרחה. אם רק עמדות עבודה מערביות מסוימות צריכות להגיע ליישום המזרחי, בחרו אותן בגבול האתר לפני התרגום והשאירו את האימות של היישום עצמו במקומו. עמית הניתוב נושא תעבורת LAN ככלל האתר ולא כזהות שכבה לכל משתמש, לכן חשבונאות לכל משתמש חייבת לבוא ממקום אחר.
למדו כל שער את הקפיצה הבאה, ואז בדקו סירוב
התקנים הרגילים לעולם אינם רואים את שכבת הרשת, לכן השער שלהם צריך מסלול סטטי שמפנה את התחילית המרוחקת לכתובת ה-LAN של עמית הניתוב. זה השלב שאנשים מדלגים עליו, כי כל מה שנראה בתוך NetBird כבר עובד בעוד עמדות עבודה רגילות עדיין פוקעות. השער שומר על מסלול ברירת המחדל כפי שהיה; התחילית הזו היא תוספת, לא החלפה.
שני תיאורי המסלול שייכים לתצורת השער של כל אתר, לא לדריסה במארח. שניהם מסלולים סטטיים רגילים, ואף אחד מהם לא נוגע במסלול ברירת המחדל:
west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5בדקו עם היישום שהפרויקט באמת צריך, מעמדת עבודה רגילה, ורשמו שלושה דברים: הקפיצה הבאה שנבחרה בצד השולח, המדיניות שהתאימה וכתובת המקור שהשירות רשם. בדקו גם סירוב, כי לתכנון שמעולם לא סירב לשום דבר יש קצוות לא ידועים, והסירוב הוא ההוכחה היחידה שהמדיניות ולא הניתוב עושה את העבודה. כשגם המזרח צריך ליזום, התחילו חיבור חדש מאותו צד במקום להניח שהכיוון השני עוקב. תכננו גם את הפעלה מחדש, השדרוג וההחלפה של עמית הניתוב, כי מארח אחד הפך לתלות של האתר.
| Test | A pass looks like | A failure points at |
|---|---|---|
| Ordinary workstation opens the east application | Next hop on west is the routing peer | Missing static route on the west gateway |
| A source outside policy is refused | No session in the service log | Policy too broad, or a route bypasses it |
| East starts a connection, if required | A fresh reverse session succeeds | No policy for the reverse direction |
שמות פרטיים צריכים תכנון פותר משלהם, כי נגישות אינה יוצרת רשומות DNS ונתיב IP עובד עם שם שבור נקרא בדיוק כמו נתיב שבור. אם עמית הניתוב רץ בתוך רשת ענן, עברו גם על כללי ההעברה והחומת אש של הספק, כי הרישום אינו עוקף אותם. שמרו את תצפיות הבדיקה ליד התוכנית, כי האדם הבא שינפה תקלות ירצה את המדיניות המתאימה ואת כתובת המקור שנרשמה, לא תיאור של הטופולוגיה.