שני קווי קישור אבל מנהרה אחת: מעבר, איזון או צירוף
מעבר בעת כשל, איזון לפי זרימה וצירוף של זרימה אחת הם שלושה הבטחות שונות. שני מסלולי ברירת מחדל נותנים לכם את הראשונה, ולא את השתיים האחרות.
שני קווי אינטרנט יכולים להפוך VPN לזמין יותר, ולהפוך אותו למהיר יותר עבור עומסי עבודה מסוימים, אבל המנגנון הוא שקובע מה משני הדברים יקרה. נתב עם שני מסלולי ברירת מחדל אינו מצורף, ומנהרה שנושאת אלפי חיבורים פנימיים היא עדיין זרימה חיצונית אחת. לתת שם להבטחה תחילה הוא ההבדל בין תכנון לאכזבה יקרה. הטבלה למטה מפרידה בין האפשרויות לפי מה שכל אחת דורשת בקצה המרוחק ומה אובדן קישור עושה להעברה.
שלוש הבטחות, ורק אחת זקוקה לשותף
מעבר בעת כשל שומר על מסלול זמין כשהקישור המועדף נעלם. איזון לפי גיבוב זרימות מפזר זרימות בלתי תלויות על שני קווי הקישור. צירוף של זרימה אחת מאפשר להעברה אחת להשתמש בשני הקישורים בו-זמנית. אלה מוצרים שונים עם דרישות שונות, ורק האחרון זקוק לשיתוף פעולה של משהו שמחוץ לנתב שלכם.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
שום דבר בטבלה הזו אינו סיבה לקנות קו שני. מה שהיא עושה הוא למנוע הערכה של תכנון מעבר כאילו היה צירוף.
למה מנהרה נראית לנתב כזרימה אחת
נתב שמאזן עומס מגבב כתובות מקור ויעד יחד עם פורטים, ואז שולח את כל הזרימה לאן שהגיבוב מצביע. מנהרת VPN היא זרימה כזו מנקודת המבט של הנתב, יהיה אשר יהיה מה שרץ בתוכה. חיבורים פנימיים לא מגיעים לעולם להחלטת הגיבוב, כי הכותרת החיצונית כבר קבעה את המסלול. לכן קו קישור שני יכול להכפיל את הקיבולת הכוללת עבור משתמשים רבים ולא לשנות דבר בהעברה גדולה של משתמש אחד.
שתי מנהרות נפרדות יכולות לתת לכם שני מועמדים, אבל הן עדיין זקוקות למדיניות מכוונת שמקצה תעבורה ומשאירה תשובות במסלול שנשא את הבקשה. ניתוב א-סימטרי הוא התוצאה הרגילה של דילוג על אותו שלב. המינימום הוא מדיניות שמציינת את הזרימה, את הקישור המועדף ואת קישור הגיבוי.
צירוף Ethernet אינו חוצה ספקים לא קשורים, כי הקצה המרוחק חייב להשתתף בפרוטוקול הצירוף. צירוף בין שני ספקי אינטרנט הוא פרויקט מחקר אלא אם קיים קצה משתף פעולה.
מה TCP רב-מסלולי דורש בשני הקצוות
התיעוד של Linux על Multipath TCP מתאר כמה תת-זרימות ששייכות לחיבור אחד. תמיכת ליבה בקצה אחד אינה משנה דבר בפני עצמה, כי גם העמית חייב לקבל את תת-הזרימות האלה. פרוקסי בצד המרוחק הוא הסידור הנפוץ האחר, והוא הופך לרכיב עם קיבולת וזמינות משלו שצריך לתכנן עבורן. אותה היגיון שולל תשובה קלה ל-WireGuard, שתעבורתו UDP: MPTCP מגדיל תת-זרימות TCP ואינו יכול לצרף את המנהרה הזו בלי משהו אחר בתכנון.
בדקו אם תכונת הליבה מופעלת לפני שמתכננים סביבה, כי הפצות רבות מספקות אותה כבויה. שלוש הפקודות האלה עונות על כך בדקה.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showבחרו לפי עומס העבודה, לא לפי החוברת
אם עומס העבודה הוא הפעלות רבות ובלתי תלויות, איזון לפי גיבוב זרימות יכול להוסיף קיבולת בלי שיתוף פעולה בקצה המרוחק. אם מדובר בהעברה גדולה אחת, רק תכנון צירוף יעזור, ותכנון כזה זקוק לעמית משתף פעולה. אם הדרישה היא שהעבודה תימשך כשקישור מת, התשובה היא מעבר בעת כשל ותפוקת העברה אחת אינה רלוונטית.
כתבו את הדרישה במשפט אחד שיש בו פועל: גיבוי אחד מסתיים מהר פי שניים, או שקישור שנפל אינו מסיים הפעלה. מטרות מעורפלות מייצרות תכנונים שאיש אינו יכול לקבל או לדחות. אחר כך החליטו מה הקצה המרוחק רשאי להיות, כי האפשרות הזולה ביותר היא לעתים קרובות זו שלא דורשת שם שום דבר חדש. האילוץ הזה מסלק את רוב הטענות של החוברת עוד לפני הפגישה הראשונה.
הפרידו את שלוש ההבטחות במסמך הדרישות. תכנון שטוען לשלושתן מספק בדרך כלל אחת ומניח בשקט את האחרות. החלק הבא בודק איזו מהן מסופקת באמת.
בדקו העברה אחת ורבות, ואז משכו קישור
השוו העברה מתמשכת אחת לכמה העברות מקבילות לאותו יעד, ורשמו אובדן, השהיה וניצולת לכל קישור. רווח רק בהפעלות מקבילות מצביע על פיזור זרימות, לא על צירוף של זרימה אחת. בדקו את אובדן קו הקישור האחד בנפרד, כי קיבולת כששני הקישורים עובדים אינה אומרת דבר על מעבר בעת כשל עבור הפעלה קיימת. תעדו את המסלול, את השקע ואת מוני השליחה החוזרת לפני כל בדיקה ואחריה.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5כשההעברה היחידה עדיין משתמשת בקו קישור אחד, התכנון עושה בדיוק את מה שגיבוב זרימות מרמז. כשההעברות המקבילות מתפזרות על שניהם, האיזון עובד והצירוף לא. תעדו איזו משלוש ההבטחות התכנון באמת מקיים, והשיחה הבאה על קיבולת תתחיל מראיות ולא מטענה של ספק.