Git נתקע בלי ה-VPN? OpenSSH מסמן חבילות עם IPQoS

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

קראו את הסימפטום כהבדל בניתוב

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

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

הלקוח מטביע בייט QoS על כל שקע SSH

כל חיבור OpenSSH מ-7.8 ואילך נושא בכותרת ה-IP ערך שנתבים רשאים להשתמש בו כדי לתעדף תעבורה. הפעלות מסוף מקבלות ערך אחד והעתקות גדולות ערך אחר, מתוך התאוריה שאדם שמקליד ראוי ליחס טוב יותר מאשר העברת קובץ. רוב הרשתות מתעלמות לחלוטין מהרמז, ולכן הוא עובר בלי ששמים לב במשך שנים. מיעוט של מנהלי התקני Wi-Fi, ספקי סלולר ומרכזי VPN פועל לפיו, וחלק מהם פועל לרעה.

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

אמתו תחילה את גרסת הלקוח עם ssh -V. כל גרסה מ-7.8 ומעלה נושאת את ההתנהגות הזאת כברירת מחדל.

שלוש פקודות שמפרידות את זה מ-MTU ומ-DNS

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

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

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

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

שימו את החריגה בקובץ אחד, מארח אחד בכל פעם

חריגה שייכת לצד המארח שהיא חלה עליו, עם הערה שאומרת למה היא קיימת.

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

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

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

סגרו את המעגל עם בעל הרשת

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

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

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