Varför en 403 från en VPN-webbplats inte är ett proxyfel

Användare kopplar från VPN:en, möter en 403 på en intern webbplats och rapporterar att proxyn är trasig. Tre separata saker kan skapa den sidan: ursprunget nekade begäran, vidarebefordringsproxyn vägrade öppna tunneln, eller proxyn krävde sina egna inloggningsuppgifter. Var och en är ett korrekt svar på en annan fråga, och att platta till dem till en enda generisk felsida förstör det enda bevis du har. Sortera nekandet efter komponenten som skapade det och jämför sedan nätverksvägen som varje komponent faktiskt använder.

Namnge komponenten som skapade 403

En HTTP-statuskod tillhör den part som skickade den. När ursprunget returnerar 403 har det tolkat begäran och beslutat att anroparen kanske inte har resursen, vilket är ett auktoriseringssvar och inte ett transportproblem. När en vidarebefordringsproxy svarar 403 på en CONNECT vägrade den bygga tunneln överhuvudtaget, och ingenting uppströms kontaktades någonsin. När den svarar 407 vill den ha sina egna inloggningsuppgifter, som inte har något med applikationens inloggning att göra.

RFC 9110 definierar dessa roller, inklusive den proxyspecifika utmaningen. Läs svarets egen status och eventuell Proxy-Authenticate-rubrik innan du läser brödtexten, eftersom en vänlig HTML-felsida vanligtvis döljer vilken komponent som skrev den.

Vad en CONNECT-tunnel döljer för en byte-relay

När en proxy returnerar 200 på CONNECT vidarebefordrar den byte och webbläsaren behåller sin egen TLS-session med ursprunget. En byte-relay-proxy kan därför inte läsa den krypterade 403 inuti den sessionen, och den blir aldrig författare till nekandet. Ett nekande innan tunneln öppnas är en helt annan händelse, skapad ett lager längre ned.

En TLS-avslutande omvänd proxy står i en annan position: den äger TLS-gränsen, tolkar HTTP och kan legitimt skriva om eller fånga upp svar. Den förmågan är ett konfigurationsval, inte en egenskap hos proxy i allmänhet, och den ger inte rätt att kringgå applikationens åtkomstpolicy. Att läsa svaret är en förmåga; att avgöra vad anroparen får se förblir ursprungets arbete.

Den praktiska konsekvensen är att du måste veta vilken av de tre formerna du kör innan du tolkar en 403. Att lägga till HTTP-inspektionsregler på en strömproxy ger den ingen synlighet, och att förvänta sig att en byte-relay förklarar ett ursprungsnekande skickar dig till fel logg.

Jämför proxyns utgångsväg med webbläsarens tunneladress

En webbläsare ansluten till en VPN flyttar inte automatiskt en separat proxyserver till den tunneln. Ursprunget ser proxyns utgångsadress, och om proxyn fortfarande går ut via den lokala standardvägen ser den skyddade webbplatsen en adress som den aldrig konfigurerades att lita på. Den inre VPN-adressen på laptopen är osynlig för det ursprunget. Detta är den vanligaste anledningen till att en fungerande tunnel fortfarande ger en 403 från en webbplats som beter sig korrekt mot alla andra.

Testa de två vägarna separat så att adresserna inte kan blandas ihop.

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örsta begäran visar vad ursprunget svarar på din egen adress, den andra visar vad det svarar på proxyns. Ett matchande par 403 pekar på ursprungets auktoriseringsregler; en 200 följd av en 403 pekar på proxyvägen. Fråga ursprungets ägare vilka källadresser regeluppsättningen faktiskt tillåter, i stället för att anta att VPN-poolen ingår.

Testa varje gräns med en begäran som isolerar den

Isolera proxylagret genom att be det om något det inte kan neka av applikationsskäl. En CONNECT till en värd som proxyn får nå, med utdata kastad, berättar om tunnelintag överhuvudtaget fungerar.

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'

Om det skriver ut en 200 för CONNECT och sedan ett TLS-handskakning är proxyintaget i ordning och den senare 403 kom från ursprunget. Om det skriver ut 407, ange proxyuppgifter med --proxy-user och upprepa innan du drar någon slutsats om webbplatsen. Om det skriver ut 403 på CONNECT-raden är proxyns egen tillåtelselista gränsen att undersöka, och applikationen är inte inblandad.

Håll inloggningsuppgifter utanför shellhistoriken och utanför inklistrade transkript. Ett proxylösenord som skrivs in på en kommandorad är synligt för andra lokala användare, och ett fångat CONNECT-spår med inloggningsuppgifter är värre än inget spår alls.

Håll avgörandet läsbart i stället för att skriva om sidan

När du vet vilken komponent som nekade, bevara det svaret. En omvänd proxy som byter namn på ett ursprungs-403 till en 504-timeout, eller ersätter det med en framgångssida, döljer ett auktoriseringsbeslut bakom en tillgänglighetsberättelse och skickar nästa svarsperson till fel team. Anpassade felsidor är bra när de behåller statusen och lägger till sammanhang.

Cachning förtjänar samma omsorg. RFC 9111 reglerar hur delade cachar får återanvända svar, och ett nekande som skapats för en anropare får inte lämnas till en annan som om det vore tillstånd. Om nekandesvar alls lagras, håll dem privata och avgränsade, och lägg aldrig till en offentlig färskhetsregel bara för att minska uppströmstrafiken.

Avsluta med ett skriftligt avgörande som namnger komponenten, den status den skapade och den källadress som ursprunget såg. Registrera den exakta begäran, gällande proxyinställningar och tiden, så att nästa rapport kan matchas mot samma bevis i stället för att härledas på nytt från minnet. Den registreringen besvarar nästa rapport på sekunder och hindrar att samma 403 återigen diagnostiseras som ett VPN-avbrott.