Kërkesat e aplikacionit dështojnë pas një VPN korporative, por shfletuesi funksionon

Hap portalin e brendshëm në një shfletues dhe ai ngarkohet. Ekzekuton aplikacionin që thërret të njëjtin host dhe ai dështon, me një mesazh që nuk emërton asnjë shtresë. Tuneli mbart shfletuesin, prandaj tuneli nuk është i dyshuari i parë. Midis kërkesës tënde dhe shërbimit qëndrojnë katër gjëra, dhe secila lë një gjurmë tjetër. Ky është rendi që ndjek, duke nisur nga kërkesa që aplikacioni dërgon vërtet, dhe jo nga faqja e cilësimeve të klientit VPN.

Shiko kërkesën që aplikacioni dërgon vërtet

Përpara se të prekësh konfigurimin, lëre aplikacionin të thotë çfarë bën. Një kapje e një kërkese të vetme me proxy-n të çaktivizuar shprehimisht dhe një test i thjeshtë porte të japin dy vija bazë me të cilat krahasohen hapat e mëpasshëm. Nëse kërkesa kalon me proxy të fikur, ke përfunduar tashmë tre nga katër shtresat.

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

Ekzekuto dy të fundit drejt të njëjtit destinacion dhe shiko ku ndahen. Një shfletues që funksionon plus një curl që funksionon plus një aplikacion që nuk funksionon e ngushtojnë problemin në diçka që aplikacioni shton: një proxy, një transport ose një madhësi mesazhi.

Aplikacioni trashëgoi një proxy që askush nuk e konfiguroi

Shumica e stivave HTTP lexojnë konfigurimin e proxy-t nga sistemi operativ si parazgjedhje. Një klient VPN korporativ shpesh instalon një të tillë si pjesë të profilit të tij të aksesit, kështu që kërkesat dalin përmes një proxy që zhvilluesi nuk e përmendi kurrë në kod. Në .NET trajtuesi i parazgjedhur lexon cilësimet e IE/WinHTTP; Java lexon -Dhttp.proxyHost; Node nuk ka mbështetje proxy të integruar derisa një bibliotekë ta shtojë. Dështimi rrallë është refuzim i pastër, prandaj njerëzit fillojnë të shikojnë serverin.

Testi kushton një kërkesë: çaktivizo proxy-n shprehimisht në një trajtues dhe krahaso.

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

Nëse kjo funksionon, rregullimi i përket konfigurimit të aplikacionit, jo tunelit. Përsërit auditimin për çdo mjedis ekzekutimi në projekt, sepse secili lexon një burim tjetër dhe ndoshta vetëm njëri është i prishur.

Porta që zgjodhe nuk është porta që lejon politika

Një host i rrugëtuar nuk është shërbim i lejuar. Politika korporative zakonisht lejon portat e web-it në dalje dhe hedh poshtë të tjerat, kështu që një shërbim në 8080 ose 1883 është i paarritshëm ndërsa 443 funksionon mirë. Shfletuesi nuk provon asgjë këtu: përdor 443 sipas përkufizimit.

Publiko të njëjtin shërbim pas 443 dhe arrije me emër përpara se të kërkosh një përjashtim. Nëse përjashtimi është vërtet i nevojshëm, kufizoje në një interval burimi dhe një destinacion dhe trajtoje si pjesë e përkufizimit të shërbimit, jo si zgjidhja personale e dikujt.

TCP i papërpunuar që rruga e rivendos

Lidhjet e TCP të papërpunuar me jetë të gjatë janë shtresa që dështon në mënyrën më konfuze. Një rrugë që lejon trafikun e web-it prapëseprapë mund të rivendosë ose rishkruajë TCP në dalje të pazakontë, dhe klienti raporton një gabim soketi që lexohet si ndërprerje. Shërbimet e mesazheve dhe ngjarjeve zakonisht ofrojnë transport WebSocket pikërisht për një rrjet të tillë, dhe kalimi është opsion i klientit, jo ndryshim i tunelit.

Ndrysho transportin, testo përsëri dhe mos ndrysho asgjë tjetër në të njëjtin ekzekutim. Ai test me një ndryshore të thotë nëse rivendosja erdhi nga rruga apo nga shërbimi.

Lidhje që mbyllen vetëm me ngarkesa të mëdha

Një kërkesë që kalon dhe pastaj vdes rreth një sekondë më vonë, por vetëm kur trupi është i madh, tregon një kufi madhësie diku në mes. Një ndërmjetës që numëron bajtët e mesazheve mund ta lëshojë lidhjen në mes të transferimit, dhe klienti raporton mbyllje anormale në vend të një afati kohor.

Ndaj ngarkesën në copa në shtresën e aplikacionit. Mbaje këtë të ndarë nga puna me MTU: ulja e madhësisë së paketës së tunelit ndihmon kur sesionet normale TCP ngecin në një numër konstant bajtësh, dhe nuk bën asgjë për një mesazh që një ndërmjetës e konsideron shumë të madh.

Si t'i dallosh të katërt në një kalim

Tre vëzhgime zgjidhin shumicën e rasteve. A ndodh dështimi menjëherë apo vetëm me trup të madh? A kalon e njëjta kërkesë me proxy të çaktivizuar? A ndryshon rezultati kur ndryshon portën ose transportin? Shkruaj përgjigjet përpara ndryshimit të radhës, sepse një VPN korporative plus një proxy i trashëguar plus një vlerë e parazgjedhur e aplikacionit të japin tre shkaqe të besueshme njëherësh.

Mbaj një ndryshore për test dhe shëno hostin e destinacionit që përdore. Pa atë vijë bazë, personi tjetër përsërit të katër hapat nga fillimi.