קישור אלחוטי כגיבוי: מעבר מנותב או מקטע אחד?
החליטו אם הגיבוי מחזיר נגישות מנותבת או מאריך מקטע Ethernet אחד. הבחירה קובעת בקרת לולאות, בדיקות תקינות והתאוששות.
שני מבנים, רדיו מנקודה לנקודה ו-VPN באינטרנט שיכול לשמש נתיב שני. לפני שהגיבוי הופך אוטומטי, שאלה אחת מכריעה כמעט כל השאר: מה צריך לשרוד — נגישות IP בין תת-רשתות נפרדות או מקטע Ethernet משותף אחד? העובדה שהרדיו מתנהג כמו כבל אינה טיעון להעביר כל מסגרת שידור דרך האינטרנט. ענו קודם על השאלה, כי שתי התשובות דורשות בקרת לולאות אחרת, בדיקות תקינות אחרות ותפיסות שונות של משמעות ההתאוששות.
החליטו מה צריך לשרוד את התקלה
רשמו את היישומים שחייבים להמשיך לעבוד וציינו אם הם תלויים בנגישות ב-Layer 3 או בשכנות ב-Layer 2. שיתוף קבצים, חיבורים למסדי נתונים ושירותי ווב בדרך כלל מתעניינים רק בנתיבים; פרוטוקולי גילוי, חלק ממוצרי אשכולות וכל דבר שמצפה לתחום שידור אחד מתעניינים בשכנות. גיבוי שמחזיר את הסוג הלא נכון של נגישות יוצר אתר שמחובר טכנית וחסר תועלת למעשה.
רשמו את הרשימה הזו וצרפו אותה לתכנון, כי התשובה בדרך כלל זזה ברגע שבעל היישום הראשון שומע על הקישור החדש.
מעבר מנותב: שני קידומות, נתיב מועדף אחד
עם קידומות אתר נפרדות, הגיבוי הוא בעיית ניתוב. לכל נתב יש נתיב מועדף דרך הרדיו ונתיב פחות מועדף דרך המנהרה, והנתיב המועדף נסוג כאשר הרדיו מפסיק להעביר תנועה. הצד השני זקוק לנתיב חזרה משלו, ושני הצדדים צריכים להסכים איזה נתיב מועדף בכל כיוון כדי שהתנועה לא תיקח את הדרך הארוכה רק בכיוון אחד.
ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1
קראו גם את הפקודה השלישית ולא רק את השנייה: כלל מדיניות, טבלה שנייה או החלטה מבוססת מקור יכולים לשלוח תנועה מתת-רשת אחת אחרת מאחרת, וחיפוש ברירת מחדל אחד מסתיר זאת.
מעבר מגושר: מקטע אחד, נתיב חוסם אחד
אם השכנות באמת נדרשת, הגיבוי חייב לשאת מסגרות Ethernet, דבר שמנהרת IP מנותבת אינה עושה. גישור ממשק VPN לתוך מקטע מקומי נתמך בחלק מהפלטפורמות, והממשקים האלה הופכים אז לחברי גשר עם ההשלכות הנלוות. שני נתיבי Layer 2 שמעבירים בו-זמנית יוצרים לולאה, ולכן התכנון זקוק לעץ פורש שמכסה את שני האתרים ולהצהרה ברורה איזה נתיב צריך לחסום.
זו החלטת תכנון מהותית ולא תיבת סימון, ותיעוד הגישור של הפלטפורמה שלכם, כמו סקירת הגישור עבור pfSense, הוא המקום לאשר במה חבר VPN באמת משתתף. הפעלת אפשרות עץ פורש במכשיר אחד לא קשור לא מוכיחה דבר על הסידור מקצה לקצה.
נטרו את הגבול שחשוב
רדיו עם מתח, ממשק במצב פעיל ומנהרה בריאה מתארים כל אחד עובדה מקומית. אף אחד מהם לא מוכיח שחבילה מבניין אחד הגיעה למארח בשני, וזו העובדה היחידה שעל לוגיקת המעבר לפעול לפיה. נטרו יעד מעבר לנתב המרוחק אם המדיניות מאפשרת, ונטרו את שני הכיוונים בנפרד כדי שכשל א-סימטרי יהיה גלוי.
ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10
שמרו על הבדיקה זולה ומוגבלת: מרווח קצר, ספירה קטנה וזמן קצוב שמתאים לסבילות היישום. מוניטור שתלוי בעצמו בנתיב שהוא בודק ידווח על הצלחה עד הרגע שבו יפסיק לדווח על משהו.
תרגלו את שני הכיוונים תחת עומס
אל תעתיקו יעד התכנסות אחד מהטופולוגיה של מישהו אחר. זמן הגילוי, התכנסות הנתיב או הגשר, מוכנות המנהרה והתאוששות היישום מוסיפים כל אחד את העיכוב שלו, והסכום בציוד שלכם הוא המספר היחיד שחשוב. תרגלו בזמן שתנועה מייצגת זורמת, כדי שהמדידה תכלול את התורים וההפעלות שקיימים בייצור.
sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10
בדקו התאוששות בקפידה כמו תקלה. רדיו לא יציב שמהבהב פנימה והחוצה יגרור תנועה הלוך ושוב אם להיגיון ההעדפה אין ריסון, ומשתמשים חווים זאת כגרוע מהפסקה נקייה אחת. תעדו את הנתיב הנבחר בכל שלב, אילו בקשות חדשות הצליחו ומה קרה להפעלות שהיו פתוחות כשהנתיב השתנה. התיעוד הזה הוא מה שהופך כבל שני למדיניות תפעולית.