Wêrom in 403 fan in VPN-side gjin proxyflater is

Brûkers ferbrekke de VPN, krije in 403 op in ynterne side en melde dat de proxy stikken is. Trije aparte dingen kinne dy side meitsje: de oarsprong wegere it fersyk, de foarútproxy wegere de tunnel te iepenjen, of de proxy easke syn eigen bewizen. Elk fan dy is in goed antwurd op in oare fraach, en se plat te slaan ta ien algemiene flater-side ferneatiget it iennichste bewiis dat jo hawwe. Sortearje de wegering op it ûnderdiel dat him makke hat, en fergelykje dan it netwurkpaad dat elk ûnderdiel eins brûkt.

Nammje it ûnderdiel dat de 403 makke hat

In HTTP-statuskoade heart by de partij dy't him stjoerd hat. As de oarsprong 403 weromstjoert, hat er it fersyk analysearre en besletten dat de oanropper it boarne miskien net hat, wat in autorisaasje-antwurd is en gjin ferfiersprobleem. As in foarútproxy 403 antwurdet op in CONNECT, hat er wegere de tunnel hielendal te bouwen, en neat boppestreams is ea kontakt opnommen. As er 407 antwurdet, wol er syn eigen bewizen, dy't neat te meitsjen hawwe mei de oanmelding fan de applikaasje.

RFC 9110 definiearret dizze rollen, ynklusyf de proxy-spesifike útdaging. Lês de status fan it antwurd sels en elke Proxy-Authenticate-kop foardat jo de lichem lêze, want in freonlike HTML-flaterside ferberget meastentiids hokker ûnderdiel him skreaun hat.

Wat in CONNECT-tunnel ferberget foar in byte-relay

Sadree't in proxy 200 weromstjoert op CONNECT, relayout er bytes en de browser hâldt syn eigen TLS-sesje mei de oarsprong. In byte-relayproxy kin dêrom de fersifere 403 yn dy sesje net lêze, en hy wurdt nea de auteur fan de wegering. In wegering foardat de tunnel iepengiet is in hiel oar barren, makke ien laach leger.

In TLS-beëinigjende omkearde proxy stiet op in oare posysje: hy besit de TLS-grins, analysearret HTTP en kin antwurden rjochtfeardich oerskriuwe of ûnderskeppe. Dy feardigens is in konfiguraasjekar, gjin eigenskip fan proxyjen yn 't algemien, en hy jout gjin tastimming om it tagongsbelied fan de applikaasje te omgean. It antwurd lêze is in feardigens; beslute wat de oanropper sjen mei bliuwt it wurk fan de oarsprong.

De praktyske gefolch is dat jo witte moatte hokker fan de trije foarmen jo draaie foardat jo in 403 ynterpretearje. It tafoegjen fan HTTP-ynspeksjeregels oan in streamproxy jout him gjin sichtberens, en fan in byte-relay ferwachtsje dat er in oarsprong-wegering ferklearret sil jo yn it ferkearde logboek sykje litte.

Fergelykje it útgongspaad fan de proxy mei it tunneladres fan de browser

In browser dy't oan in VPN ferbûn is, ferpleatst net automatysk in aparte proxyserver nei dy tunnel. De oarsprong sjocht it útgongsadres fan de proxy, en as de proxy noch altiten fia de lokale standertrûte fuortgiet, sjocht de beskerme side in adres dêr't er nea op fertrouwe ynsteld wie. It ynterne VPN-adres op de laptop is ûnsichtber foar dy oarsprong. Dit is de iennichste meast foarkommende reden wêrom't in wurkjende tunnel noch altiten in 403 jout fan in side dy't him foar alle oaren goed hâldt.

Test de twa paden apart, sadat de adressen net betize wurde kinne.

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

It earste fersyk lit sjen wat de oarsprong antwurdet foar jo eigen adres, it twadde lit sjen wat er antwurdet foar dat fan de proxy. In byinoar passend pear 403 wiist op de autorisaasjeregels fan de oarsprong; in 200 folge troch in 403 wiist op it proxypaad. Freegje de eigner fan de oarsprong hokker boarneadressen de regelset eins talit, ynstee fan oan te nimmen dat de VPN-pool derby sit.

Test elke grins mei in fersyk dat him isolearret

Isolearje de proxylaach troch him om eat te freegjen dat er om applikaasjeredenen net wegerje kin. In CONNECT nei in host dy't de proxy berikke mei, mei de útfier fuortgoaid, fertelt jo oft tunnel tagong hielendal wurket.

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 dat in 200 foar de CONNECT en dan in TLS-hânskodruk printsje, is proxy-tagong goed en kaam de lettere 403 fan de oarsprong. As it 407 printsjet, jou dan proxy-bewizen mei --proxy-user en werhelje foardat jo in konklúzje oer de side lûke. As it 403 op de CONNECT-rigel printsjet, is de eigen tastimmingslist fan de proxy de grins om te ûndersykjen, en de applikaasje is der net by belutsen.

Hâld bewizen bûten de shell-skiednis en bûten plakte transkripsjes. In proxywachtwurd dat yn in kommando-rigel typt wurdt, is sichtber foar oare lokale brûkers, en in fêstlein CONNECT-spoar mei bewizen is slimmer as hielendal gjin spoar.

Hâld it oardiel lêsber ynstee fan de side oer te skriuwen

Sadree't jo witte hokker ûnderdiel wegere, bewarje dat antwurd. In omkearde proxy dy't in oarsprong-403 omneamt ta in 504-timeout, of him ferfangt troch in suksesside, ferberget in autorisaasjebeslút efter in ferhaal oer beskikberens en stjoert de folgjende reagearder nei it ferkearde team. Oanpaste flatersiden binne goed as se de status hâlde en kontekst tafoegje.

Caching fertsjinnet deselde soarch. RFC 9111 regelet hoe't dielde caches antwurden werbrûke meie, en in wegering makke foar ien oanropper mei net oan in oar jûn wurde as wie it tastimming. As wegeringsantwurden hielendal bewarre wurde, hâld se privee en beheind, en foegje nea in iepenbiere frisheidsregel ta allinnich om boppestreams ferkear te ferminderjen.

Einigje mei in skreaun oardiel dat it ûnderdiel neamt, de status dy't it makke hat, en it boarneadres dat de oarsprong seach. Registrearje it krekte fersyk, de jildende proxy-ynstellingen en de tiid, sadat it folgjende rapport tsjin deselde bewiizen hâlden wurde kin ynstee fan út it ûnthâld op 'e nij ôflaat te wurden. Dat register beantwurdet it folgjende rapport yn sekonden en stopet dat deselde 403 wer as in VPN-útfal diagnostisearre wurdt.