Pse një 403 nga një sajt VPN nuk është dështim i proxy-t

Përdoruesit shkëputin VPN-në, hasin një 403 në një sajt të brendshëm dhe raportojnë se proxy-ja është prishur. Tre gjëra të ndara mund ta prodhojnë atë faqe: origjina e refuzoi kërkesën, proxy-ja përpara refuzoi të hapë tunelin, ose proxy-ja kërkoi kredencialet e veta. Secila prej tyre është përgjigje e saktë për një pyetje tjetër, dhe rrafshimi i tyre në një faqe të përgjithshme dështimi shkatërron provën e vetme që keni. Renditni refuzimin sipas komponentit që e prodhoi, pastaj krahasoni rrugën e rrjetit që përdor vërtet secili komponent.

Emërtoni komponentin që prodhoi 403

Një kod statusi HTTP i përket palës që e dërgoi. Kur origjina kthen 403, e ka analizuar kërkesën dhe ka vendosur që thirrësi mund të mos e ketë burimin, që është përgjigje autorizimi dhe jo problem transporti. Kur një proxy përpara përgjigjet 403 për një CONNECT, ka refuzuar ta ndërtojë tunelin fare, dhe asgjë sipër nuk u kontaktua ndonjëherë. Kur përgjigjet 407, kërkon kredencialet e veta, të cilat nuk kanë asnjë lidhje me hyrjen e aplikacionit.

RFC 9110 përcakton këto role, përfshirë sfidën specifike të proxy-t. Lexoni statusin e vetë përgjigjes dhe çdo header Proxy-Authenticate përpara se të lexoni trupin, sepse një faqe gabimi HTML miqësore zakonisht fsheh cili komponent e shkroi.

Çfarë fsheh një tunel CONNECT nga një përcjellës bajtesh

Pasi proxy-ja kthen 200 për CONNECT, po përcjell bajte dhe shfletuesi mban sesionin e vet TLS me origjinën. Prandaj një proxy që përcjell bajte nuk mund të lexojë 403-in e kriptuar brenda atij sesioni dhe nuk bëhet kurrë autor i refuzimit. Një refuzim para se të hapet tuneli është një ngjarje krejt tjetër, e prodhuar një shtresë më poshtë.

Një proxy i kundërt që përfundon TLS është në një pozicion tjetër: zotëron kufirin TLS, analizon HTTP dhe mund të rishkruajë ose përgjojë ligjërisht përgjigjet. Kjo aftësi është zgjedhje konfigurimi, jo veti e proxy-t në përgjithësi, dhe nuk autorizon anashkalimin e politikës së aksesit të aplikacionit. Leximi i përgjigjes është aftësi; vendimi se çfarë mund të shohë thirrësi mbetet puna e origjinës.

Pasoja praktike është se duhet të dini cilën nga tre format po ekzekutoni përpara se të interpretoni një 403. Shtimi i rregullave të inspektimit HTTP te një proxy rrjedhës nuk i jep dukshmëri, dhe pritja që një përcjellës bajtesh të shpjegojë një refuzim të origjinës do t'ju dërgojë në regjistrin e gabuar.

Krahasoni rrugën e daljes së proxy-t me adresën e tunelit të shfletuesit

Një shfletues i lidhur me një VPN nuk e zhvendos automatikisht një server proxy të veçantë në atë tunel. Origjina sheh adresën e daljes së proxy-t, dhe nëse proxy-ja ende del përmes rrugës parazgjedhëse lokale, sajti i mbrojtur sheh një adresë që nuk u konfigurua kurrë për t'u besuar. Adresa e brendshme VPN në laptop është e padukshme për atë origjinë. Ky është shkaku më i zakonshëm pse një tunel që funksionon ende jep 403 nga një sajt që sillet saktë për të gjithë të tjerët.

Testoni të dyja rrugët veçmas, që adresat të mos ngatërrohen.

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

Kërkesa e parë tregon çfarë përgjigjet origjina për adresën tuaj, e dyta tregon çfarë përgjigjet për atë të proxy-t. Një çift 403 që përputhet tregon rregullat e autorizimit të origjinës; një 200 i ndjekur nga 403 tregon rrugën e proxy-t. Pyetni pronarin e origjinës se cilat adresa burimi pranon vërtet grupi i rregullave, në vend që të supozoni se pishina VPN është përfshirë.

Testoni çdo kufi me një kërkesë që e izolon atë

Izoloni shtresën e proxy-t duke i kërkuar diçka që nuk mund ta refuzojë për arsye aplikacioni. Një CONNECT drejt një hosti që proxy-ja lejohet të arrijë, me daljen e hedhur, ju tregon nëse pranimi në tunel funksionon fare.

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'

Nëse kjo printon 200 për CONNECT dhe më pas një shtrëngim duarsh TLS, pranimi i proxy-t është në rregull dhe 403-i i mëvonshëm erdhi nga origjina. Nëse printon 407, jepni kredencialet e proxy-t me --proxy-user dhe përsëritni përpara se të nxirrni ndonjë përfundim për sajtin. Nëse printon 403 në rreshtin CONNECT, lista e lejeve e vetë proxy-t është kufiri që duhet shqyrtuar, dhe aplikacioni nuk është i përfshirë.

Mbani kredencialet jashtë historisë së shell-it dhe jashtë transkripteve të ngjitura. Një fjalëkalim proxy i shtypur në një rresht komande është i dukshëm për përdorues të tjerë lokalë, dhe një gjurmë CONNECT e kapur me kredenciale është më keq se asnjë gjurmë.

Mbani verdiktin të lexueshëm në vend që të rishkruani faqen

Pasi të dini cili komponent refuzoi, ruajeni atë përgjigje. Një proxy i kundërt që riemërton një 403 të origjinës si skadim kohe 504, ose e zëvendëson me një faqe suksesi, fsheh një vendim autorizimi pas një historie disponueshmërie dhe e dërgon përgjigjësin e radhës në ekipin e gabuar. Faqet e gabimit të personalizuara janë në rregull kur ruajnë statusin dhe shtojnë kontekst.

Cache-ja meriton të njëjtin kujdes. RFC 9111 rregullon se si cache-t e përbashkëta mund të ripërdorin përgjigjet, dhe një refuzim i prodhuar për një thirrës nuk duhet t'i jepet një tjetri sikur të ishte leje. Nëse përgjigjet e refuzimit ruhen fare, mbani ato private dhe të kufizuara, dhe mos shtoni kurrë një rregull publik freskie vetëm për të reduktuar trafikun sipër.

Përfundoni me një verdikt të shkruar që emërton komponentin, statusin që prodhoi dhe adresën burimore që pa origjina. Regjistroni kërkesën e saktë, cilësimet e proxy-t në fuqi dhe kohën, që raporti i radhës të mund të përputhet me të njëjtat prova në vend që të nxirret përsëri nga kujtesa. Ai regjistrim i përgjigjet raportit të radhës brenda sekondave dhe ndalon ridiagnostikimin e të njëjtit 403 si ndërprerje VPN.