Zakaj 403 s spletnega mesta VPN ni okvara proxyja
403 od izvora, zavrnjen CONNECT in izziv 407 označujejo različne meje. Najprej primerjajte izhodno pot proxyja z naslovom VPN v brskalniku.
Uporabniki prekinejo VPN, naletijo na 403 na notranjem spletnem mestu in poročajo, da je proxy pokvarjen. To stran lahko ustvarijo tri ločene stvari: izvor je zavrnil zahtevo, posredniški proxy je zavrnil odpiranje tunela ali pa je proxy zahteval svoje poverilnice. Vsaka od njih je pravilen odgovor na drugo vprašanje, in njihovo sploščitev v eno splošno stran napake uniči edini dokaz, ki ga imate. Razvrstite zavrnitev po komponenti, ki jo je ustvarila, nato primerjajte omrežno pot, ki jo vsaka komponenta dejansko uporablja.
Poimenujte komponento, ki je ustvarila 403
Koda stanja HTTP pripada strani, ki jo je poslala. Ko izvor vrne 403, je zahtevo razčlenil in odločil, da klicatelj morda nima vira, kar je odgovor o avtorizaciji in ne težava prevoza. Ko posredniški proxy odgovori 403 na CONNECT, je zavrnil gradnjo tunela sploh, in nič višje ni bilo nikoli kontaktirano. Ko odgovori 407, želi svoje poverilnice, ki nimajo nič skupnega s prijavo v aplikacijo.
| 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 opredeljuje te vloge, vključno z izzivom, specifičnim za proxy. Preberite lastno stanje odgovora in vsako glavo Proxy-Authenticate, preden preberete telo, ker prijazna stran napake HTML običajno skriva, katera komponenta jo je napisala.
Kaj tunel CONNECT skriva pred posredovanjem bajtov
Ko proxy vrne 200 na CONNECT, posreduje bajte in brskalnik ohrani svojo sejo TLS z izvorom. Proxy, ki posreduje bajte, zato ne more prebrati šifriranega 403 v tej seji in nikoli ne postane avtor zavrnitve. Zavrnitev pred odprtjem tunela je povsem drug dogodek, ustvarjen eno plast nižje.
Povratni proxy, ki zaključi TLS, je v drugem položaju: ima mejo TLS, razčlenjuje HTTP in lahko zakonito prepisuje ali prestreza odgovore. Ta zmožnost je izbira konfiguracije, ne lastnost proxyja na splošno, in ne dovoljuje obhoda politike dostopa aplikacije. Branje odgovora je zmožnost; odločitev, kaj sme klicatelj videti, ostaja delo izvora.
Praktična posledica je, da morate vedeti, katero od treh oblik izvajate, preden razložite 403. Dodajanje pravil za HTTP-inšpekcijo pretočnemu proxyju ne daje vidnosti, in pričakovanje, da bo posredovanje bajtov pojasnilo zavrnitev izvora, vas pošlje v napačen dnevnik.
Primerjajte izhodno pot proxyja z naslovom tunela brskalnika
Brskalnik, povezan z VPN, samodejno ne premakne ločenega strežnika proxy v ta tunel. Izvor vidi izhodni naslov proxyja, in če proxy še vedno izhaja po lokalni privzeti poti, zaščiteno mesto vidi naslov, ki mu nikoli ni bilo nastavljeno zaupanje. Notranji naslov VPN na prenosniku je za ta izvor neviden. To je najpogostejši razlog, da delujoč tunel še vedno daje 403 s spletnega mesta, ki se do vseh drugih obnaša pravilno.
Preizkusite obe poti ločeno, da naslovov ne bo mogoče zamenjati.
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/privatePrva zahteva pokaže, kaj izvor odgovarja na vaš naslov, druga, kaj odgovarja na naslov proxyja. Ujemajoči se par 403 kaže na pravila avtorizacije izvora; 200, ki mu sledi 403, kaže na pot proxyja. Vprašajte lastnika izvora, katere izvorne naslove nabor pravil dejansko dopušča, namesto da predpostavljate, da je skupina VPN vključena.
Preizkusite vsako mejo z zahtevo, ki jo izolira
Izolirajte plast proxyja tako, da ga prosite za nekaj, česar ne more zavrniti iz aplikacijskih razlogov. CONNECT do gostitelja, do katerega proxy sme priti, z zavrženim izhodom, vam pove, ali sprejem v tunel sploh deluje.
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'
Če to izpiše 200 za CONNECT in nato rokovanje TLS, je sprejem proxyja v redu in poznejši 403 je prišel od izvora. Če izpiše 407, navedite poverilnice proxyja z --proxy-user in ponovite, preden naredite kakršen koli sklep o spletnem mestu. Če izpiše 403 v vrstici CONNECT, je lastni seznam dovoljenih proxyja meja, ki jo je treba preučiti, in aplikacija ni vpletena.
Hranite poverilnice zunaj zgodovine lupine in zunaj prilepljenih prepisov. Geslo proxyja, vtipkano v ukazno vrstico, je vidno drugim lokalnim uporabnikom, in zajeta sled CONNECT s poverilnicami je slabša od nobene sledi.
Ohranite sodbo berljivo, namesto da bi prepisali stran
Ko veste, katera komponenta je zavrnila, ohranite ta odgovor. Povratni proxy, ki izvorni 403 preimenuje v časovno omejitev 504 ali ga nadomesti s stranjo uspeha, skrije odločitev o avtorizaciji za zgodbo o razpoložljivosti in pošlje naslednjega odzivnika v napačno ekipo. Strani napak po meri so v redu, ko ohranijo stanje in dodajo kontekst.
Predpomnjenje si zasluži enako skrb. RFC 9111 ureja, kako lahko skupni predpomnilniki ponovno uporabijo odgovore, in zavrnitve, ustvarjene za enega klicatelja, se ne smejo izročiti drugemu, kot da bi bila dovoljenje. Če se odgovori o zavrnitvi sploh shranjujejo, jih hranite zasebne in omejene, in nikoli ne dodajte javnega pravila svežine samo zato, da bi zmanjšali promet navzgor.
Zaključite s pisno sodbo, ki poimenuje komponento, stanje, ki ga je ustvarila, in izvorni naslov, ki ga je videl izvor. Zabeležite natančno zahtevo, veljavne nastavitve proxyja in čas, da bo naslednje poročilo mogoče primerjati z istimi dokazi, namesto da bi ga znova izpeljali iz spomina. Ta zapis odgovori na naslednje poročilo v sekundah in prepreči, da bi isto 403 znova diagnosticirali kot izpad VPN.