HTTPS בקונטיינר מאחורי VPN ארגוני נתקע? בדקו את רגל ה-DTLS

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

שתי תעבורות, תסמין אחד מבלבל

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

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

החליטו בניסוי, לא באינטואיציה

הניסוי הזול ביותר מכבה את ערוץ הנתונים UDP וחוזר על הבקשה. השתמשו בלקוח שורת הפקודה ולא בעטיפת שולחן העבודה, כדי שהדגל יחול באמת: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. אם הבקשה שנתקעה מושלמת כעת, רגל ה-DTLS הייתה הבעיה והשאר היה רעש.

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

אם הדגל מתקן, החליטו למה

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

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

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

אם הגודל הוא הסיבה, ממשק המנהרה מקבל מנות שהנתיב לא יכול לשאת, והבעיה חוזרת בכל תעבורה ברגע שהמטענים גדלים. השוו את הממשקים: ip link show tun0 במארח, ואז docker network inspect bridge כדי לקרוא את ה-MTU הרשום באפשרויות הרשת. גשר קונטיינר שעדיין על 1500 בתים תחת מנהרה שנושאת פחות הוא הממצא הרגיל.

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

החליטו במה אתם מוכנים להחליף

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

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