Kwa nini 403 kutoka tovuti ya VPN si hitilafu ya proksi

Watumiaji hukata VPN, hukutana na 403 kwenye tovuti ya ndani na kuripoti kuwa proksi imeharibika. Mambo matatu tofauti yanaweza kuzalisha ukurasa huo: asili ilikataa ombi, proksi ya mbele ilikataa kufungua handaki, au proksi ilidai vitambulisho vyake. Kila moja ni jibu sahihi la swali tofauti, na kuzipanga pamoja katika ukurasa mmoja wa jumla wa hitilafu huharibu ushahidi pekee ulio nao. Panga kukataliwa kwa sehemu iliyoizalisha, kisha linganisha njia ya mtandao ambayo kila sehemu hutumia kweli.

Taja sehemu iliyozalisha 403

Msimbo wa hali ya HTTP ni wa upande uliotuma. Wakati asili inarudisha 403, imechanganua ombi na kuamua kwamba mpigaji anaweza asiwe na rasilimali, jambo ambalo ni jibu la idhini na si tatizo la usafirishaji. Wakati proksi ya mbele inajibu 403 kwa CONNECT, ilikataa kujenga handaki kabisa, na hakuna kitu kilichowasiliana juu yake. Wakati inajibu 407, inataka vitambulisho vyake, ambavyo havina uhusiano wowote na kuingia kwa programu.

RFC 9110 inafafanua majukumu haya, ikiwa ni pamoja na changamoto maalum ya proksi. Soma hali ya jibu lenyewe na kichwa chochote cha Proxy-Authenticate kabla ya kusoma mwili, kwa sababu ukurasa wa hitilafu wa HTML wenye urafiki kwa kawaida huficha sehemu iliyoandika.

Kile handaki ya CONNECT huficha kutoka kwa kipitishaji baiti

Baada ya proksi kurudisha 200 kwa CONNECT, inapitisha baiti na kivinjari kinahifadhi kipindi chake cha TLS na asili. Kwa hivyo proksi inayopitisha baiti haiwezi kusoma 403 iliyofichwa ndani ya kipindi hicho, na kamwe haifanyiki kuwa mwandishi wa kukataliwa. Kukataliwa kabla ya handaki kufunguka ni tukio tofauti kabisa, linalozalishwa tabaka moja chini.

Proksi ya kinyume inayomaliza TLS iko katika nafasi tofauti: inamiliki mpaka wa TLS, inachanganua HTTP na inaweza kuandika upya au kunasa majibu kwa njia halali. Uwezo huo ni chaguo la usanidi, si sifa ya proksi kwa ujumla, na hautoi idhini ya kupitiliza sera ya ufikiaji ya programu. Kusoma jibu ni uwezo; kuamua kile mpigaji anachoweza kuona kunabaki kuwa kazi ya asili.

Matokeo ya vitendo ni kwamba lazima ujue ni umbo gani kati ya matatu unaendesha kabla ya kufasiri 403. Kuongeza sheria za ukaguzi wa HTTP kwa proksi ya mtiririko hakupi mwonekano, na kutarajia kipitishaji baiti kueleza kukataliwa kwa asili kutakupeleka kwenye kumbukumbu isiyo sahihi.

Linganisha njia ya kutoka ya proksi na anwani ya handaki ya kivinjari

Kivinjari kilichounganishwa na VPN haki hamishi seva ya proksi tofauti kwenye handaki hiyo kiotomatiki. Asili inaona anwani ya kutoka ya proksi, na ikiwa proksi bado inatoka kupitia njia chaguo-msingi ya ndani, tovuti iliyolindwa inaona anwani ambayo haikuwahi kusanidiwa kuaminiwa. Anwani ya ndani ya VPN kwenye kompyuta ya mkononi haionekani kwa asili hiyo. Hii ndiyo sababu ya kawaida zaidi kwa nini handaki inayofanya kazi bado inatoa 403 kutoka tovuti inayojitendea vizuri kila mtu mwingine.

Jaribu njia mbili kwa tofauti ili anwani zisichanganyike.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Ombi la kwanza linaonyesha asili inajibu nini kwa anwani yako, la pili linaonyesha inajibu nini kwa anwani ya proksi. Jozi ya 403 inayolingana inaonyesha sheria za idhini za asili; 200 ikifuatiwa na 403 inaonyesha njia ya proksi. Muulize mmiliki wa asili ni anwani gani za chanzo seti ya sheria inakubali kweli, badala ya kudhani kuwa bwawa la VPN limejumuishwa.

Jaribu kila mpaka kwa ombi linaloitenga

Tenga tabaka la proksi kwa kuomba kitu ambacho haiwezi kukataa kwa sababu za programu. CONNECT kwa mwenyeji ambaye proksi inaruhusiwa kufikia, huku matokeo yakitupwa, inakuambia ikiwa uingiaji wa handaki unafanya kazi hata kidogo.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Ikiwa hiyo inachapisha 200 kwa CONNECT na kisha kupeana mkono kwa TLS, uingiaji wa proksi ni sawa na 403 ya baadaye ilitoka kwa asili. Ikiwa inachapisha 407, toa vitambulisho vya proksi kwa --proxy-user na urudie kabla ya kufikia hitimisho lolote kuhusu tovuti. Ikiwa inachapisha 403 kwenye mstari wa CONNECT, orodha ya ruhusa ya proksi yenyewe ndio mpaka wa kuchunguza, na programu haihusiki.

Weka vitambulisho nje ya historia ya shell na nje ya nakala zilizopachikwa. Nenosiri la proksi lililoandikwa kwenye mstari wa amri linaonekana kwa watumiaji wengine wa ndani, na alama ya CONNECT iliyonaswa na vitambulisho ni mbaya kuliko kutokuwa na alama yoyote.

Weka uamuzi uweze kusomeka badala ya kuandika upya ukurasa

Baada ya kujua ni sehemu gani ilikataa, hifadhi jibu hilo. Proksi ya kinyume inayobadilisha jina la 403 ya asili kuwa muda wa kumalizika 504, au kuibadilisha na ukurasa wa mafanikio, huficha uamuzi wa idhini nyuma ya hadithi ya upatikanaji na kumtuma mjibu anayefuata kwa timu isiyo sahihi. Kurasa za hitilafu maalum ni sawa zinapohifadhi hali na kuongeza muktadha.

Uhifadhi wa akiba unastahili uangalifu sawa. RFC 9111 inasimamia jinsi akiba za pamoja zinavyoweza kutumia majibu tena, na kukataliwa kulikozalishwa kwa mpigaji mmoja hakupaswi kupewa mwingine kana kwamba ni ruhusa. Ikiwa majibu ya kukataliwa yanahifadhiwa hata kidogo, yahifadhi kama ya faragha na yenye mipaka, na kamwe usiongeze sheria ya ubichi ya umma ili tu kupunguza trafiki ya juu.

Maliza kwa uamuzi ulioandikwa unaotaja sehemu, hali iliyoizalisha na anwani ya chanzo ambayo asili iliona. Rekodi ombi kamili, mipangilio ya proksi inayotumika na muda, ili ripoti inayofuata iweze kulinganishwa na ushahidi huo huo badala ya kutolewa tena kutoka kwa kumbukumbu. Rekodi hiyo hujibu ripoti inayofuata kwa sekunde na huzuia 403 hiyo hiyo kutambuliwa tena kama kukatika kwa VPN.