Maombi ya programu yanashindikana nyuma ya VPN ya kampuni, lakini kivinjari kinafanya kazi

Unafungua lango la ndani kwenye kivinjari na linapakia. Unaendesha programu inayoiita mwenyeji huyo huyo na inashindikana, kwa ujumbe ambao hautaji tabaka lolote. Handaki linabeba kivinjari, kwa hiyo handaki si mshukiwa wa kwanza. Kuna vitu vinne kati ya ombi lako na huduma, na kila kimoja kinaacha alama tofauti. Huu ndio mpangilio ninaofuata, nikianza na ombi ambalo programu hutuma kweli, na si ukurasa wa mipangilio wa mteja wa VPN.

Tazama ombi ambalo programu hutuma kweli

Kabla ya kugusa usanidi, acha programu ikwambie inafanya nini. Kunasa ombi moja huku proksi imezimwa waziwazi pamoja na jaribio rahisi la bandari kunakupa mistari miwili ya msingi ambayo hatua zinazofuata hulinganishwa nayo. Ikiwa ombi linafanikiwa proksi ikiwa imezimwa, tayari umemaliza tabaka tatu kati ya nne.

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

Endesha mbili za mwisho kuelekea lengo lilo hilo na uangalie zinapotofautiana. Kivinjari kinachofanya kazi pamoja na curl inayofanya kazi pamoja na programu isiyofanya kazi hupunguza tatizo hadi kitu ambacho programu inaongeza: proksi, usafirishaji au ukubwa wa ujumbe.

Programu ilirithi proksi ambayo hakuna aliyesanidi

Nyingi za mikusanyiko ya HTTP husoma usanidi wa proksi kutoka mfumo wa uendeshaji kwa chaguo-msingi. Mteja wa VPN wa kampuni mara nyingi husakinisha moja kama sehemu ya wasifu wake wa ufikiaji, kwa hiyo maombi hutoka kupitia proksi ambayo msanidi hakuwahi kuitaja kwenye msimbo. Katika .NET kishikizi cha chaguo-msingi huchukua mipangilio ya IE/WinHTTP; Java husoma -Dhttp.proxyHost; Node haina msaada wa proksi uliojengwa ndani hadi maktaba iongeze. Kushindikana mara chache ni kukataa safi, ndiyo sababu watu huanza kuangalia seva.

Jaribio linagharimu ombi moja: zima proksi waziwazi kwenye kishikizi kimoja na linganisha.

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

Ikiwa hilo linafanikiwa, marekebisho ni ya usanidi wa programu, si ya handaki. Rudia ukaguzi kwa kila mazingira ya utekelezaji katika mradi, kwa sababu kila moja husoma chanzo tofauti na huenda ni kimoja tu kilichovunjika.

Bandari uliyochagua si bandari ambayo sera inaruhusu

Mwenyeji aliyeelekezwa si huduma iliyoruhusiwa. Sera ya kampuni kwa kawaida huruhusu bandari za wavuti zinazotoka na hutupa nyingine, kwa hiyo huduma kwenye 8080 au 1883 haifikiki wakati 443 inafanya kazi vizuri. Kivinjari hakithibitishi chochote hapa: kinatumia 443 kwa ufafanuzi.

Tangaza huduma hiyo hiyo nyuma ya 443 na uifikie kwa jina kabla ya kuomba msamaha. Ikiwa msamaha unahitajika kweli, weka kikomo kwa safu moja ya chanzo na lengo moja na uichukulie kama sehemu ya ufafanuzi wa huduma, si kama njia ya kibinafsi ya mtu.

TCP mbichi ambayo njia huiweka upya

Miunganisho ya TCP mbichi ya muda mrefu ni tabaka linaloshindikana kwa njia ya kuchanganya zaidi. Njia inayoruhusu trafiki ya wavuti bado inaweza kuweka upya au kuandika upya TCP inayotoka isiyo ya kawaida, na mteja huripoti kosa la soketi ambalo husomwa kama kukatika. Huduma za ujumbe na matukio kwa kawaida hutoa usafirishaji wa WebSocket kwa ajili ya mtandao wa aina hii, na kubadilisha ni chaguo la mteja, si mabadiliko ya handaki.

Badilisha usafirishaji, jaribu tena na usibadilishe kitu kingine katika mbio hizo hizo. Jaribio hilo la kigezo kimoja hukuambia kama uwekaji upya ulitoka kwenye njia au kwenye huduma.

Miunganisho inayofungwa tu kwa mizigo mikubwa

Ombi linalofanikiwa kisha kufa karibu sekunde moja baadaye, lakini tu wakati mwili ni mkubwa, linaelekeza kwenye kikomo cha ukubwa mahali katikati. Mpatanishi anayehesabu baiti za ujumbe anaweza kuangusha muunganisho katikati ya uhawilishaji, na mteja huripoti kufungwa kusiko kawaida badala ya muda wa kusubiri.

Gawanya mzigo vipande vipande kwenye tabaka la programu. Weka hilo kando na kazi ya MTU: kupunguza ukubwa wa pakiti ya handaki husaidia wakati vikao vya kawaida vya TCP vinasimama kwa idadi isiyobadilika ya baiti, na hakifanyi chochote kwa ujumbe ambao mpatanishi anaona ni mkubwa mno.

Jinsi ya kutofautisha wanne kwa mpito mmoja

Uchunguzi tatu hutatua kesi nyingi. Kushindikana kunatokea mara moja au tu kwa mwili mkubwa? Ombi lile lile linafanikiwa proksi ikiwa imezimwa? Matokeo hubadilika unapobadilisha bandari au usafirishaji? Andika majibu kabla ya mabadiliko yajayo, kwa sababu VPN ya kampuni pamoja na proksi iliyorithiwa pamoja na chaguo-msingi la programu hukupa sababu tatu zinazowezekana kwa wakati mmoja.

Weka kigezo kimoja kwa jaribio na uandike mwenyeji wa lengo uliyotumia. Bila msingi huo, mtu anayefuata hurudia hatua zote nne tangu mwanzo.