שילוב פרוקסי ארגוני באפליקציות מובייל

מדוע אפליקציית הנייד שלך לא רואה את הפרוקסי הארגוני?

לקוחות רבים פונים אלינו עם אותה בעיה: אפליקציית הנייד מפסיקה לעבוד בתוך רשת ארגונית עם פרוקסי HTTPS כפוי. הסיבה היא שהאפליקציה מתעלמת מהגדרות הפרוקסי של המערכת שנקבעו דרך פרופיל MDM (Intune, Jamf, MobileIron). שילוב הפרוקסי המפתח שלנו עבור פרוקסי ארגוני באפליקציית נייד מכסה NTLM proxy iOS Android, עקיפת SSL Inspection, וקבצי PAC בנייד. אנו מטפלים גם בהגדרת OkHttp proxy והגדרת URLSession proxy ב-iOS, ומבטיחים שפרוקסי עם אימות באפליקציית נייד יעבוד עם כל הגדרות MDM. בצע אופטימיזציה לתעבורה הארגונית של אפליקציית הנייד שלך עם הפתרון שלנו ל-HTTPS proxy בנייד, כולל אימות Kerberos בנייד.

כיצד מערכות הפעלה ניידות מעבירות הגדרות פרוקסי

אנדרואיד: הגדרות הפרוקסי של המערכת נגישות דרך ConnectivityManager ו-LinkProperties. עבור HTTP/HTTPS — ProxyInfo עם שדות host ו-port. עבור PAC (Proxy Auto-Config) — כתובת ה-URL של הסקריפט. OkHttp קורא את הפרוקסי של המערכת אוטומטית כאשר משתמשים ב-OkHttpClient.Builder() ללא proxy() מפורש — אם לא דרסו אותו, הוא משתמש ב-ProxySelector.getDefault(). עם זאת, יש ניואנס: ProxySelector עובד עבור HTTP/HTTPS אבל לא עבור WebSocket (ws://, wss://). כאשר OkHttp משדרג חיבור HTTP ל-WebSocket, הוא משתמש במנהרת CONNECT, אבל Proxy-Authorization חייב להיות מועבר בנפרד דרך Authenticator.

iOS: URLSessionConfiguration.default קולט אוטומטית את הפרוקסי של המערכת מההגדרות. אבל תצורות מותאמות אישית (ephemeral) או URLSession עם תצורה שהוגדרה במפורש לא יורשות פרוקסי. לשליטה מפורשת: CFNetworkCopySystemProxySettings() (Core Foundation) או NEProxySettings דרך Network Extension API.

OkHttp מטפל בפרוקסי באנדרואיד אוטומטית דרך ProxySelector, בעוד iOS עושה זאת רק עם תצורת ברירת מחדל. עם זאת, ב-iOS PAC מטופל על ידי המערכת, מה שמפשט את המשימה. שים לב שעבור פרוקסי עם אימות, OkHttp דורש הגדרה מפורשת של Authenticator, בדומה ל-URLSession.

NTLM ו-Kerberos: אימות פרוקסי ארגוני

התרחיש הכואב ביותר הוא כאשר הפרוקסי דורש אימות NTLM או Kerberos (Integrated Windows Authentication). ספריות HTTP סטנדרטיות ב-iOS ובאנדרואיד לא תומכות ב-NTLM מחוץ לקופסה.

באנדרואיד: OkHttp + ספריית ntlm-authentication או Authenticator מותאם אישית המיישם את לחיצת היד של NTLM. NTLM הוא פרוטוקול תלת-שלבי: NEGOTIATE → CHALLENGE → AUTHENTICATE. תגובת האתגר מחושבת מהאשלי של סיסמת NT, שם משתמש ודומיין. אחסן אישורים ב-AccountManager — לא ב-SharedPreferences.

ב-iOS: URLSession תומך ב-NTLM דרך URLAuthenticationChallenge עם NSURLAuthenticationMethodNTLM. עליך ליישם URLSessionTaskDelegate ולהחזיר URLCredential עם שם משתמש/סיסמה. דומיין הוא אופציונלי, אבל חלק מהפרוקסי הארגוניים דוחים בקשות בלעדיו.

Kerberos (Negotiate) בנייד הוא נדיר אבל מופיע בחברות גדולות עם MS AD. ב-iOS: GSS-API (זמין דרך Heimdal). באנדרואיד — אין practically פתרון ראוי ללא NDK ו-MIT Kerberos.

כיצד להגדיר SSL Inspection ללא כשלים

פרוקסי HTTPS ארגוניים פועלים לעתים קרובות כ-Man-in-the-Middle — הם מפענחים תעבורת TLS, בודקים אותה, ומצפינים מחדש עם האישור שלהם. המכשיר חייב לסמוך על ה-CA הארגוני.

במכשירים המנוהלים על ידי MDM, ה-CA הארגוני מותקן אוטומטית דרך פרופיל. עבור אפליקציות שמיישמות Certificate Pinning — SSL Inspection שובר את זה. עליך או להשבית pinning עבור נקודות קצה פנימיות או להצמיד לאישור MDM (בדוק את השרשרת ל-CA הארגוני המהימן, לא לאישור העלה של השרת).

באנדרואיד 7+, אישורי CA המותקנים על ידי משתמש אינם מהימנים כברירת מחדל. עבור אפליקציות ארגוניות שחייבות לסמוך על ה-CA המותקן על ידי MDM: השתמש ב-network_security_config.xml עם וציין במפורש לפיתוח, אבל רק system לייצור MDM.

קבצי PAC: כאשר יש יותר מפרוקסי אחד

Proxy Auto-Config (PAC) הוא פונקציית JavaScript FindProxyForURL(url, host) שמחזירה פרוקסי או DIRECT עבור כל URL. רשתות ארגוניות משתמשות ב-PAC לניתוב: משאבים פנימיים — ישיר, אינטרנט — דרך פרוקסי.

ב-iOS: PAC מטופל על ידי המערכת; URLSession משתמש בתוצאה בשקיפות. באנדרואיד: ProxyInfo.buildPacProxy(Uri) — MDM מגדיר את זה, אבל טיפול פרוגרמטי בסקריפטים של PAC באפליקציה אינו טריוויאלי. עבור לקוחות HTTP מותאמים אישית (OkHttp), עליך לנתח ולהריץ PAC בעצמך — השתמש בספריית pac4j-proxy או JavaScript דרך JavaScriptEngine.

תוצרים

1. ביקורת תשתית — קבע סוג פרוקסי, פתרון MDM, שיטת אימות, צורך ב-SSL Inspection.
2. יישום תמיכת פרוקסי — הגדר לקוח HTTP (OkHttp/URLSession), יישם אימות (NTLM, Basic, Digest), טפל ב-PAC, עקוף SSL Inspection.
3. בדיקות בסביבה הארגונית — בדוק על מכשירים אמיתיים עם פרופיל MDM, כולל נדידה בין Wi-Fi לרשת סלולרית.
4. תיעוד והדרכה — ספק קבצי תצורה, קטעי קוד והוראות למנהלים ולמפתחים שלך.

למה להזמין אינטגרציה מאיתנו

יש לנו ניסיון של 5+ שנים באינטגרציית פרוקסי ארגוני, לאחר שהשלמנו מעל 25 פרויקטים ללקוחות ארגוניים (בנקים, קמעונאות, לוגיסטיקה). האינטגרציה שלנו מקצרת את זמן התמיכה בממוצע ב-40% — חוסכת עד $5,500 בשנה — ומפחיתה את זמן הפריסה ב-50% בהשוואה לפיתוח פנימי, שזה פי 2 מהר יותר. עבור אינטגרציית NTLM, הגישה שלנו אמינה פי 3 מפתרונות גנריים. אינטגרציה בסיסית מתחילה ב-$3,000, עם פרויקטים מורכבים בממוצע של $7,500. שילבנו עם 30+ פתרונות MDM שונים, ושיעור שביעות הרצון של הלקוחות שלנו הוא 98%. הביקורת עולה $1,000, יישום מ-$2,000, ובדיקות $1,500. אנו מבטיחים שהאפליקציה שלך עובדת ברשת שלך — אם נשארות בעיות אחרי השלב שלנו, אנו מתקנים אותן על חשבוננו.

להבנה מעמיקה יותר של פרוטוקול NTLM, עיין בתיעוד של Microsoft. להגדרת OkHttp עם פרוקסי, ראה את המדריך הרשמי של OkHttp.

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