De ce un 403 de la un site VPN nu este o defecțiune a proxy-ului

Utilizatorii deconectează VPN-ul, primesc un 403 pe un site intern și raportează că proxy-ul este stricat. Trei lucruri separate pot produce acea pagină: originea a refuzat cererea, proxy-ul direct a refuzat să deschidă tunelul sau proxy-ul a cerut propriile credențiale. Fiecare dintre ele este un răspuns corect la o întrebare diferită, iar aplatizarea lor într-o singură pagină generică de eroare distruge singura dovadă pe care o aveți. Sortați refuzul după componenta care l-a produs, apoi comparați calea de rețea pe care fiecare componentă o folosește efectiv.

Numiți componenta care a produs 403

Un cod de stare HTTP aparține părții care l-a trimis. Când originea returnează 403, a analizat cererea și a decis că apelantul poate să nu aibă resursa, ceea ce este un răspuns de autorizare, nu o problemă de transport. Când un proxy direct răspunde 403 la un CONNECT, a refuzat să construiască tunelul în întregime, iar nimic din amonte nu a fost contactat. Când răspunde 407, vrea propriile credențiale, care nu au nicio legătură cu autentificarea aplicației.

RFC 9110 definește aceste roluri, inclusiv provocarea specifică proxy-ului. Citiți statusul răspunsului însuși și orice antet Proxy-Authenticate înainte de a citi corpul, deoarece o pagină de eroare HTML prietenoasă ascunde de obicei ce componentă a scris-o.

Ce ascunde un tunel CONNECT de un releu de octeți

După ce un proxy returnează 200 la CONNECT, el retransmite octeți, iar browserul își păstrează propria sesiune TLS cu originea. Un proxy care retransmite octeți nu poate citi, așadar, 403-ul criptat din acea sesiune și nu devine niciodată autorul refuzului. Un refuz înainte de deschiderea tunelului este un eveniment complet diferit, produs cu un nivel mai jos.

Un proxy invers care termină TLS este într-o altă poziție: deține granița TLS, analizează HTTP și poate rescrie sau intercepta în mod legitim răspunsuri. Această capacitate este o alegere de configurare, nu o proprietate a proxy-ului în general, și nu autorizează ocolirea politicii de acces a aplicației. Citirea răspunsului este o capacitate; decizia cu privire la ce poate vedea apelantul rămâne sarcina originii.

Consecința practică este că trebuie să știți care dintre cele trei forme o rulați înainte de a interpreta un 403. Adăugarea de reguli de inspecție HTTP la un proxy de flux nu îi oferă vizibilitate, iar așteptarea ca un releu de octeți să explice un refuz al originii vă va trimite în jurnalul greșit.

Comparați calea de ieșire a proxy-ului cu adresa tunelului browserului

Un browser conectat la un VPN nu mută automat un server proxy separat pe acel tunel. Originea vede adresa de ieșire a proxy-ului, iar dacă proxy-ul iese în continuare prin ruta implicită locală, site-ul protejat vede o adresă în care nu a fost niciodată configurat să aibă încredere. Adresa VPN internă de pe laptop este invizibilă pentru acea origine. Acesta este cel mai frecvent motiv pentru care un tunel funcțional încă dă 403 de la un site care se comportă corect pentru toți ceilalți.

Testați cele două căi separat, astfel încât adresele să nu poată fi confundate.

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

Prima cerere arată ce răspunde originea pentru propria adresă, a doua arată ce răspunde pentru cea a proxy-ului. O pereche de 403 care se potrivește indică regulile de autorizare ale originii; un 200 urmat de un 403 indică calea proxy-ului. Întrebați proprietarul originii ce adrese sursă admite de fapt setul de reguli, în loc să presupuneți că pool-ul VPN este inclus.

Testați fiecare graniță cu o cerere care o izolează

Izolați stratul proxy cerându-i ceva ce nu poate refuza din motive de aplicație. Un CONNECT către un host pe care proxy-ul are voie să îl atingă, cu ieșirea aruncată, vă spune dacă admiterea în tunel funcționează deloc.

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'

Dacă asta afișează 200 pentru CONNECT și apoi un handshake TLS, admiterea proxy-ului este în regulă, iar 403-ul ulterior a venit de la origine. Dacă afișează 407, furnizați credențiale de proxy cu --proxy-user și repetați înainte de a trage orice concluzie despre site. Dacă afișează 403 pe linia CONNECT, lista de permisiuni proprie a proxy-ului este granița de examinat, iar aplicația nu este implicată.

Țineți credențialele în afara istoricului shell-ului și a transcrierilor lipite. O parolă de proxy tastată într-o linie de comandă este vizibilă altor utilizatori locali, iar o urmă CONNECT capturată cu credențiale este mai rea decât nicio urmă.

Păstrați verdictul lizibil în loc să rescrieți pagina

După ce știți ce componentă a refuzat, păstrați acel răspuns. Un proxy invers care redenumește un 403 al originii ca timeout 504 sau îl înlocuiește cu o pagină de succes ascunde o decizie de autorizare în spatele unei povești despre disponibilitate și trimite următorul respondent la echipa greșită. Paginile de eroare personalizate sunt în regulă atunci când păstrează statusul și adaugă context.

Cache-ul merită aceeași grijă. RFC 9111 reglementează modul în care cache-urile partajate pot reutiliza răspunsuri, iar un refuz produs pentru un apelant nu trebuie predat altuia ca și cum ar fi permisiune. Dacă răspunsurile de refuz sunt stocate, păstrați-le private și delimitate și nu adăugați niciodată o regulă publică de prospețime doar pentru a reduce traficul din amonte.

Încheiați cu un verdict scris care numește componenta, statusul pe care l-a produs și adresa sursă pe care a văzut-o originea. Înregistrați cererea exactă, setările de proxy în vigoare și ora, astfel încât raportul următor să poată fi comparat cu aceleași dovezi în loc să fie derivat din nou din memorie. Acea înregistrare răspunde raportului următor în câteva secunde și împiedică rediagnosticarea aceluiași 403 ca o cădere a VPN-ului.