סיכום ערוץ אינטרנט אמיתי - OpenMPTCPRouter

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

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

מיתוסים על סיכום ערוץ

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

איזון ברמת חיבור IP

זוהי הדרך המשתלמת והפופולרית ביותר להשתמש במספר ערוצי אינטרנט בו זמנית. לשם הפשטות, בואו נדמיין שיש לכם שלושה ספקי אינטרנט, כל אחד נותן לכם כתובת IP אמיתית מהרשת שלו. כל הספקים הללו מחוברים לנתב התומך בפונקציית Multi-WAN. זה יכול להיות OpenWRT עם חבילת mwan3, mikrotik, ubiquiti או כל נתב ביתי אחר, מכיוון שאופציה כזו כבר אינה נדירה.

כדי לדמות את המצב, בואו נדמיין שהספקים נתנו לנו את הכתובות הבאות:

WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33

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

בעת איזון ברמת החיבור, כל חיבור TCP עובר דרך ספק נפרד.

מצב איזון זה גורם לעתים קרובות לבעיות עבור המשתמשים. לדוגמה, אתרים רבים קושרים קובצי Cookie ואסימונים לכתובת ה-IP של הלקוח, ואם היא משתנה לפתע, הבקשה נדחית או שהלקוח מנותק מהאתר. זה משוכפל לעתים קרובות במערכות לקוח-בנק ובאתרים אחרים עם כללי הפעלה נוקשים של משתמשים. הנה דוגמה להמחשה פשוטה: קבצי מוזיקה ב-VK.com זמינים רק עם מפתח הפעלה חוקי, שקשור ל-IP, ולקוחות המשתמשים באיזון כזה לרוב לא משמיעים אודיו מכיוון שהבקשה לא עברה דרך הספק שאליו הפגישה קשורה.

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

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

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

חיבור אחד תמיד ישתמש רק בערוץ אינטרנט אחד

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

סיכום ערוץ אמיתי

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

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

שרת הסיכום מקבץ את כל הערוצים למנהרה אחת. כל החיבורים מקורם מכתובת השרת המסכמת

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

פתרונות מסחריים

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

נתב לשידורי וידאו עם פונקציית סיכום ערוצים

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

לפעמים זה נראה די מפחיד:

הגדרת OpenMPTCPRouter

פרוטוקול MP-TCP (MultiPath TCP) הומצא כדי להיות מסוגל להתחבר באמצעות מספר ערוצים בו זמנית. למשל שלו תומך ב-iOS ויכול להתחבר בו זמנית לשרת מרוחק באמצעות WiFi ודרך רשת סלולרית. חשוב להבין שלא מדובר בשני חיבורי TCP נפרדים, אלא בחיבור אחד שנוצר על פני שני ערוצים בבת אחת. כדי שזה יעבוד, השרת המרוחק חייב לתמוך גם ב-MPTCP.

OpenMPTCPRouter הוא פרויקט נתב תוכנת קוד פתוח המאפשר סיכום ערוצים אמיתי. המחברים מצהירים שהפרויקט נמצא בסטטוס גרסת אלפא, אך ניתן כבר להשתמש בו. הוא מורכב משני חלקים - שרת סיכום, שנמצא באינטרנט ונתב, אליו מחוברים מספר ספקי אינטרנט ומכשירי הלקוח עצמם: מחשבים, טלפונים. הנתב המותאם אישית יכול להיות Raspberry Pi, כמה נתבי WiFi או מחשב רגיל. יש מכלולים מוכנים לפלטפורמות שונות, וזה מאוד נוח.

כיצד פועל OpenMPTCPRouter

הקמת שרת סיכום

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

עבור משימה זו נשתמש בשרת VPS ב Debian 10.

דרישות לשרת המסכם:

• MPTCP לא עובד על וירטואליזציה של OpenVZ
• אמור להיות אפשרי להתקין את הקרנל שלך Linux

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

wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh

התוצאה של התקנת שרת מוצלחת.

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

uname -a 
Linux test-server.local 4.19.67-mptcp

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

הגדרת נתב לקוח

על אתר הפרויקט בנייה מוכנה זמינה עבור פלטפורמות מסוימות, כגון Raspberry Pi, Banana Pi, נתבים Lynksys ומכונות וירטואליות.
חלק זה של openmptcprouter מבוסס על OpenWRT, תוך שימוש ב-LuCI כממשק, המוכר לכל מי שאי פעם נתקל ב-OpenWRT. ההפצה שוקלת כ-50MB!

כספסל מבחן, אשתמש ב-Raspberry Pi ובמספר מודמי USB עם מפעילים שונים: MTS ו-Megafon. אני לא חושב שאני צריך להגיד לך איך לכתוב תמונה לכרטיס SD.

בתחילה, יציאת ה-Ethernet ב-Raspberry Pi מוגדרת כ-LAN עם כתובת IP סטטית 192.168.100.1. כדי להימנע מהתעסקות עם חוטים על השולחן, חיברתי את ה-Raspberry Pi לנקודת גישה ל-WiFi והגדרתי את מתאם ה-WiFi של המחשב לכתובת סטטית 192.168.100.2. שרת ה-DHCP אינו מופעל כברירת מחדל, לכן עליך להשתמש בכתובות סטטיות.

עכשיו אתה יכול להיכנס לממשק האינטרנט 192.168.100.1

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

בהגדרות ה-LAN, תוכל להגדיר את רשת המשנה הרצויה ולהפעיל את שרת ה-DHCP.

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

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

כדי למנוע בלבול עם שמות ממשקים, אני ממליץ לצפות בהודעות dmesg תוך כדי התחברות דרך SSH.

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

OpenMPTCPRouter דורש שכתובות ממשק ה-WAN יהיו סטטיות, לכן אנו מגיעים עם רשתות משנה עבור המודמים ומגדירים אותן במערכת → openmptcprouter → תפריט הגדרות הממשק. כאן עליך לציין את כתובת ה-IP ומפתח השרת שהתקבלו במהלך התקנת שרת המסכם.

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

מצב ברירת המחדל הוא shadowsocks + mptcp. זהו פרוקסי שעוטף את כל החיבורים בתוך עצמו. תחילה הוא מוגדר לעיבוד TCP בלבד, אך ניתן להפעיל גם UDP.

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

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

מסקנה

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

עקבו אחר המפתח שלנו באינסטגרם

מקור: www.habr.com