Waarom een 403 van een VPN-site geen proxyfout is
Een 403 van de origin, een geweigerde CONNECT en een 407-uitdaging markeren verschillende grenzen. Vergelijk eerst het uitgangspad van de proxy met het VPN-adres van de browser.
Gebruikers verbreken de VPN, krijgen een 403 op een interne site en melden dat de proxy kapot is. Drie afzonderlijke dingen kunnen die pagina veroorzaken: de origin weigerde het verzoek, de forward-proxy weigerde de tunnel te openen, of de proxy eiste zijn eigen inloggegevens. Elk daarvan is een juist antwoord op een andere vraag, en ze plat slaan tot één generieke foutpagina vernietigt het enige bewijs dat je hebt. Sorteer de weigering op de component die hem heeft gemaakt en vergelijk daarna het netwerkpad dat elke component werkelijk gebruikt.
Benoem de component die de 403 heeft veroorzaakt
Een HTTP-statuscode hoort bij de partij die hem heeft verzonden. Wanneer de origin 403 retourneert, heeft hij het verzoek geparseerd en besloten dat de aanroeper de bron mogelijk niet heeft, wat een autorisatieantwoord is en geen transportprobleem. Wanneer een forward-proxy 403 antwoordt op een CONNECT, weigerde hij de tunnel überhaupt te bouwen, en niets stroomopwaarts werd ooit gecontacteerd. Wanneer hij 407 antwoordt, wil hij zijn eigen inloggegevens, die niets met de aanmelding van de applicatie te maken hebben.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 definieert deze rollen, inclusief de proxyspecifieke uitdaging. Lees de eigen status van het antwoord en elke Proxy-Authenticate-header voordat je de body leest, want een vriendelijke HTML-foutpagina verbergt meestal welke component hem heeft geschreven.
Wat een CONNECT-tunnel verbergt voor een byterelay
Zodra een proxy 200 retourneert op CONNECT, stuurt hij bytes door en de browser houdt zijn eigen TLS-sessie met de origin. Een byterelay-proxy kan de versleutelde 403 in die sessie dus niet lezen, en hij wordt nooit de auteur van de weigering. Een weigering voordat de tunnel opengaat is een volledig andere gebeurtenis, geproduceerd een laag lager.
Een TLS-beëindigende reverse proxy staat op een andere positie: hij bezit de TLS-grens, parseert HTTP en kan antwoorden legitiem herschrijven of onderscheppen. Die mogelijkheid is een configuratiekeuze, geen eigenschap van proxyen in het algemeen, en zij machtigt niet tot het omzeilen van het toegangsbeleid van de applicatie. Het antwoord lezen is een mogelijkheid; beslissen wat de aanroeper mag zien blijft het werk van de origin.
De praktische consequentie is dat je moet weten welke van de drie vormen je draait voordat je een 403 interpreteert. HTTP-inspectieregels toevoegen aan een streamproxy geeft hem geen zichtbaarheid, en van een byterelay verwachten dat hij een origin-weigering verklaart, stuurt je naar het verkeerde logboek.
Vergelijk het uitgangspad van de proxy met het tunneladres van de browser
Een browser die met een VPN is verbonden, verplaatst niet automatisch een aparte proxyserver naar die tunnel. De origin ziet het uitgangsadres van de proxy, en als de proxy nog steeds via de lokale standaardroute vertrekt, ziet de beschermde site een adres dat nooit is geconfigureerd om te vertrouwen. Het interne VPN-adres op de laptop is onzichtbaar voor die origin. Dit is de meest voorkomende reden dat een werkende tunnel nog steeds een 403 oplevert van een site die zich voor alle anderen correct gedraagt.
Test de twee paden afzonderlijk zodat de adressen niet kunnen worden verward.
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/privateHet eerste verzoek toont wat de origin antwoordt voor je eigen adres, het tweede wat hij antwoordt voor dat van de proxy. Een overeenkomend paar 403 wijst op de autorisatieregels van de origin; een 200 gevolgd door een 403 wijst op het proxypad. Vraag de eigenaar van de origin welke bronadressen de regelset werkelijk toelaat, in plaats van aan te nemen dat de VPN-pool is inbegrepen.
Test elke grens met een verzoek dat hem isoleert
Isoleer de proxylaag door hem iets te vragen dat hij om applicatieredenen niet kan weigeren. Een CONNECT naar een host die de proxy mag bereiken, met de uitvoer weggegooid, vertelt je of tunneltoegang überhaupt werkt.
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'
Als dat een 200 voor de CONNECT en daarna een TLS-handshake afdrukt, is de proxytoegang in orde en kwam de latere 403 van de origin. Als het 407 afdrukt, geef proxy-inloggegevens op met --proxy-user en herhaal voordat je enige conclusie over de site trekt. Als het 403 op de CONNECT-regel afdrukt, is de eigen toelatingslijst van de proxy de grens die moet worden onderzocht, en de applicatie is niet betrokken.
Houd inloggegevens buiten de shell-geschiedenis en buiten geplakte transcripten. Een proxypaswoord dat in een opdrachtregel wordt getypt, is zichtbaar voor andere lokale gebruikers, en een vastgelegd CONNECT-spoor met inloggegevens is erger dan helemaal geen spoor.
Houd het oordeel leesbaar in plaats van de pagina te herschrijven
Zodra je weet welke component weigerde, bewaar dat antwoord. Een reverse proxy die een origin-403 hernoemt tot een 504-time-out, of hem vervangt door een succespagina, verbergt een autorisatiebeslissing achter een beschikbaarheidsverhaal en stuurt de volgende reageerder naar het verkeerde team. Aangepaste foutpagina's zijn prima wanneer ze de status behouden en context toevoegen.
Caching verdient dezelfde zorg. RFC 9111 regelt hoe gedeelde caches antwoorden mogen hergebruiken, en een weigering die voor de ene aanroeper is gemaakt, mag niet aan een andere worden gegeven alsof het toestemming was. Als weigeringsantwoorden überhaupt worden opgeslagen, houd ze dan privé en begrensd, en voeg nooit een openbare versheidsregel toe alleen om upstreamverkeer te verminderen.
Sluit af met een schriftelijk oordeel dat de component, de geproduceerde status en het bronadres dat de origin zag benoemt. Leg het exacte verzoek, de geldende proxyinstellingen en de tijd vast, zodat het volgende rapport tegen hetzelfde bewijs kan worden gelegd in plaats van opnieuw uit het geheugen te worden afgeleid. Dat verslag beantwoordt het volgende rapport in seconden en voorkomt dat dezelfde 403 opnieuw als VPN-storing wordt gediagnosticeerd.