Proč 403 z webu VPN není selhání proxy
403 od původu, odmítnutý CONNECT a výzva 407 označují různé hranice. Nejprve porovnejte výstupní cestu proxy s adresou VPN v prohlížeči.
Uživatelé odpojí VPN, narazí na 403 na interním webu a hlásí, že proxy je rozbitá. Tu stránku mohou vytvořit tři oddělené věci: původ odmítl požadavek, dopředná proxy odmítla otevřít tunel nebo proxy vyžadovala vlastní přihlašovací údaje. Každá z nich je správnou odpovědí na jinou otázku a jejich sloučení do jedné obecné stránky selhání ničí jediný důkaz, který máte. Roztřiďte odmítnutí podle komponenty, která ho vytvořila, a poté porovnejte síťovou cestu, kterou každá komponenta skutečně používá.
Pojmenujte komponentu, která vytvořila 403
Stavový kód HTTP patří straně, která ho odeslala. Když původ vrátí 403, zpracoval požadavek a rozhodl, že volající možná nemá prostředek, což je odpověď o autorizaci, nikoli problém přenosu. Když dopředná proxy odpoví 403 na CONNECT, odmítla tunel vůbec postavit a nic výše po proudu nebylo kontaktováno. Když odpoví 407, chce vlastní přihlašovací údaje, které nemají nic společného s přihlášením do aplikace.
| 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 tyto role včetně výzvy specifické pro proxy. Přečtěte si vlastní stav odpovědi a případnou hlavičku Proxy-Authenticate dříve než tělo, protože přátelská HTML chybová stránka obvykle skrývá, která komponenta ji napsala.
Co tunel CONNECT skrývá před přeposíláním bajtů
Jakmile proxy vrátí na CONNECT 200, přeposílá bajty a prohlížeč si udržuje vlastní relaci TLS s původem. Proxy přeposílající bajty proto nemůže přečíst šifrované 403 uvnitř této relace a nikdy se nestane autorem odmítnutí. Odmítnutí před otevřením tunelu je zcela jiná událost, vytvořená o vrstvu níž.
Reverzní proxy ukončující TLS je v jiné pozici: vlastní hranici TLS, analyzuje HTTP a může legitimně přepisovat nebo zachytávat odpovědi. Tato schopnost je volba konfigurace, nikoli vlastnost proxy obecně, a neopravňuje obcházet přístupovou politiku aplikace. Číst odpověď je schopnost; rozhodovat, co volající smí vidět, zůstává úkolem původu.
Praktickým důsledkem je, že musíte vědět, který ze tří tvarů provozujete, než 403 vyložíte. Přidání pravidel pro HTTP inspekci k proudové proxy jí nedává viditelnost a očekávání, že přeposílání bajtů vysvětlí odmítnutí původu, vás pošle do špatného logu.
Porovnejte výstupní cestu proxy s adresou tunelu prohlížeče
Prohlížeč připojený k VPN automaticky nepřesune samostatný proxy server do tohoto tunelu. Původ vidí výstupní adresu proxy, a pokud proxy stále vychází přes místní výchozí trasu, chráněný web vidí adresu, které se nikdy nenastavilo, aby jí důvěřoval. Vnitřní adresa VPN na notebooku je pro tento původ neviditelná. To je nejčastější důvod, proč funkční tunel stále dává 403 z webu, který se ke všem ostatním chová správně.
Otestujte obě cesty odděleně, aby se adresy nemohly zaměnit.
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/privatePrvní požadavek ukazuje, co původ odpovídá na vaši vlastní adresu, druhý, co odpovídá na adresu proxy. Shodná dvojice 403 ukazuje na autorizační pravidla původu; 200 následované 403 ukazuje na cestu proxy. Zeptejte se vlastníka původu, které zdrojové adresy sada pravidel skutečně připouští, místo abyste předpokládali, že je zahrnut fond VPN.
Otestujte každou hranici požadavkem, který ji izoluje
Izolujte vrstvu proxy tím, že ji požádáte o něco, co nemůže odmítnout z aplikačních důvodů. CONNECT k hostiteli, kam proxy smí dosáhnout, s odhozeným výstupem vám řekne, zda přijetí tunelu 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'
Pokud to vypíše 200 pro CONNECT a potom TLS handshake, přijetí proxy je v pořádku a pozdější 403 přišlo od původu. Pokud vypíše 407, dodajte přihlašovací údaje proxy pomocí --proxy-user a opakujte, než uděláte jakýkoli závěr o webu. Pokud vypíše 403 na řádku CONNECT, vlastní seznam povolených proxy je hranice k prozkoumání a aplikace do toho nevstupuje.
Udržujte přihlašovací údaje mimo historii shellu a mimo vložené přepisy. Heslo proxy napsané do příkazového řádku je viditelné pro ostatní místní uživatele a zachycený záznam CONNECT s přihlašovacími údaji je horší než žádný záznam.
Udržujte verdikt čitelný, místo abyste stránku přepisovali
Jakmile víte, která komponenta odmítla, zachovejte tu odpověď. Reverzní proxy, která původní 403 přeznačí na časový limit 504 nebo ji nahradí stránkou úspěchu, skrývá rozhodnutí o autorizaci za příběhem dostupnosti a posílá dalšího respondéra ke špatnému týmu. Vlastní chybové stránky jsou v pořádku, když zachovají stav a přidají kontext.
Kešování si zaslouží stejnou péči. RFC 9111 upravuje, jak sdílené keše mohou znovu používat odpovědi, a odmítnutí vytvořené pro jednoho volajícího se nesmí předat jinému, jako by to bylo povolení. Pokud se odmítavé odpovědi vůbec ukládají, udržujte je soukromé a omezené a nikdy nepřidávejte veřejné pravidlo svěžesti jen proto, abyste snížili provoz proti proudu.
Skončete písemným verdiktem, který pojmenuje komponentu, stav, který vytvořila, a zdrojovou adresu, kterou původ viděl. Zaznamenejte přesný požadavek, platná nastavení proxy a čas, aby šlo příští hlášení porovnat se stejnými důkazy místo znovuodvozování z paměti. Ten záznam odpoví na příští hlášení během sekund a zabrání tomu, aby se stejná 403 znovu diagnostikovala jako výpadek VPN.