Af hverju 403 frá VPN-síðu er ekki bilun í proxy
403 frá uppruna, hafnað CONNECT og 407 áskorun merkja mismunandi mörk. Berið fyrst saman útleið proxysins og VPN-vistfangið í vafranum.
Notendur aftengja VPN, lenda í 403 á innri síðu og tilkynna að proxyið sé bilað. Þrír aðskildir hlutir geta búið til þá síðu: uppruninn hafnaði beiðninni, framproxyið neitaði að opna göngin eða proxyið krafðist eigin skírteina. Hver þeirra er rétt svar við annarri spurningu, og að slétta þau í eina almennilega bilunarsíðu eyðileggur eina sönnunargagnið sem þú hefur. Raðaðu höfnuninni eftir þeim hluta sem bjó hana til og berðu síðan saman netleiðinni sem hver hluti notar í raun.
Nefndu hlutinn sem bjó til 403
HTTP-stöðukóði tilheyrir þeim aðila sem sendi hann. Þegar uppruninn skilar 403 hefur hann greint beiðnina og ákveðið að kallið eigi kannski ekki auðlindina, sem er heimildarsvar en ekki flutningsvandamál. Þegar framproxy svarar 403 á CONNECT neitaði það að byggja göngin yfirleitt, og ekkert ofar var nokkurn tíma haft samband við. Þegar það svarar 407 vill það eigin skírteini, sem hafa ekkert með innskráningu forritsins að gera.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 skilgreinir þessi hlutverk, þar á meðal áskorunina sem snýr sérstaklega að proxy. Lestu stöðu svarsins sjálfs og hvaða Proxy-Authenticate-haus sem er áður en þú lest meginmálið, því vingjarnleg HTML-villusiða felur venjulega hvaða hluti skrifaði hana.
Hvað CONNECT-göngin fela fyrir bætaendursendingu
Þegar proxy skilar 200 á CONNECT er það að endursenda bæti og vafrinn heldur sínum eigin TLS-fundi við upprunann. Proxy sem endursendir bæti getur því ekki lesið dulkóðuðu 403 inni í þeim fundi, og það verður aldrei höfundur höfnunarinnar. Höfnun áður en göngin opnast er gjörólíkur atburður, framleiddur einu lagi neðar.
Andhverft proxy sem lýkur TLS er í annarri stöðu: það á TLS-mörkin, greinir HTTP og getur lögmætlega endurskrifað eða stöðvað svör. Sú geta er stillingarval, ekki eiginleiki proxys almennt, og hún veitir ekki heimild til að fara fram hjá aðgangsstefnu forritsins. Að lesa svarið er geta; að ákveða hvað kallið má sjá er áfram verk upprunans.
Hagnýt afleiðing er að þú verður að vita hvaða af þremur myndum þú keyrir áður en þú túlkar 403. Að bæta HTTP-skoðunarreglum við straumproxy gefur því ekki sýnileika, og ef þú býst við að bætaendursending skýri höfnun upprunans muntu leita í röngum annál.
Berið saman útleið proxysins og gönguvistfang vafrans
Vafri sem er tengdur VPN færir ekki sjálfkrafa sérstakan proxymiðlara yfir á þau göng. Uppruninn sér útleiðarvistfang proxysins, og ef proxyið fer enn út um staðbundnu sjálfgefnu leiðina sér varða síðan vistfang sem aldrei var stillt til að treysta. Innra VPN-vistfangið á fartölvunni er ósýnilegt þeim uppruna. Þetta er algengasta ástæðan fyrir því að virk göng skila enn 403 frá síðu sem hegðar sér rétt gagnvart öllum öðrum.
Prófaðu leiðirnar tvær í sitt hvoru lagi svo vistföngin ruglist ekki.
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/privateFyrsta beiðnin sýnir hvað uppruninn svarar fyrir þitt eigið vistfang, önnur sýnir hvað hann svarar fyrir vistfang proxysins. Samstæð 403 par bendir á heimildarreglur upprunans; 200 sem 403 fylgir bendir á leið proxysins. Spurðu eiganda upprunans hvaða upprunavistföng reglurnar leyfa í raun í stað þess að gera ráð fyrir að VPN-laugin sé meðtalinn.
Prófaðu hvert mark með beiðni sem einangrar það
Einangraðu proxylagið með því að biðja það um eitthvað sem það getur ekki hafnað af forritsástæðum. CONNECT á hýsil sem proxyinu er leyft að ná til, með úttaki hent, segir þér hvort innganga í göngin virki yfirleitt.
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'
Ef það prentar 200 fyrir CONNECT og síðan TLS-handaband, er innganga proxysins í lagi og síðara 403 kom frá upprunanum. Ef það prentar 407 skaltu gefa proxyskírteini með --proxy-user og endurtaka áður en þú dregur nokkra ályktun um síðuna. Ef það prentar 403 á CONNECT-línunni er eigin leyfislisti proxysins markið sem á að skoða, og forritið kemur ekki við sögu.
Haltu skírteinum utan skeljasögunnar og utan límdra umritana. Lykilorð proxys sem slegið er inn á skipanalínu er sýnilegt öðrum staðbundnum notendum, og handtekið CONNECT-sport með skírteinum er verra en ekkert sport.
Haltu úrskurðinum læsilegum í stað þess að endurskrifa síðuna
Þegar þú veist hvaða hluti hafnaði skaltu varðveita það svar. Andhverft proxy sem endurnefnir 403 upprunans sem 504-tímamörk, eða skiptir því út fyrir árangurssíðu, felur heimildarákvörðun bak við sögu um aðgengi og sendir næsta svarendur til rangs teymis. Sérsniðnar villusíður eru í lagi þegar þær halda stöðunni og bæta við samhengi.
Skyndiminni á skilið sömu umönnun. RFC 9111 stýrir því hvernig sameiginleg skyndiminni mega endurnýta svör, og höfnun sem framleidd er fyrir einn kalla má ekki afhenda öðrum eins og hún sé heimild. Ef höfnunarsvör eru geymd yfirleitt skaltu halda þeim einkareknum og afmörkuðum, og bættu aldrei við opinberri ferskleikareglu eingöngu til að draga úr umferð ofar.
Ljúktu með skriflegum úrskurði sem nefnir hlutinn, stöðuna sem hann bjó til og upprunavistfangið sem uppruninn sá. Skráðu nákvæmu beiðnina, gildandi proxystillingar og tímann, svo hægt sé að bera næstu skýrslu við sömu sönnunargögn í stað þess að leiða þau aftur út úr minni. Sú skrá svarar næstu skýrslu á sekúndum og kemur í veg fyrir að sama 403 greinist aftur sem VPN-rof.