הורדות גדולות מול ה-VPN: בוחרים את המסלול בבקשה

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

למה נתב לא יכול למדוד תגובה

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

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

בדיקה 1: האם יש נקודת החלטה שיכולה לבחור מסלול?

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

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

בדיקה 2: מה המטא-נתונים באמת אומרים לכם?

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

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

בדיקה 3: האם הזרימה כבר קיימת?

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

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

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

בדיקה 4: האם הדרישה האמיתית היא השהיה, ולא יציאה?

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

tc qdisc replace dev eth0 root cake bandwidth 100mbit

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

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

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