Захтеви апликације не пролазе кроз корпоративни 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 стекова чита прокси конфигурацију из оперативног система по default-у. Корпоративни VPN клијент често га инсталира као део свог профила приступа, па захтеви излазе кроз прокси који програмер никада није споменуо у коду. У .NET-у подразумевани handler вуче из IE/WinHTTP подешавања; Java чита -Dhttp.proxyHost; Node нема уграђену подршку за прокси док је библиотека не дода. Неуспех ретко је чисто одбијање, зато људи почињу да гледају сервер.

Тест кошта један захтев: искључите прокси изричито на једном handler-у и упоредите.

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

Ако то прође, поправка припада конфигурацији апликације, а не тунелу. Поновите ревизију за свако окружење извршавања у пројекту, јер свако чита другачији извор и само једно може бити покварено.

Порт који сте одабрали није порт који политика дозвољава

Рутиран хост није дозвољени сервис. Корпоративна политика обично дозвољава одлазне веб портове и одбацује остале, па је сервис на 8080 или 1883 недоступан док 443 ради добро. Прегледач овде ништа не доказује: он по дефиницији користи 443.

Објавите исти сервис иза 443 и дохватите га по имену пре него што затражите изузетак. Ако је изузетак заиста потребан, ограничите га на један распон извора и једну дестинацију и третирајте га као део дефиниције сервиса, а не као нечије лично заобилажење.

Сирови TCP који пут ресетује

Дуготрајне везе сировог TCP-а су слој који пада најзбуњујуће. Пут који дозвољава веб саобраћај ипак може да ресетује или препише неуобичајен одлазни TCP, а клијент пријави грешку сокета која се чита као прекид. Сервиси за поруке и догађаје обично испоручују WebSocket транспорт управо за такву мрежу, а пребацивање је опција клијента, а не промена тунела.

Промените транспорт, поново тестирајте и не мењајте ништа друго у истом пролазу. Тај тест с једном променљивом каже вам долази ли ресет с пута или из сервиса.

Веза које се затварају само на великим теретима

Захтев који прође и онда умре око секунду касније, али само када је тело велико, упућује на ограничење величине негде у средини. Посредник који броји бајтове порука може да испусти везу усред преноса, а клијент пријави абнормално затварање уместо истека времена.

Поделите терет на делове на нивоу апликације. Држите то одвојено од рада на MTU: смањење величине пакета тунела помаже када обичне TCP сесије застану на сталном броју бајтова, а не чини ништа за поруку коју посредник сматра превеликом.

Како разликовати четири у једном пролазу

Три запажања решавају већину случајева. Да ли се неуспех дешава одмах или само с великим телом? Да ли исти захтев пролази с искљученим проксијем? Да ли се исход мења када промените порт или транспорт? Запишите одговоре пре следеће промене, јер корпоративни VPN плус наслеђени прокси плус задата поставка апликације дају вам три вероватна узрока одједном.

Држите једну променљиву по тесту и забележите хост дестинације који сте користили. Без те основне линије следећа особа понавља сва четири корака од почетка.