Заявките на приложението се провалят зад корпоративен 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 плюс наследено прокси плюс настройка по подразбиране ви дават три вероятни причини наведнъж.

Дръжте една променлива на тест и записвайте хоста на дестинацията, който сте използвали. Без тази базова линия следващият човек повтаря четирите стъпки отначало.

Подобни статии