Programos užklausos nepraeina už įmonės VPN, o naršyklė veikia

Atidarote vidinį portalą naršyklėje ir jis įkeliamas. Paleidžiate programą, kuri kreipiasi į tą patį mazgą, ir ji nepavyksta, su pranešimu, kuriame neįvardytas nė vienas sluoksnis. Tunelis gabena naršyklę, todėl tunelis nėra pirmasis įtariamasis. Tarp jūsų užklausos ir paslaugos stovi keturi dalykai, ir kiekvienas palieka kitokį pėdsaką. Štai tvarka, kurios laikausi: pradedant nuo užklausos, kurią programa iš tikrųjų siunčia, o ne nuo VPN kliento nustatymų puslapio.

Pažiūrėkite į užklausą, kurią programa iš tikrųjų siunčia

Prieš liedami konfigūraciją, leiskite programai pasakyti, ką ji daro. Vienos užklausos fiksavimas su aiškiai išjungtu tarpiniu serveriu ir paprastas prievado testas duoda dvi bazines linijas, su kuriomis lyginami tolesni žingsniai. Jei užklausa pavyksta išjungus tarpinį serverį, trys iš keturių sluoksnių jau sutvarkyti.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Paleiskite paskutinius du į tą patį tikslą ir stebėkite, kur jie išsiskiria. Veikianti naršyklė plius veikiantis curl plius neveikianti programa susiaurina problemą iki to, ką programa prideda: tarpinio serverio, transporto ar pranešimo dydžio.

Programa paveldėjo tarpinį serverį, kurio niekas nesukonfigūravo

Dauguma HTTP rinkinių tarpinio serverio konfigūraciją pagal nutylėjimą skaito iš operacinės sistemos. Įmonės VPN klientas dažnai įdiegia vieną kaip savo prieigos profilio dalį, todėl užklausos išeina per tarpinį serverį, kurio kūrėjas kode niekada nepaminėjo. .NET numatytasis apdorotuvas ima IE/WinHTTP nustatymus; Java skaito -Dhttp.proxyHost; Node neturi įtaisyto tarpinio serverio palaikymo, kol biblioteka jo neprideda. Nesėkmė retai būna švarus atmetimas, todėl žmonės pradeda žiūrėti į serverį.

Testas kainuoja vieną užklausą: viename apdorotuve aiškiai išjunkite tarpinį serverį ir palyginkite.

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

Jei tai pavyksta, pataisymas priklauso programos konfigūracijai, o ne tuneliui. Pakartokite auditą kiekvienai projekto vykdymo aplinkai, nes kiekviena skaito kitą šaltinį ir tik viena gali būti sugedusi.

Prievadas, kurį pasirinkote, nėra prievadas, kurį leidžia politika

Maršrutizuotas mazgas nėra leidžiama paslauga. Įmonės politika paprastai leidžia išeinančius žiniatinklio prievadus, o kitus išmeta, todėl paslauga 8080 arba 1883 prievade yra nepasiekiama, o 443 veikia gerai. Naršyklė čia nieko neįrodo: ji pagal apibrėžimą naudoja 443.

Paskelbkite tą pačią paslaugą už 443 ir pasiekite ją vardu prieš prašydami išimties. Jei išimtis tikrai reikalinga, apribokite ją vienu šaltinio diapazonu ir vienu tikslu ir traktuokite kaip paslaugos apibrėžimo dalį, o ne kaip kažkieno asmeninį apėjimą.

Neapdorotas TCP, kurį kelias atstato

Ilgai gyvuojantys neapdoroto TCP ryšiai yra sluoksnis, kuris nepavyksta labiausiai gluminančiai. Kelias, leidžiantis žiniatinklio srautą, vis tiek gali atstatyti arba perrašyti neįprastą išeinantį TCP, o klientas praneša apie lizdo klaidą, kuri skaitoma kaip sutrikimas. Pranešimų ir įvykių paslaugos paprastai teikia WebSocket transportą būtent tokiam tinklui, o perjungimas yra kliento pasirinkimas, o ne tunelio pakeitimas.

Pakeiskite transportą, dar kartą išbandykite ir tame pačiame paleidime nieko kito nekeiskite. Tas vieno kintamojo testas pasako, ar atstatymas atėjo iš kelio, ar iš paslaugos.

Ryšiai, kurie užsidaro tik esant didelėms apkrovoms

Užklausa, kuri pavyksta ir po maždaug sekundės miršta, bet tik kai turinys didelis, rodo į dydžio ribą kažkur viduryje. Tarpininkas, kuris skaičiuoja pranešimų baitus, gali numesti ryšį perdavimo viduryje, o klientas praneša apie nenormalų uždarymą vietoj laiko limito.

Suskaidykite apkrovą programos lygmenyje. Laikykite tai atskirai nuo MTU darbo: tunelio paketo dydžio sumažinimas padeda, kai įprastos TCP sesijos sustoja ties pastoviu baitų skaičiumi, ir nieko nepadaro pranešimui, kurį tarpininkas laiko per dideliu.

Kaip atskirti keturis vienu ėjimu

Trys stebėjimai išsprendžia daugumą atvejų. Ar nesėkmė įvyksta iš karto, ar tik su dideliu turiniu? Ar ta pati užklausa pavyksta išjungus tarpinį serverį? Ar rezultatas keičiasi pakeitus prievadą ar transportą? Užsirašykite atsakymus prieš kitą pakeitimą, nes įmonės VPN plius paveldėtas tarpinis serveris plius programos numatytoji reikšmė duoda tris tikėtinas priežastis iš karto.

Laikykite vieną kintamąjį vienam testui ir užsirašykite naudotą tikslo mazgą. Be tos bazinės linijos kitas žmogus kartoja visus keturis žingsnius nuo pradžių.