Zašto 403 sa VPN stranice nije kvar proxyja

Korisnici isključe VPN, naiđu na 403 na internoj stranici i prijave da je proxy pokvaren. Tri odvojene stvari mogu proizvesti tu stranicu: izvor je odbio zahtjev, naprijed proxy je odbio otvoriti tunel ili je proxy zatražio vlastite vjerodajnice. Svaka od njih točan je odgovor na drugo pitanje, a njihovo svođenje na jednu opću stranicu kvara uništava jedini dokaz koji imate. Razvrstajte odbijanje po komponenti koja ga je proizvela, a zatim uporedite mrežnu putanju koju svaka komponenta zapravo koristi.

Imenujte komponentu koja je proizvela 403

HTTP statusni kod pripada strani koja ga je poslala. Kad izvor vrati 403, obradio je zahtjev i zaključio da pozivatelj možda nema resurs, što je odgovor o autorizaciji, a ne transportni problem. Kad naprijed proxy odgovori 403 na CONNECT, odbio je uopće izgraditi tunel i ništa uzvodno nije bilo kontaktirano. Kad odgovori 407, traži vlastite vjerodajnice, koje nemaju veze s prijavom u aplikaciju.

RFC 9110 definira te uloge, uključujući izazov specifičan za proxy. Pročitajte vlastiti status odgovora i svako zaglavlje Proxy-Authenticate prije čitanja tijela, jer prijateljska HTML stranica pogreške obično skriva koja ju je komponenta napisala.

Što CONNECT tunel skriva od prijenosa bajtova

Nakon što proxy vrati 200 na CONNECT, prenosi bajtove i preglednik zadržava vlastitu TLS sesiju s izvorom. Proxy koji prenosi bajtove stoga ne može pročitati šifrirani 403 unutar te sesije i nikada ne postaje autor odbijanja. Odbijanje prije otvaranja tunela posve je drugi događaj, proizveden jedan sloj niže.

Obrnuti proxy koji završava TLS u drugom je položaju: posjeduje TLS granicu, analizira HTTP i može legitimno prepisivati ili presretati odgovore. Ta je sposobnost izbor konfiguracije, a ne svojstvo proxyja općenito, i ne daje ovlast za zaobilaženje pristupne politike aplikacije. Čitanje odgovora sposobnost je; odluka o tome što pozivatelj smije vidjeti ostaje posao izvora.

Praktična posljedica je da morate znati koji od tri oblika pokrećete prije nego protumačite 403. Dodavanje pravila za HTTP inspekciju stream proxyju ne daje mu vidljivost, a očekivanje da prijenos bajtova objasni odbijanje izvora poslat će vas u pogrešan dnevnik.

Uporedite izlaznu putanju proxyja s adresom tunela preglednika

Preglednik povezan s VPN-om ne premješta automatski zaseban proxy poslužitelj u taj tunel. Izvor vidi izlaznu adresu proxyja, a ako proxy još izlazi kroz lokalnu zadanu rutu, zaštićena stranica vidi adresu kojoj nikada nije bila konfigurirana vjerovati. Unutarnja VPN adresa na prijenosniku nevidljiva je tom izvoru. To je najčešći razlog zašto tunel koji radi još daje 403 sa stranice koja se prema svima ostalima ponaša ispravno.

Testirajte dvije putanje odvojeno kako se adrese ne bi pomiješale.

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

Prvi zahtjev pokazuje što izvor odgovara na vašu vlastitu adresu, drugi pokazuje što odgovara na proxyjevu. Podudarni par 403 upućuje na izvorna pravila autorizacije; 200 nakon kojeg slijedi 403 upućuje na proxy putanju. Pitajte vlasnika izvora koje izvorne adrese skup pravila zapravo dopušta, umjesto da pretpostavite da je VPN pool uključen.

Testirajte svaku granicu zahtjevom koji je izolira

Izolirajte proxy sloj tražeći od njega nešto što ne može odbiti iz aplikacijskih razloga. CONNECT prema hostu do kojeg proxy smije doći, s odbačenim izlazom, govori vam radi li prijam tunela uopće.

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'

Ako to ispiše 200 za CONNECT i zatim TLS rukovanje, prijam proxyja je u redu i kasniji 403 došao je od izvora. Ako ispiše 407, dostavite proxy vjerodajnice s --proxy-user i ponovite prije bilo kakvog zaključka o stranici. Ako ispiše 403 na retku CONNECT, proxyjev vlastiti popis dopuštenja granica je koju treba ispitati, a aplikacija nije uključena.

Držite vjerodajnice izvan povijesti ljuske i izvan zalijepljenih transkripata. Lozinka proxyja upisana u naredbeni redak vidljiva je drugim lokalnim korisnicima, a snimljeni CONNECT trag s vjerodajnicama gori je od nikakvog traga.

Držite presudu čitljivom umjesto da prepisujete stranicu

Kad znate koja je komponenta odbila, sačuvajte taj odgovor. Obrnuti proxy koji izvorni 403 preimenuje u 504 istek ili ga zamijeni stranicom uspjeha skriva odluku o autorizaciji iza priče o dostupnosti i šalje sljedećeg odgovornog u pogrešan tim. Prilagođene stranice pogreške dobre su kad zadrže status i dodaju kontekst.

Keširanje zaslužuje istu pažnju. RFC 9111 uređuje kako zajednički keševi smiju ponovno koristiti odgovore, a odbijanje proizvedeno za jednog pozivatelja ne smije se predati drugome kao da je dopuštenje. Ako se odgovori odbijanja uopće pohranjuju, držite ih privatnima i ograničenima i nikada ne dodajte javno pravilo svježine samo da smanjite uzvodni promet.

Završite pisanom presudom koja imenuje komponentu, status koji je proizvela i izvornu adresu koju je izvor vidio. Zabilježite točan zahtjev, proxy postavke na snazi i vrijeme, kako bi se sljedeće izvješće moglo usporediti s istim dokazima umjesto iznova izvoditi iz pamćenja. Taj zapis odgovara na sljedeće izvješće u sekundama i zaustavlja ponovno dijagnosticiranje istog 403 kao VPN ispada.