TUN/TAP: ארגומנט לא חוקי — אי-התאמת מסגור ב-OpenVPN

הלקוח מאמת את עצמו, היומן אומר מחובר, ואף מנה לא חוצה את המנהרה. השרת מסיים את הניסיון עם write to TUN/TAP: Invalid argument (code=22), שנראה כמו תקלת מנהל התקן ובדרך כלל אינו כזה. בנתבים ובשרתי Linux קטנים, השורה הזו בדרך כלל אומרת ששני הצדדים לא מסכימים כיצד למסגר מנות נתונים, ולכן הליבה דוחה את החוצץ המפוענח שנמסר לה. הניתוב טרם נבדק בשלב הזה.

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

המנהרה עולה ושום דבר לא חוצה אותה

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

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

דחיסה היא מסגור, לא רוחב פס

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

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

יישרו את שני הקצוות או הסירו משניהם

מנו כל הנחיית דחיסה: קובץ השרת, כל אפשרות שנדחפה, קבצים ספציפיים ללקוח ופרופיל הלקוח. comp-lzo בשרת צריך את אותה מילה בלקוח, ו-adaptive הוא ברירת המחדל הישנה שהאפשרות החשופה בדרך כלל אומרת בגרסאות בנייה ישנות יותר. מתג ה-GUI של הנתב המסומן LZO או דחיסה כותב את אותה אפשרות, אז הגדירו אותו להתאמה במקום לערבב אלגוריתמים. אל תניחו ששם דומה חזותית תואם.

אם הדחיסה אינה רצויה, הסירו אותה בכוונה משני הקצוות. allow-compression no בשרת דוחה מנות דחוסות, אבל רק לאחר שהלקוחות הפסיקו להציע אותן; יישומו בזמן שלקוח עדיין דוחף דחיסה יוצר מחדש את אי-ההתאמה בכיוון השני.

בדקו את הדחיפה ואת סוג ההתקן

שרת יכול לדחוף הנחיית דחיסה מהקובץ הראשי שלו או מקובץ ספציפי ללקוח, ולקוח יכול להפיל אפשרויות שנדחפו עם pull-filter. חברו לקוח אחד ברמת פירוט 4, קראו מה השרת הכריז מול מה שהלקוח קיבל, ואז ודאו שאף מסנן לא הסיר אותו. אם שני הצדדים כעת מסכימים והשגיאה נמשכת, הסתכלו על סוג ההתקן: dev tap בקצה אחד ו-dev tun בקצה השני אינם יכולים להחליף מסגרות, והליבה דוחה את הכתיבה באותה דרך.

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

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