Kodėl 403 iš VPN svetainės nėra tarpinio serverio gedimas

Vartotojai atjungia VPN, vidinėje svetainėje gauna 403 ir praneša, kad tarpinis serveris sugedęs. Tą puslapį gali sukurti trys atskiri dalykai: šaltinis atmetė užklausą, pirminis tarpinis serveris atsisakė atidaryti tunelį arba tarpinis serveris pareikalavo savo prisijungimo duomenų. Kiekvienas jų yra teisingas atsakymas į kitą klausimą, o jų suplokštinimas į vieną bendrą gedimo puslapį sunaikina vienintelį įrodymą, kurį turite. Surikiuokite atmetimą pagal komponentą, kuris jį sukūrė, tada palyginkite tinklo kelią, kurį kiekvienas komponentas iš tikrųjų naudoja.

Įvardykite komponentą, kuris sukūrė 403

HTTP būsenos kodas priklauso šaliai, kuri jį išsiuntė. Kai šaltinis grąžina 403, jis išanalizavo užklausą ir nusprendė, kad kvietėjas gali neturėti ištekliaus, o tai yra autorizacijos atsakymas, o ne transporto problema. Kai pirminis tarpinis serveris atsako 403 į CONNECT, jis atsisakė apskritai statyti tunelį, ir niekas aukščiau nebuvo susisiektas. Kai jis atsako 407, jis nori savo prisijungimo duomenų, kurie neturi nieko bendra su programos prisijungimu.

RFC 9110 apibrėžia šiuos vaidmenis, įskaitant tarpiniam serveriui būdingą iššūkį. Prieš skaitydami turinį perskaitykite paties atsakymo būseną ir bet kurią Proxy-Authenticate antraštę, nes draugiškas HTML klaidos puslapis paprastai paslepia, kuris komponentas jį parašė.

Ką CONNECT tunelis slepia nuo baitų retransliatoriaus

Kai tarpinis serveris grąžina 200 į CONNECT, jis retransliuoja baitus, o naršyklė palaiko savo TLS sesiją su šaltiniu. Todėl baitus retransliuojantis tarpinis serveris negali perskaityti užšifruoto 403 toje sesijoje ir niekada netampa atmetimo autoriumi. Atmetimas prieš atidarant tunelį yra visiškai kitas įvykis, sukuriamas vienu sluoksniu žemiau.

TLS užbaigiantis atvirkštinis tarpinis serveris yra kitoje padėtyje: jam priklauso TLS riba, jis analizuoja HTTP ir gali teisėtai perrašyti ar perimti atsakymus. Tas gebėjimas yra konfigūracijos pasirinkimas, o ne bendra tarpinio serverio savybė, ir jis nesuteikia teisės apeiti programos prieigos politikos. Atsakymo skaitymas yra gebėjimas; sprendimas, ką kvietėjas gali matyti, lieka šaltinio darbu.

Praktinė pasekmė: prieš interpretuodami 403 turite žinoti, kurią iš trijų formų naudojate. HTTP patikros taisyklių pridėjimas prie srauto tarpinio serverio nesuteikia jam matomumo, o tikėjimasis, kad baitų retransliatorius paaiškins šaltinio atmetimą, nukreips jus į netinkamą žurnalą.

Palyginkite tarpinio serverio išėjimo kelią su naršyklės tunelio adresu

Prie VPN prijungta naršyklė automatiškai neperkelia atskiro tarpinio serverio į tą tunelį. Šaltinis mato tarpinio serverio išėjimo adresą, o jei tarpinis serveris vis dar išeina vietiniu numatytuoju maršrutu, apsaugota svetainė mato adresą, kuriuo niekada nebuvo konfigūruota pasitikėti. Nešiojamojo kompiuterio vidinis VPN adresas tam šaltiniui nematomas. Tai dažniausia priežastis, kodėl veikiantis tunelis vis tiek duoda 403 iš svetainės, kuri visiems kitiems elgiasi teisingai.

Tikrinkite abu kelius atskirai, kad adresai nesumaišytų.

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

Pirmoji užklausa rodo, ką šaltinis atsako į jūsų pačių adresą, antroji rodo, ką jis atsako į tarpinio serverio adresą. Sutampanti 403 pora nurodo šaltinio autorizacijos taisykles; 200, po kurio seka 403, nurodo tarpinio serverio kelią. Paklauskite šaltinio savininko, kuriuos šaltinio adresus taisyklių rinkinys iš tikrųjų priima, o ne manykite, kad VPN telkinys įtrauktas.

Tikrinkite kiekvieną ribą užklausa, kuri ją izoliuoja

Izoliuokite tarpinio serverio sluoksnį paprašydami jo to, ko jis negali atmesti dėl programos priežasčių. CONNECT į prieglobą, kurią tarpinis serveris gali pasiekti, išmetus išvestį, pasakys, ar tunelio priėmimas apskritai veikia.

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'

Jei tai išspausdina 200 CONNECT užklausai ir tada TLS rankos paspaudimą, tarpinio serverio priėmimas tvarkingas, o vėlesnis 403 atėjo iš šaltinio. Jei išspausdina 407, pateikite tarpinio serverio prisijungimo duomenis su --proxy-user ir pakartokite prieš darydami kokią nors išvadą apie svetainę. Jei CONNECT eilutėje išspausdina 403, tarpinio serverio paties leidimų sąrašas yra riba, kurią reikia ištirti, o programa čia nedalyvauja.

Laikykite prisijungimo duomenis už shell istorijos ir už įklijuotų stenogramų. Komandinėje eilutėje įvestas tarpinio serverio slaptažodis matomas kitiems vietiniams vartotojams, o užfiksuotas CONNECT pėdsakas su prisijungimo duomenimis yra blogiau nei jokio pėdsako.

Laikykite nuosprendį įskaitomą, o ne perrašykite puslapį

Kai žinote, kuris komponentas atmetė, išsaugokite tą atsakymą. Atvirkštinis tarpinis serveris, kuris šaltinio 403 pervadina į 504 skirtąjį laiką arba pakeičia jį sėkmės puslapiu, paslepia autorizacijos sprendimą už prieinamumo istorijos ir nukreipia kitą atsakingąjį į netinkamą komandą. Pasirinktiniai klaidų puslapiai yra gerai, kai jie išlaiko būseną ir prideda kontekstą.

Talpyklos saugojimas nusipelno tokios pat priežiūros. RFC 9111 reglamentuoja, kaip bendros talpyklos gali pakartotinai naudoti atsakymus, o atmetimas, sukurtas vienam kvietėjui, neturi būti perduotas kitam taip, tarsi tai būtų leidimas. Jei atmetimo atsakymai apskritai saugomi, laikykite juos privačius ir apribotus, ir niekada nepridėkite viešos šviežumo taisyklės vien tam, kad sumažintumėte aukštupio srautą.

Užbaikite rašytiniu nuosprendžiu, kuriame įvardytas komponentas, jo sukurta būsena ir šaltinio adresas, kurį matė šaltinis. Užrašykite tikslią užklausą, galiojančius tarpinio serverio nustatymus ir laiką, kad kitą ataskaitą būtų galima palyginti su tais pačiais įrodymais, o ne iš naujo išvesti iš atminties. Tas įrašas atsako į kitą ataskaitą per sekundes ir neleidžia to paties 403 vėl diagnozuoti kaip VPN sutrikimo.