Kvifor ein 403 frå ein VPN-nettstad ikkje er ein proxyfeil

Brukarar koplar frå VPN-en, treff ein 403 på ein intern nettstad og rapporterer at proxyen er øydelagd. Tre separate ting kan produsere den sida: opphavet avviste førespurnaden, videresendingsproxyen nekta å opne tunnelen, eller proxyen kravde eigne påloggingsdata. Kvar av dei er eit riktig svar på eit anna spørsmål, og å flate dei ut til éi generisk feilside øydelegg det einaste beviset du har. Sorter avvisinga etter komponenten som laga henne, og samanlikn deretter nettverksstien kvar komponent faktisk brukar.

Namngi komponenten som produserte 403

Ein HTTP-statuskode høyrer til parten som sende han. Når opphavet returnerer 403, har det analysert førespurnaden og bestemt at den som ringjer kanskje ikkje har ressursen, noko som er eit autorisasjonssvar og ikkje eit transportproblem. Når ein videresendingsproxy svarar 403 på ein CONNECT, nekta han å byggje tunnelen i det heile, og ingenting oppstraums vart nokon gong kontakta. Når han svarar 407, vil han ha eigne påloggingsdata, som ikkje har noko med innlogginga i applikasjonen å gjere.

RFC 9110 definerer desse rollene, inkludert den proxyspesifikke utfordringa. Les sjølve statusen til svaret og ein kvar Proxy-Authenticate-header før du les kroppen, fordi ei venleg HTML-feilside vanlegvis skjuler kva komponent som skreiv henne.

Kva ein CONNECT-tunnel skjuler for ein byterelay

Når ein proxy returnerer 200 på CONNECT, videresender han byte, og nettlesaren held sin eigen TLS-økt med opphavet. Ein byterelay-proxy kan difor ikkje lese den krypterte 403 inne i den økta, og han blir aldri forfattaren av avvisinga. Ei avvising før tunnelen opnar er ei heilt anna hending, produsert eitt lag lenger nede.

Ein TLS-terminerande reversproxy står i ein annan posisjon: han eig TLS-grensa, analyserer HTTP og kan legitimt skrive om eller fange opp svar. Den evna er eit konfigurasjonsval, ikkje ein eigenskap ved proxy generelt, og ho gir ikkje rett til å omgå tilgangspolitikken til applikasjonen. Å lese svaret er ei evne; å avgjere kva den som ringjer får sjå, blir framleis opphavet si oppgåve.

Den praktiske konsekvensen er at du må vite kva av dei tre formene du køyrer før du tolkar ein 403. Å leggje til HTTP-inspeksjonsreglar på ein straumproxy gir han ikkje synlegheit, og å vente at ein byterelay forklarer ei opphavsavvising vil sende deg til feil logg.

Samanlikn utgangsstien til proxyen med tunneladressa til nettlesaren

Ein nettlesar som er kopla til ein VPN flyttar ikkje automatisk ein separat proxyserver over på den tunnelen. Opphavet ser utgangsadressa til proxyen, og dersom proxyen framleis går ut gjennom den lokale standardruta, ser den verna nettstaden ei adresse som han aldri var konfigurert til å stole på. Den indre VPN-adressa på laptopen er usynleg for det opphavet. Dette er den enkelt mest vanlege grunnen til at ein fungerande tunnel framleis gir ein 403 frå ein nettstad som oppfører seg rett for alle andre.

Test dei to stiane kvar for seg slik at adressene ikkje kan forvekslast.

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

Den første førespurnaden viser kva opphavet svarar på di eiga adresse, den andre viser kva han svarar på adressa til proxyen. Eit samsvarande par 403 peikar på autorisasjonsreglane til opphavet; ein 200 etterfølgt av ein 403 peikar på proxy-stien. Spør eigaren av opphavet kva kjeldeadresser regelsettet faktisk tillèt, i staden for å anta at VPN-poolen er inkludert.

Test kvar grense med ein førespurnad som isolerer henne

Isoler proxy-laget ved å be det om noko det ikkje kan nekte av applikasjonsgrunnar. Ein CONNECT til ein vert som proxyen har lov til å nå, med utdata kasta, fortel deg om tunnelopptak i det heile fungerer.

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'

Dersom det skriv ut ein 200 for CONNECT og deretter eit TLS-handtrykk, er proxyopptaket i orden, og den seinare 403 kom frå opphavet. Dersom det skriv ut 407, oppgi proxy-påloggingsdata med --proxy-user og gjenta før du dreg noka konklusjon om nettstaden. Dersom det skriv ut 403 på CONNECT-linja, er den eigne tillatingslista til proxyen grensa som skal undersøkjast, og applikasjonen er ikkje involvert.

Hald påloggingsdata utanfor skal-historikken og utanfor innlimte transkripsjonar. Eit proxy-passord som blir skrive inn på ei kommandolinje, er synleg for andre lokale brukarar, og eit fanga CONNECT-spor med påloggingsdata er verre enn ingen spor i det heile.

Hald avgjerda lesbar i staden for å skrive om sida

Når du veit kva komponent som nekta, ta vare på det svaret. Ein reversproxy som døyper om ein opphavs-403 til ein 504-tidsavbrot, eller erstattar han med ei suksessside, skjuler ei autorisasjonsavgjerd bak ei tilgjengelegheitssoge og sender neste respondent til feil team. Eigendefinerte feilsider er fine når dei held på statusen og legg til kontekst.

Bufring fortener same omsut. RFC 9111 regulerer korleis delte bufre kan bruke svar om att, og ei avvising produsert for ein som ringjer må ikkje givast vidare til ein annan som om det var løyve. Dersom avvisingssvar i det heile blir lagra, hald dei private og avgrensa, og legg aldri til ein offentleg ferskleiksregel berre for å redusere oppstraums trafikk.

Avslutt med ei skriftleg avgjerd som namngir komponenten, statusen han produserte, og kjeldeadressa opphavet såg. Registrer den nøyaktige førespurnaden, gjeldande proxyinnstillingar og tidspunktet, slik at neste rapport kan matchast mot dei same bevisa i staden for å bli leidd ut på nytt frå minnet. Den registreringa svarar på neste rapport på sekund og hindrar at den same 403-en igjen blir diagnostisert som eit VPN-utfall.