Қолданба сұраулары корпоративтік 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, мұраға қалған прокси және қолданбаның әдепкі мәні бірге үш ықтимал себеп береді.

Әр сынақта бір айнымалы ұстап, пайдаланған межелік хостты жазып отырыңыз. Сол базалық сызықсыз келесі адам төрт қадамды да басынан қайталайды.

Қатысты мақалалар