Nabibigo ang mga kahilingan ng app sa likod ng corporate VPN, pero gumagana ang browser

Binubuksan mo ang panloob na portal sa browser at naglo-load ito. Pinapatakbo mo ang app na tumatawag sa parehong host at nabibigo ito, may mensaheng hindi nagpapangalan ng anumang layer. Dinadala ng tunnel ang browser, kaya hindi ang tunnel ang unang pinaghihinalaan. May apat na bagay sa pagitan ng kahilingan mo at ng serbisyo, at bawat isa ay nag-iiwan ng ibang bakas. Ito ang pagkakasunod-sunod na sinusundan ko, simula sa kahilingang talagang ipinapadala ng app, hindi sa pahina ng settings ng VPN client.

Tingnan ang kahilingang talagang ipinapadala ng app

Bago hawakan ang configuration, hayaang sabihin ng app kung ano ang ginagawa nito. Ang paghuli ng isang kahilingan na hayagang naka-off ang proxy at isang simpleng pagsubok sa port ay nagbibigay sa iyo ng dalawang baseline na paghahambingan ng mga susunod na hakbang. Kung nagtagumpay ang kahilingan habang patay ang proxy, tapos ka na sa tatlo sa apat na layer.

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

Patakbuhin ang huling dalawa sa parehong destinasyon at tingnan kung saan sila nagkakaiba. Isang gumaganang browser at isang gumaganang curl at isang app na hindi gumagana — pinapaliit nito ang problema sa isang bagay na idinadagdag ng app: isang proxy, isang transport o isang laki ng mensahe.

Nagmana ang app ng proxy na walang nag-configure

Karamihan sa mga HTTP stack ay nagbabasa ng proxy configuration mula sa operating system bilang default. Madalas na nag-i-install ang corporate VPN client ng isa bilang bahagi ng profile ng access nito, kaya lumalabas ang mga kahilingan sa isang proxy na hindi binanggit ng developer sa code. Sa .NET, ang default handler ay kumukuha mula sa mga setting ng IE/WinHTTP; nagbabasa ang Java ng -Dhttp.proxyHost; walang built-in na proxy support ang Node hanggang may library na magdagdag. Bihirang maging malinis na pagtanggi ang kabiguan, kaya nagsisimulang tingnan ng mga tao ang server.

Isang kahilingan ang halaga ng pagsubok: hayagang patayin ang proxy sa isang handler at ihambing.

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

Kung nagtagumpay iyon, ang pagwawasto ay kabilang sa configuration ng app, hindi sa tunnel. Ulitin ang audit para sa bawat runtime sa proyekto, dahil bawat isa ay nagbabasa ng ibang pinagmulan at maaaring isa lang ang sira.

Ang port na pinili mo ay hindi ang port na pinapayagan ng patakaran

Ang naka-route na host ay hindi isang pinapayagang serbisyo. Karaniwang pinapayagan ng patakaran ng kumpanya ang mga palabas na web port at itinatapon ang iba, kaya hindi maabot ang serbisyo sa 8080 o 1883 habang maayos na gumagana ang 443. Walang pinapatunayan ang browser dito: gumagamit ito ng 443 ayon sa kahulugan.

Ilathala ang parehong serbisyo sa likod ng 443 at maabot ito sa pangalan bago humingi ng eksepsiyon. Kung talagang kailangan ang eksepsiyon, limitahan ito sa isang saklaw ng pinagmulan at isang destinasyon at ituring itong bahagi ng depinisyon ng serbisyo, hindi bilang personal na paraan ng iba.

Hilaw na TCP na nire-reset ng landas

Ang pangmatagalang hilaw na koneksyon ng TCP ang layer na pinakalito ang kabiguan. Ang landas na pumapayag sa web traffic ay maaari pa ring mag-reset o magsulat muli ng kakaibang palabas na TCP, at nag-uulat ang client ng error sa socket na parang pagkaantala. Karaniwang may transport na WebSocket ang mga serbisyo ng mensahe at event para sa ganitong uri ng network, at ang paglipat ay opsiyon ng client, hindi pagbabago sa tunnel.

Palitan ang transport, subukan muli at huwag baguhin ang iba sa parehong pagtakbo. Ang pagsubok na may isang variable ang magsasabi kung galing sa landas o sa serbisyo ang reset.

Mga koneksyong nagsasara lamang sa malalaking payload

Ang kahilingang nagtagumpay at namatay pagkalipas ng mga isang segundo, pero kapag malaki lang ang katawan, ay tumuturo sa limitasyon sa laki sa gitna. Ang intermediary na nagbibilang ng bytes ng mensahe ay maaaring magpabagsak ng koneksyon sa gitna ng paglilipat, at nag-uulat ang client ng abnormal na pagsasara sa halip na timeout.

Hatiin ang payload sa antas ng aplikasyon. Ihiwalay ito sa gawain sa MTU: nakakatulong ang pagbaba ng laki ng packet ng tunnel kapag ang ordinaryong sesyon ng TCP ay tumitigil sa palagiang bilang ng bytes, at wala itong ginagawa para sa mensaheng itinuturing na masyadong malaki ng intermediary.

Paano makilala ang apat sa isang pagdaan

Tatlong obserbasyon ang nagtatakda ng karamihan ng kaso. Agaran bang nangyayari ang kabiguan o kapag malaki lang ang katawan? Nagtagumpay ba ang parehong kahilingan habang patay ang proxy? Nagbabago ba ang resulta kapag pinalitan mo ang port o transport? Isulat ang mga sagot bago ang susunod na pagbabago, dahil ang corporate VPN at minanang proxy at default ng app ay nagbibigay ng tatlong malamang dahilan nang sabay.

Panatilihin ang isang variable kada pagsubok at itala ang destinasyong host na ginamit mo. Kung wala ang baseline na iyon, inuulit ng susunod na tao ang apat na hakbang mula sa simula.