Hvorfor en 403 fra et VPN-websted ikke er en proxyfejl

Brugere afbryder VPN'en, rammer en 403 på et internt websted og rapporterer, at proxyen er i stykker. Tre separate ting kan frembringe den side: oprindelsen afviste anmodningen, forward-proxyen afviste at åbne tunnelen, eller proxyen krævede sine egne legitimationsoplysninger. Hver af dem er et korrekt svar på et forskelligt spørgsmål, og at presse dem sammen til én generisk fejlside ødelægger det eneste bevis, du har. Sortér afvisningen efter den komponent, der lavede den, og sammenlign derefter den netværkssti, hver komponent faktisk bruger.

Navngiv den komponent, der producerede 403

En HTTP-statuskode tilhører den part, der sendte den. Når oprindelsen returnerer 403, har den parset anmodningen og besluttet, at den kaldende muligvis ikke har ressourcen, hvilket er et autorisationssvar og ikke et transportproblem. Når en forward-proxy svarer 403 på et CONNECT, afviste den at bygge tunnelen helt, og intet opstrøms blev nogensinde kontaktet. Når den svarer 407, vil den have sine egne legitimationsoplysninger, som intet har at gøre med applikationens login.

RFC 9110 definerer disse roller, herunder den proxyspecifikke udfordring. Læs svarets egen status og enhver Proxy-Authenticate-header, før du læser bodyen, fordi en venlig HTML-fejlside normalt skjuler, hvilken komponent der skrev den.

Hvad en CONNECT-tunnel skjuler for en byterelay

Når en proxy returnerer 200 på CONNECT, videresender den bytes, og browseren beholder sin egen TLS-session med oprindelsen. En byterelay-proxy kan derfor ikke læse den krypterede 403 inde i den session, og den bliver aldrig forfatter til afvisningen. En afvisning, før tunnelen åbnes, er en helt anden begivenhed, produceret et lag længere nede.

En TLS-terminerende reverse proxy står i en anden position: den ejer TLS-grænsen, parser HTTP og kan legitimt omskrive eller opsnappe svar. Den evne er et konfigurationsvalg, ikke en egenskab ved proxying generelt, og den tillader ikke at omgå applikationens adgangspolitik. At læse svaret er en evne; at afgøre, hvad den kaldende må se, forbliver oprindelsens opgave.

Den praktiske konsekvens er, at du skal vide, hvilken af de tre former du kører, før du fortolker en 403. At tilføje HTTP-inspektionsregler til en stream-proxy giver den ikke synlighed, og at forvente, at en byterelay forklarer en oprindelsesafvisning, sender dig til at lede i den forkerte log.

Sammenlign proxyens udgangssti med browserens tunneladresse

En browser, der er forbundet til en VPN, flytter ikke automatisk en separat proxyserver over på den tunnel. Oprindelsen ser proxyens udgangsadresse, og hvis proxyen stadig forlader gennem den lokale standardrute, ser det beskyttede websted en adresse, den aldrig blev konfigureret til at stole på. Den indre VPN-adresse på bærbaren er usynlig for den oprindelse. Det er den enkelt mest almindelige grund til, at en fungerende tunnel stadig giver en 403 fra et websted, der opfører sig korrekt for alle andre.

Test de to stier hver for sig, så adresserne 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 anmodning viser, hvad oprindelsen svarer på din egen adresse, den anden viser, hvad den svarer på proxyens. Et matchende par 403 peger på oprindelsens autorisationsregler; en 200 efterfulgt af en 403 peger på proxy-stien. Spørg oprindelsens ejer, hvilke kildeadresser regelsættet faktisk tillader, i stedet for at antage, at VPN-puljen er inkluderet.

Test hver grænse med en anmodning, der isolerer den

Isolér proxy-laget ved at bede det om noget, det ikke kan afvise af applikationsmæssige grunde. Et CONNECT til en vært, som proxyen må nå, med output kasseret, fortæller dig, om tunneladgang overhovedet virker.

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 udskriver en 200 for CONNECT og derefter et TLS-håndtryk, er proxyadgangen fin, og den senere 403 kom fra oprindelsen. Hvis det udskriver 407, angiv proxy-legitimationsoplysninger med --proxy-user og gentag, før du drager nogen konklusion om webstedet. Hvis det udskriver 403 på CONNECT-linjen, er proxyens egen tilladelsesliste den grænse, der skal undersøges, og applikationen er ikke involveret.

Hold legitimationsoplysninger ude af shell-historikken og ude af indsatte transskriptioner. En proxyadgangskode, der tastes på en kommandolinje, er synlig for andre lokale brugere, og et opsnappet CONNECT-spor med legitimationsoplysninger er værre end intet spor.

Hold afgørelsen læsbar i stedet for at omskrive siden

Når du ved, hvilken komponent der afviste, skal du bevare det svar. En reverse proxy, der omdøber en oprindelses-403 til en 504-timeout eller erstatter den med en succes-side, skjuler en autorisationsbeslutning bag en tilgængelighedshistorie og sender den næste respondent til det forkerte team. Brugerdefinerede fejlsider er fine, når de beholder status og tilføjer kontekst.

Caching fortjener samme omhu. RFC 9111 regulerer, hvordan delte caches må genbruge svar, og en afvisning produceret for én kaldende må ikke gives videre til en anden, som om det var tilladelse. Hvis afvisningssvar overhovedet gemmes, hold dem private og afgrænsede, og tilføj aldrig en offentlig friskhedsregel blot for at reducere opstrøms trafik.

Afslut med en skriftlig afgørelse, der navngiver komponenten, den status den producerede, og den kildeadresse, oprindelsen så. Registrér den nøjagtige anmodning, de gældende proxyindstillinger og tidspunktet, så den næste rapport kan matches mod de samme beviser i stedet for at blive udledt fra hukommelsen. Den registrering besvarer den næste rapport på sekunder og forhindrer, at den samme 403 igen diagnosticeres som et VPN-nedbrud.