Hvorfor en 403 fra et VPN-nettsted ikke er en proxyfeil

Brukere kobler fra VPN-en, treffer en 403 på et internt nettsted og rapporterer at proxyen er ødelagt. Tre separate ting kan produsere den siden: opprinnelsen avviste forespørselen, videresendingsproxyen nektet å åpne tunnelen, eller proxyen krevde egne påloggingsdata. Hver av dem er et riktig svar på et annet spørsmål, og å flate dem ut til én generisk feilside ødelegger det eneste beviset du har. Sorter avvisningen etter komponenten som laget den, og sammenlign deretter nettverksstien hver komponent faktisk bruker.

Navngi komponenten som produserte 403

En HTTP-statuskode tilhører parten som sendte den. Når opprinnelsen returnerer 403, har den analysert forespørselen og bestemt at den som ringer kanskje ikke har ressursen, noe som er et autorisasjonssvar og ikke et transportproblem. Når en videresendingsproxy svarer 403 på en CONNECT, nektet den å bygge tunnelen i det hele tatt, og ingenting oppstrøms ble noen gang kontaktet. Når den svarer 407, vil den ha egne påloggingsdata, som ikke har noe med applikasjonens innlogging å gjøre.

RFC 9110 definerer disse rollene, inkludert den proxyspesifikke utfordringen. Les svarets egen status og enhver Proxy-Authenticate-header før du leser kroppen, fordi en vennlig HTML-feilside vanligvis skjuler hvilken komponent som skrev den.

Hva en CONNECT-tunnel skjuler for en byterelay

Når en proxy returnerer 200 på CONNECT, videresender den bytes, og nettleseren beholder sin egen TLS-økt med opprinnelsen. En byterelay-proxy kan derfor ikke lese den krypterte 403 inne i den økten, og den blir aldri forfatteren av avvisningen. En avvisning før tunnelen åpnes er en helt annen hendelse, produsert ett lag lenger ned.

En TLS-terminerende reversproxy står i en annen posisjon: den eier TLS-grensen, analyserer HTTP og kan legitimt skrive om eller fange opp svar. Den evnen er et konfigurasjonsvalg, ikke en egenskap ved proxy generelt, og den gir ikke rett til å omgå applikasjonens tilgangspolicy. Å lese svaret er en evne; å avgjøre hva den som ringer får se, forblir opprinnelsens jobb.

Den praktiske konsekvensen er at du må vite hvilken av de tre formene du kjører før du tolker en 403. Å legge til HTTP-inspeksjonsregler på en strømproxy gir den ikke synlighet, og å forvente at en byterelay forklarer en opprinnelsesavvisning vil sende deg til feil logg.

Sammenlign proxyens utgangssti med nettleserens tunneladresse

En nettleser koblet til en VPN flytter ikke automatisk en separat proxyserver over på den tunnelen. Opprinnelsen ser proxyens utgangsadresse, og hvis proxyen fortsatt går ut gjennom den lokale standardruten, ser det beskyttede nettstedet en adresse det aldri var konfigurert til å stole på. Den indre VPN-adressen på laptopen er usynlig for den opprinnelsen. Dette er den enkelt mest vanlige grunnen til at en fungerende tunnel fortsatt gir en 403 fra et nettsted som oppfører seg riktig for alle andre.

Test de to stiene hver for seg slik at adressene ikke kan forveksles.

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 forespørselen viser hva opprinnelsen svarer på din egen adresse, den andre viser hva den svarer på proxyens. Et samsvarende par 403 peker på opprinnelsens autorisasjonsregler; en 200 etterfulgt av en 403 peker på proxy-stien. Spør opprinnelsens eier hvilke kildeadresser regelsettet faktisk tillater, i stedet for å anta at VPN-poolen er inkludert.

Test hver grense med en forespørsel som isolerer den

Isoler proxy-laget ved å be det om noe det ikke kan nekte av applikasjonsgrunner. En CONNECT til en vert som proxyen har lov til å nå, med utdata forkastet, forteller deg om tunnelopptak i det hele tatt 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'

Hvis det skriver ut en 200 for CONNECT og deretter et TLS-håndtrykk, er proxyopptaket i orden, og den senere 403 kom fra opprinnelsen. Hvis det skriver ut 407, oppgi proxy-påloggingsdata med --proxy-user og gjenta før du trekker noen konklusjon om nettstedet. Hvis det skriver ut 403 på CONNECT-linjen, er proxyens egen tillatelsesliste grensen som skal undersøkes, og applikasjonen er ikke involvert.

Hold påloggingsdata utenfor shell-historikken og utenfor innlimte transkripsjoner. Et proxy-passord som skrives inn på en kommandolinje, er synlig for andre lokale brukere, og et fanget CONNECT-spor med påloggingsdata er verre enn ingen spor i det hele tatt.

Hold avgjørelsen lesbar i stedet for å skrive om siden

Når du vet hvilken komponent som nektet, bevar det svaret. En reversproxy som omdøper en opprinnelses-403 til en 504-tidsavbrudd, eller erstatter den med en suksesside, skjuler en autorisasjonsbeslutning bak en tilgjengelighetshistorie og sender neste respondent til feil team. Egendefinerte feilsider er fine når de beholder statusen og legger til kontekst.

Bufring fortjener samme omhu. RFC 9111 regulerer hvordan delte bufre kan gjenbruke svar, og en avvisning produsert for én som ringer må ikke gis videre til en annen som om det var tillatelse. Hvis avvisningssvar i det hele tatt lagres, hold dem private og avgrensede, og legg aldri til en offentlig ferskhetsregel bare for å redusere oppstrøms trafikk.

Avslutt med en skriftlig avgjørelse som navngir komponenten, statusen den produserte, og kildeadressen opprinnelsen så. Registrer den nøyaktige forespørselen, gjeldende proxyinnstillinger og tidspunktet, slik at neste rapport kan matches mot de samme bevisene i stedet for å utledes på nytt fra hukommelsen. Den registreringen svarer på neste rapport på sekunder og hindrer at den samme 403-en igjen diagnostiseres som et VPN-utfall.