Zergatik VPN gune bateko 403 ez den proxy akats bat

Erabiltzaileek VPNa deskonektatzen dute, barneko gune batean 403 bat jasotzen dute eta proxyak huts egin duela jakinarazten dute. Hiru gauza bereizik sor dezakete orri hori: jatorriak eskaera ukatu zuen, aurreko proxyak tunela irekitzea ukatu zuen edo proxyak bere kredentzialak eskatu zituen. Horietako bakoitza galdera desberdin bati emandako erantzun zuzena da, eta horiek hutsegite-orri generiko bakarrean zapaltzeak duzun froga bakarra suntsitzen du. Sailkatu ukapena egin zuen osagaiaren arabera, eta gero konparatu osagai bakoitzak benetan erabiltzen duen sare-bidea.

Izenda ezazu 403a sortu zuen osagaia

HTTP egoera-kode bat bidali zuen alderdiarena da. Jatorriak 403 itzultzen duenean, eskaera aztertu du eta deitzaileak baliabidea ez duela izan daitekeela erabaki du, eta hori baimen-erantzuna da, ez garraio-arazoa. Aurreko proxy batek CONNECT bati 403 erantzuten dionean, tunela eraikitzea erabat ukatu du eta goragoko ezer ez da inoiz kontaktatu. 407 erantzuten duenean, bere kredentzialak nahi ditu, eta horiek ez dute zerikusirik aplikazioaren saio-hasierarekin.

RFC 9110 arauak zeregin horiek definitzen ditu, proxyari dagokion erronka barne. Irakurri erantzunaren beraren egoera eta Proxy-Authenticate goiburua gorputza irakurri aurretik, HTML errore-orri atsegin batek normalean ezkutatzen baitu zein osagaik idatzi zuen.

Zer ezkutatzen duen CONNECT tunel batek byte errele batetik

Proxy batek CONNECT-i 200 itzultzen dionean, byteak erreleatzen ari da eta nabigatzaileak bere TLS saioa mantentzen du jatorriarekin. Beraz, byteak erreleatzen dituen proxy batek ezin du saio horren barruko 403 zifratua irakurri, eta ez da inoiz ukatzearen egilea bihurtzen. Tunela ireki aurretik emandako uko bat erabat bestelako gertaera da, geruza bat beherago sortua.

TLS amaitzen duen alderantzizko proxy bat beste posizio batean dago: TLS mugaren jabe da, HTTP aztertzen du eta erantzunak berridazteko edo atzemateko gaitasuna du zilegi. Gaitasun hori konfigurazio-aukeraketa da, ez proxyingaren ezaugarri orokorra, eta ez du aplikazioaren sarbide-politika saihesteko baimenik ematen. Erantzuna irakurtzea gaitasuna da; deitzaileak zer ikus dezakeen erabakitzea jatorriaren lana izaten jarraitzen du.

Ondorio praktikoa da jakin behar duzula hiru formetako zein exekutatzen duzun 403 bat interpretatu aurretik. Proxy fluxu bati HTTP ikuskapen-arauak gehitzeak ez dio ikusgaitasunik ematen, eta byte errele bati jatorriaren ukoa azaltzea espero baduzu, okerreko erregistrora bidaliko zaitu.

Konparatu proxyaren irteera-bidea nabigatzailearen tunel-helbidearekin

VPN batera konektatutako nabigatzaile batek ez du proxy zerbitzari bereizi bat automatikoki tunel horretara eramaten. Jatorriak proxyaren irteera-helbidea ikusten du, eta proxyak oraindik tokiko bide lehenetsitik irteten badu, babestutako guneak inoiz fidatzeko konfiguratu ez zen helbide bat ikusten du. Gailu eramangarriko barne VPN helbidea ikusezina da jatorri horrentzat. Hori da tunel bat funtzionatzen ari dela beste guztientzat behar bezala jokatzen duen gune batek oraindik 403 emateko arrazoi ohikoena.

Probatu bi bideak bereiz, helbideak ez nahasteko.

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

Lehen eskaerak jatorriak zure helbideari zer erantzuten dion erakusten du, bigarrenak proxyarenari zer erantzuten dion. Bat datozen 403 bikote batek jatorriaren baimen-arauak seinalatzen ditu; 200 baten ondoren 403 bat etortzeak proxyaren bidea seinalatzen du. Galdetu jatorriaren jabeari arau-multzoak zein iturburu-helbide onartzen dituen benetan, VPN igerilekua barne dagoela suposatu ordez.

Probatu muga bakoitza isolatzen duen eskaera batekin

Isolatu proxy geruza aplikazio-arrazoiengatik uka ezin dezakeen zerbait eskatuz. Proxyak iristeko baimena duen ostalari baterako CONNECT bat, irteera baztertuta, tunelaren onarpenak batere funtzionatzen duen esaten dizu.

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'

Horrek CONNECT-rako 200 eta gero TLS esku-emate bat inprimatzen badu, proxyaren onarpena ondo dago eta geroagoko 403a jatorritik etorri da. 407 inprimatzen badu, eman proxy kredentzialak --proxy-user bidez eta errepikatu gunearen gaineko ondoriorik atera aurretik. CONNECT lerroan 403 inprimatzen badu, proxyaren beraren baimen-zerrenda da aztertu beharreko muga, eta aplikazioa ez dago sartuta.

Eduki kredentzialak shell historiatik eta itsatsitako transkripzioetatik kanpo. Komando-lerro batean idatzitako proxy pasahitza beste tokiko erabiltzaile batzuentzat ikusgai dago, eta kredentzialekin harrapatutako CONNECT arrasto bat inolako arrastorik ez izatea baino okerragoa da.

Eduki epaia irakurgarri, orria berridazten aritu beharrean

Osagai batek ukatu zuela jakinda, gorde erantzun hori. Jatorrizko 403 bat 504 denbora-muga gisa berrizendatzen duen edo arrakasta-orri batekin ordezkatzen duen alderantzizko proxy batek baimen-erabaki bat erabilgarritasun-istorio baten atzean ezkutatzen du eta hurrengo erantzulea talde okerrean bidaltzen du. Errore-orri pertsonalizatuak ondo daude egoera mantendu eta testuingurua gehitzen badute.

Cacheak arreta bera merezi du. RFC 9111 arauak zehazten du nola kate partekatuek erantzunak berrerabil ditzaketen, eta deitzaile batentzat sortutako uko bat ez zaio beste bati baimena bailitzan eman behar. Uko-erantzunak gordetzen badira, eduki itzazu pribatu eta mugatu, eta ez gehitu inoiz freskotasun-arau publiko bat gorako trafikoa murriztearren soilik.

Amaitu idatzizko epai batekin, osagaia, sortu zuen egoera eta jatorriak ikusi zuen iturburu-helbidea izendatzen dituena. Erregistratu eskaera zehatza, indarrean dauden proxy ezarpenak eta ordua, hurrengo txostena froga berberekin aldera dadin, memoriarik berriz eratorri beharrean. Erregistro horrek hurrengo txostena segundotan erantzuten du eta 403 bera berriro VPN etendura gisa diagnostikatzea eragozten du.