בקשות האפליקציה נכשלות מאחורי VPN ארגוני, אבל הדפדפן עובד

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

הביטו בבקשה שהאפליקציה באמת שולחת

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

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

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

האפליקציה ירשה פרוקסי שאיש לא הגדיר

רוב מחסניות ה-HTTP קוראות את הגדרות הפרוקסי ממערכת ההפעלה כברירת מחדל. לקוח VPN ארגוני מתקין לעיתים קרובות פרוקסי כחלק מפרופיל הגישה שלו, ולכן הבקשות יוצאות דרך פרוקסי שהמפתח מעולם לא הזכיר בקוד. ב-.NET המטפל המוגדר כברירת מחדל קורא מהגדרות IE/WinHTTP; ב-Java נקרא -Dhttp.proxyHost; ב-Node אין תמיכת פרוקסי מובנית עד שספרייה מוסיפה אותה. הכשל הוא לעיתים רחוקות סירוב נקי, ולכן אנשים מתחילים להסתכל על השרת.

הבדיקה עולה בקשה אחת: כבו את הפרוקסי במפורש במטפל אחד והשוו.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

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

הפורט שבחרתם אינו הפורט שהמדיניות מתירה

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

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

TCP גולמי שהנתיב מאפס

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

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

חיבורים שנסגרים רק במטענים גדולים

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

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

איך להבדיל בין הארבעה במעבר אחד

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

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