Запити застосунку не проходять за корпоративним VPN, а браузер працює

Один застосунок падає, поки браузер завантажує сайт. Пройдіть по черзі успадкований проксі, політику портів, скидання сирого TCP і обмеження розміру корисного навантаження.

Ви відкриваєте внутрішній портал у браузері, і він завантажується. Ви запускаєте застосунок, який звертається до того самого хоста, і він падає з повідомленням, яке не називає жодного рівня. Тунель несе браузер, тому тунель не перший підозрюваний. Між вашим запитом і сервісом стоять чотири речі, і кожна залишає інший слід. Ось порядок, якого я дотримуюся: починаючи із запиту, який застосунок справді надсилає, а не зі сторінки налаштувань клієнта 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 плюс успадкований проксі плюс типове налаштування застосунку дають одразу три ймовірні причини.

Тримайте одну змінну на тест і записуйте використаний хост призначення. Без цієї базової лінії наступна людина повторює всі чотири кроки з початку.

Схожі статті