Waarom 'n 403 van 'n VPN-werf nie 'n proxy-fout is nie

Gebruikers ontkoppel die VPN, kry 'n 403 op 'n interne werf en rapporteer dat die proxy stukkend is. Drie afsonderlike dinge kan daardie bladsy lewer: die oorsprong het die versoek geweier, die voorwaartse proxy het geweier om die tonnel oop te maak, of die proxy het sy eie geloofsbriewe geëis. Elkeen is 'n korrekte antwoord op 'n ander vraag, en om hulle tot een generiese foutbladsy plat te slaan, vernietig die enigste bewys wat jy het. Sorteer die weiering volgens die komponent wat dit gemaak het en vergelyk dan die netwerkpad wat elke komponent werklik gebruik.

Noem die komponent wat die 403 opgelewer het

'n HTTP-statuskode behoort aan die party wat dit gestuur het. Wanneer die oorsprong 403 terugstuur, het dit die versoek ontleed en besluit die oproeper mag dalk nie die hulpbron hê nie, wat 'n magtigingsantwoord eerder as 'n vervoerprobleem is. Wanneer 'n voorwaartse proxy 403 op 'n CONNECT antwoord, het dit geweier om die tonnel hoegenaamd te bou, en niks stroomop is ooit gekontak nie. Wanneer dit 407 antwoord, wil dit sy eie geloofsbriewe hê, wat niks met die toepassing se aanmelding te doen het nie.

RFC 9110 definieer hierdie rolle, insluitend die proxy-spesifieke uitdaging. Lees die antwoord se eie status en enige Proxy-Authenticate-kop voordat jy die liggaam lees, want 'n vriendelike HTML-foutbladsy verberg gewoonlik watter komponent dit geskryf het.

Wat 'n CONNECT-tonnel vir 'n grefoorsending verberg

Sodra 'n proxy 200 op CONNECT terugstuur, stuur dit grepe deur en die blaaier hou sy eie TLS-sessie met die oorsprong. 'n Grepe-deursturende proxy kan dus nie die versleutelde 403 binne daardie sessie lees nie, en dit word nooit die skrywer van die weiering nie. 'n Weiering voordat die tonnel oopgaan, is 'n heeltemal ander gebeurtenis wat een laag laer geproduseer word.

'n TLS-beëindigende omgekeerde proxy staan in 'n ander posisie: dit besit die TLS-grens, ontleed HTTP en kan antwoorde wettig herskryf of onderskep. Daardie vermoë is 'n konfigurasiekeuse, nie 'n eienskap van proxy in die algemeen nie, en dit magtig nie die omseiling van die toepassing se toegangsbeleid nie. Om die antwoord te lees is 'n vermoë; om te besluit wat die oproeper mag sien, bly die oorsprong se werk.

Die praktiese gevolg is dat jy moet weet watter van die drie vorms jy bedryf voordat jy 'n 403 interpreteer. Om HTTP-inspeksiereëls by 'n stroomproxy te voeg, gee dit nie sigbaarheid nie, en om van 'n grefoorsending te verwag om 'n oorsprong-weiering te verduidelik, sal jou in die verkeerde log laat kyk.

Vergelyk die proxy se uitgangspad met die blaaier se tonneladres

'n Blaaier wat aan 'n VPN gekoppel is, skuif nie outomaties 'n aparte proxyserver op daardie tonnel nie. Die oorsprong sien die proxy se uitgangsadres, en as die proxy steeds deur die plaaslike verstekroete vertrek, sien die beskermde werf 'n adres wat dit nooit vertrou het nie. Die innerlike VPN-adres op die skootrekenaar is onsigbaar vir daardie oorsprong. Dit is die enkele mees algemene rede waarom 'n werkende tonnel steeds 'n 403 lewer van 'n werf wat vir almal anders korrek optree.

Toets die twee paaie afsonderlik sodat die adresse nie verwar kan word nie.

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

Die eerste versoek wys wat die oorsprong vir jou eie adres antwoord, die tweede wys wat dit vir die proxy s'n antwoord. 'n Passende paar 403's dui op die oorsprong se magtigingsreëls; 'n 200 gevolg deur 'n 403 dui op die proxypad. Vra die oorsprong-eienaar watter bronadresse die reëlstel werklik toelaat eerder as om aan te neem die VPN-poel is ingesluit.

Toets elke grens met 'n versoek wat dit isoleer

Isoleer die proxylaag deur dit te vra vir iets wat dit om toepassingsredes nie kan weier nie. 'n CONNECT na 'n gasheer wat die proxy mag bereik, met uitset weggegooi, vertel jou of tonneltoelating hoegenaamd werk.

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'

As dit 'n 200 vir die CONNECT en dan 'n TLS-handdruk druk, is proxytoelating reg en die latere 403 het van die oorsprong gekom. As dit 407 druk, voorsien proxy-geloofsbriewe met --proxy-user en herhaal voordat jy enige gevolgtrekking oor die werf maak. As dit 403 op die CONNECT-reël druk, is die proxy se eie toelatingslys die grens om te ondersoek, en die toepassing is nie betrokke nie.

Hou geloofsbriewe uit die dopgeskiedenis en uit geplakte transkripsies. 'n Proxy-wagwoord wat in 'n opdragreël getik word, is sigbaar vir ander plaaslike gebruikers, en 'n vasgevangde CONNECT-spoor met geloofsbriewe is slegter as geen spoor nie.

Hou die uitspraak leesbaar eerder as om die bladsy te herskryf

Sodra jy weet watter komponent geweier het, bewaar daardie antwoord. 'n Omgekeerde proxy wat 'n oorsprong-403 as 'n 504-tydsverloop herbenoem, of dit deur 'n suksesbladsy vervang, verberg 'n magtigingsbeslissing agter 'n beskikbaarheidstorie en stuur die volgende reageerder na die verkeerde span. Pasgemaakte foutbladsye is reg wanneer hulle die status behou en konteks byvoeg.

Kasberging verdien dieselfde sorg. RFC 9111 bepaal hoe gedeelde kasreuse antwoorde mag hergebruik, en 'n weiering wat vir een oproeper geskep is, mag nie aan 'n ander gegee word asof dit toestemming was nie. As weieringsantwoorde hoegenaamd gestoor word, hou hulle privaat en beperk, en voeg nooit 'n publieke varsheidsreël by net om stroomopverkeer te verminder nie.

Sluit af met 'n geskrewe uitspraak wat die komponent noem, die status wat dit opgelewer het, en die bronadres wat die oorsprong gesien het. Teken die presiese versoek, die proxy-instellings wat geld, en die tyd aan, sodat die volgende verslag teen dieselfde bewyse gepas kan word eerder as om uit die geheue herlei te word. Daardie rekord beantwoord die volgende verslag in sekondes en keer dat dieselfde 403 weer as 'n VPN-onderbreking gediagnoseer word.