Інтеграція корпоративного проксі-сервера в мобільний додаток

Чому мобільний додаток не бачить корпоративний проксі?

Багато клієнтів звертаються до нас з однією і тією ж проблемою: мобільний додаток перестає працювати всередині корпоративної мережі з примусовим HTTPS-проксі. Причина — додаток ігнорує системні налаштування проксі, встановлені через MDM-профіль (Intune, Jamf, MobileIron). Наш досвід показує, що коректна інтеграція з проксі — задача нетривіальна, особливо якщо проксі вимагає NTLM-аутентифікацію або виконує SSL Inspection. Давайте розберемо підводні камені на практичних прикладах.

Як мобільні ОС передають налаштування проксі

Android: системні налаштування проксі доступні через 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 з явно заданим configuration — не наслідують proxy. Для явного контролю: CFNetworkCopySystemProxySettings() (Core Foundation) або NEProxySettings через Network Extension API.

OkHttp справляється з проксі на Android автоматично через ProxySelector, а iOS — тільки при default configuration. Але на iOS PAC обробляється системою, що спрощує задачу. Зверніть увагу, що для проксі з аутентифікацією OkHttp вимагає явного налаштування Authenticator, аналогічно URLSession.

NTLM і Kerberos: корпоративна аутентифікація проксі

Найболючіший сценарій — проксі вимагає NTLM або Kerberos аутентифікацію (Integrated Windows Authentication). Стандартні HTTP-бібліотеки на iOS та Android не підтримують NTLM з коробки.

На Android: OkHttp + бібліотека ntlm-authentication або кастомний Authenticator з реалізацією NTLM handshake. NTLM — триетапний протокол: NEGOTIATE → CHALLENGE → AUTHENTICATE. Відповідь на challenge обчислюється на основі хешів NT-пароля, username та domain. Зберігати credentials в AccountManager — не в SharedPreferences.

На iOS: URLSession підтримує NTLM через URLAuthenticationChallenge з NSURLAuthenticationMethodNTLM. Потрібно реалізувати URLSessionTaskDelegate і повертати URLCredential з username/password. Domain — опціонально, але без нього деякі корпоративні проксі не приймають.

Kerberos (Negotiate) на мобілі — рідкість, але зустрічається у великих корпораціях з MS AD. На iOS: GSS-API (доступний через Heimdal). На Android — практично немає нормального рішення без NDK та MIT Kerberos.

Як налаштувати SSL Inspection без збоїв

Корпоративний HTTPS-проксі часто виступає Man-in-the-Middle — розшифровує TLS-трафік, перевіряє, перешифровує власним сертифікатом. Пристрій повинен довіряти корпоративному CA.

На пристроях з MDM корпоративний CA встановлюється автоматично через профіль. Для додатків, які реалізують Certificate Pinning — SSL Inspection ламає його. Потрібно або вимкнути pinning для внутрішніх ендпоінтів, або pinning на рівні MDM-сертифіката (перевіряти не leaf-сертифікат сервера, а ланцюжок до довіреного корпоративного CA).

На Android 7+ користувацькі CA-сертифікати не довіряються додаткам за замовчуванням. Для корпоративних додатків, які повинні довіряти MDM-встановленому CA: network_security_config.xml з <certificates src="system"/> і явним вказанням <certificates src="user"/> для development, тільки system для production MDM.

PAC-файли: коли проксі не один

Proxy Auto-Config (PAC) — JavaScript-функція FindProxyForURL(url, host), яка повертає проксі або DIRECT для кожного URL. Корпоративні мережі використовують PAC для маршрутизації: внутрішні ресурси — напряму, інтернет — через проксі.

На iOS: PAC обробляється системою, URLSession використовує результат прозоро. На Android: ProxyInfo.buildPacProxy(Uri) — MDM встановлює, але програмна обробка PAC-скриптів у додатку не тривіальна. Для кастомних HTTP-клієнтів (OkHttp) потрібно парсити та виконувати PAC самостійно — бібліотека pac4j-proxy або JavaScript через JavaScriptEngine.

Що входить в інтеграцію під ключ

1. Аудит інфраструктури — визначаємо тип проксі, MDM-рішення, метод аутентифікації, необхідність SSL Inspection.
2. Реалізація підтримки проксі — налаштування HTTP-клієнта (OkHttp/URLSession), реалізація аутентифікації (NTLM, Basic, Digest), обробка PAC, bypass SSL Inspection.
3. Тестування в корпоративному середовищі — перевіряємо на реальних пристроях з MDM-профілем, включаючи роумінг між Wi-Fi та мобільною мережею.
4. Документація та навчання — передаємо конфігураційні файли, code snippets, інструкції з налаштування проксі для ваших адміністраторів та розробників.

Чому варто замовити інтеграцію у нас

У нас 5+ років досвіду в інтеграції корпоративних проксі, виконано понад 20 проєктів для enterprise-клієнтів (банки, ритейл, логістика). Ми гарантуємо працездатність додатка у вашій мережі — якщо після нашого етапу залишаться проблеми, доведемо до ладу за свій рахунок. Середня економія витрат на підтримку становить до 500 000 рублів щорічно — за рахунок виключення збоїв при зміні проксі або оновленні MDM-політик.

Для більш глибокого розуміння протоколу NTLM можна звернутися до документації Microsoft. А для налаштування OkHttp під проксі — офіційний гайд OkHttp.

Готові оцінити ваш проєкт за 1–2 робочих дні — просто напишіть нам. Отримайте консультацію без зобов'язань. А якщо хочете дізнатися більше про типові підходи, зв'яжіться з нами — поділимося чек-листом з інтеграції проксі.