Prečo 403 z webu VPN nie je zlyhanie proxy
403 od pôvodu, odmietnutý CONNECT a výzva 407 označujú rôzne hranice. Najprv porovnajte výstupnú cestu proxy s adresou VPN v prehliadači.
Používatelia odpoja VPN, narazia na 403 na internom webe a hlásia, že proxy je pokazená. Tú stránku môžu vytvoriť tri oddelené veci: pôvod odmietol požiadavku, dopredná proxy odmietla otvoriť tunel alebo proxy žiadala vlastné prihlasovacie údaje. Každá z nich je správnou odpoveďou na inú otázku a ich zlúčenie do jednej všeobecnej stránky zlyhania ničí jediný dôkaz, ktorý máte. Roztrieďte odmietnutie podľa komponentu, ktorý ho vytvoril, a potom porovnajte sieťovú cestu, ktorú každý komponent skutočne používa.
Pomenujte komponent, ktorý vytvoril 403
Stavový kód HTTP patrí strane, ktorá ho odoslala. Keď pôvod vráti 403, spracoval požiadavku a rozhodol, že volajúci možno nemá prostriedok, čo je odpoveď o autorizácii, nie problém prenosu. Keď dopredná proxy odpovie 403 na CONNECT, odmietla tunel vôbec postaviť a nič vyššie po prúde nebolo kontaktované. Keď odpovie 407, chce vlastné prihlasovacie údaje, ktoré nemajú nič spoločné s prihlásením do aplikácie.
| 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 definuje tieto roly vrátane výzvy špecifickej pre proxy. Prečítajte si vlastný stav odpovede a prípadnú hlavičku Proxy-Authenticate pred telom, pretože priateľská HTML chybová stránka zvyčajne skrýva, ktorý komponent ju napísal.
Čo tunel CONNECT skrýva pred prepisovaním bajtov
Keď proxy vráti na CONNECT 200, prepisuje bajty a prehliadač si udržiava vlastnú reláciu TLS s pôvodom. Proxy prepisujúca bajty preto nemôže prečítať šifrované 403 v tejto relácii a nikdy sa nestane autorom odmietnutia. Odmietnutie pred otvorením tunela je úplne iná udalosť, vytvorená o vrstvu nižšie.
Reverzná proxy ukončujúca TLS je v inej pozícii: vlastní hranicu TLS, analyzuje HTTP a môže legitímne prepisovať alebo zachytávať odpovede. Táto schopnosť je voľba konfigurácie, nie vlastnosť proxy všeobecne, a neoprávňuje obchádzať prístupovú politiku aplikácie. Čítať odpoveď je schopnosť; rozhodovať, čo volajúci smie vidieť, zostáva úlohou pôvodu.
Praktickým dôsledkom je, že musíte vedieť, ktorý z troch tvarov prevádzkujete, skôr než 403 vyložíte. Pridanie pravidiel HTTP inšpekcie k prúdovej proxy jej nedáva viditeľnosť a očakávanie, že prepisovanie bajtov vysvetlí odmietnutie pôvodu, vás pošle do nesprávneho logu.
Porovnajte výstupnú cestu proxy s adresou tunela prehliadača
Prehliadač pripojený k VPN automaticky nepresunie samostatný proxy server do tohto tunela. Pôvod vidí výstupnú adresu proxy, a ak proxy stále vychádza cez miestnu predvolenú trasu, chránený web vidí adresu, ktorej sa nikdy nenastavilo dôverovať. Vnútorná adresa VPN na notebooku je pre tento pôvod neviditeľná. To je najčastejší dôvod, prečo funkčný tunel stále dáva 403 z webu, ktorý sa voči všetkým ostatným správa správne.
Otestujte obe cesty oddelene, aby sa adresy nemohli zameniť.
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/privatePrvá požiadavka ukazuje, čo pôvod odpovedá na vašu vlastnú adresu, druhá, čo odpovedá na adresu proxy. Zhodná dvojica 403 ukazuje na autorizačné pravidlá pôvodu; 200 nasledované 403 ukazuje na cestu proxy. Spýtajte sa vlastníka pôvodu, ktoré zdrojové adresy sada pravidiel skutočne pripúšťa, namiesto toho, aby ste predpokladali, že fond VPN je zahrnutý.
Otestujte každú hranicu požiadavkou, ktorá ju izoluje
Izolujte vrstvu proxy tým, že ju požiadate o niečo, čo nemôže odmietnuť z aplikačných dôvodov. CONNECT k hostiteľovi, kam proxy smie dosiahnuť, s odhodeným výstupom vám povie, či prijatie tunela vôbec funguje.
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'
Ak to vypíše 200 pre CONNECT a potom TLS handshake, prijatie proxy je v poriadku a neskoršie 403 prišlo od pôvodu. Ak vypíše 407, dodajte prihlasovacie údaje proxy pomocou --proxy-user a zopakujte, než urobíte akýkoľvek záver o webe. Ak vypíše 403 na riadku CONNECT, vlastný zoznam povolených proxy je hranica na preskúmanie a aplikácia do toho nevstupuje.
Udržujte prihlasovacie údaje mimo histórie shellu a mimo vložených prepisov. Heslo proxy napísané do príkazového riadku je viditeľné pre ostatných miestnych používateľov a zachytená stopa CONNECT s prihlasovacími údajmi je horšia ako žiadna stopa.
Udržujte verdikt čitateľný, namiesto prepisovania stránky
Keď viete, ktorý komponent odmietol, zachovajte tú odpoveď. Reverzná proxy, ktorá premenuje pôvodné 403 na časový limit 504 alebo ho nahradí stránkou úspechu, skrýva rozhodnutie o autorizácii za príbehom dostupnosti a posiela ďalšieho respondéra do nesprávneho tímu. Vlastné chybové stránky sú v poriadku, keď zachovajú stav a pridajú kontext.
Kešovanie si zaslúži rovnakú starostlivosť. RFC 9111 upravuje, ako môžu zdieľané keše opätovne používať odpovede, a odmietnutie vytvorené pre jedného volajúceho sa nesmie odovzdať inému, akoby to bolo povolenie. Ak sa odmietavé odpovede vôbec ukladajú, udržujte ich súkromné a obmedzené a nikdy nepridávajte verejné pravidlo sviežosti len preto, aby ste znížili prevádzku proti prúdu.
Skončite písomným verdiktom, ktorý pomenuje komponent, stav, ktorý vytvoril, a zdrojovú adresu, ktorú pôvod videl. Zaznamenajte presnú požiadavku, platné nastavenia proxy a čas, aby sa ďalšie hlásenie dalo porovnať s tými istými dôkazmi namiesto opätovného odvodzovania z pamäti. Ten záznam odpovie na ďalšie hlásenie v sekundách a zabráni tomu, aby sa rovnaká 403 znova diagnostikovala ako výpadok VPN.