Perché un 403 da un sito VPN non è un guasto del proxy
Un 403 dell'origine, un CONNECT negato e una sfida 407 segnano confini diversi. Confronta prima il percorso di uscita del proxy con l'indirizzo VPN del browser.
Gli utenti disconnettono la VPN, ricevono un 403 su un sito interno e segnalano che il proxy è guasto. Tre cose separate possono produrre quella pagina: l'origine ha rifiutato la richiesta, il proxy diretto si è rifiutato di aprire il tunnel o il proxy ha preteso le proprie credenziali. Ciascuna è una risposta corretta a una domanda diversa, e appiattirle in un'unica pagina di errore generica distrugge l'unica prova che hai. Ordina il rifiuto per il componente che l'ha prodotto, poi confronta il percorso di rete che ciascun componente usa davvero.
Nomina il componente che ha prodotto il 403
Un codice di stato HTTP appartiene alla parte che lo ha inviato. Quando l'origine restituisce 403, ha analizzato la richiesta e deciso che il chiamante potrebbe non avere la risorsa, il che è una risposta di autorizzazione e non un problema di trasporto. Quando un proxy diretto risponde 403 a un CONNECT, ha rifiutato di costruire il tunnel del tutto, e nulla a monte è mai stato contattato. Quando risponde 407, vuole le proprie credenziali, che non hanno nulla a che fare con l'accesso dell'applicazione.
| 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 |
L'RFC 9110 definisce questi ruoli, inclusa la sfida specifica del proxy. Leggi lo stato della risposta stessa e qualsiasi intestazione Proxy-Authenticate prima di leggere il corpo, perché una pagina di errore HTML amichevole di solito nasconde quale componente l'ha scritta.
Cosa nasconde un tunnel CONNECT a un relè di byte
Una volta che un proxy restituisce 200 a CONNECT, sta inoltrando byte e il browser mantiene la propria sessione TLS con l'origine. Un proxy che inoltra byte non può quindi leggere il 403 cifrato dentro quella sessione, e non diventa mai l'autore del rifiuto. Un rifiuto prima che il tunnel si apra è un evento completamente diverso, prodotto un livello più in basso.
Un proxy inverso che termina TLS è in una posizione diversa: possiede il confine TLS, analizza HTTP e può legittimamente riscrivere o intercettare le risposte. Questa capacità è una scelta di configurazione, non una proprietà del proxy in generale, e non autorizza a bypassare la politica di accesso dell'applicazione. Leggere la risposta è una capacità; decidere cosa il chiamante può vedere resta compito dell'origine.
La conseguenza pratica è che devi sapere quale delle tre forme esegui prima di interpretare un 403. Aggiungere regole di ispezione HTTP a un proxy di flusso non gli dà visibilità, e aspettarsi che un relè di byte spieghi un rifiuto dell'origine ti farà cercare nel registro sbagliato.
Confronta il percorso di uscita del proxy con l'indirizzo del tunnel del browser
Un browser connesso a una VPN non sposta automaticamente un server proxy separato su quel tunnel. L'origine vede l'indirizzo di uscita del proxy, e se il proxy esce ancora dalla route predefinita locale, il sito protetto vede un indirizzo a cui non è mai stato configurato di fidarsi. L'indirizzo VPN interno del portatile è invisibile a quell'origine. È il motivo più comune per cui un tunnel funzionante dà ancora un 403 da un sito che si comporta correttamente per tutti gli altri.
Prova i due percorsi separatamente così gli indirizzi non possono essere confusi.
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/privateLa prima richiesta mostra cosa risponde l'origine per il tuo indirizzo, la seconda cosa risponde per quello del proxy. Una coppia di 403 corrispondenti punta alle regole di autorizzazione dell'origine; un 200 seguito da un 403 punta al percorso del proxy. Chiedi al proprietario dell'origine quali indirizzi di origine il set di regole ammette davvero, invece di supporre che il pool VPN sia incluso.
Prova ogni confine con una richiesta che lo isola
Isola il livello proxy chiedendogli qualcosa che non può rifiutare per motivi applicativi. Un CONNECT verso un host che il proxy può raggiungere, con l'output scartato, ti dice se l'ammissione al tunnel funziona affatto.
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'
Se questo stampa un 200 per il CONNECT e poi una stretta di mano TLS, l'ammissione del proxy va bene e il 403 successivo è venuto dall'origine. Se stampa 407, fornisci credenziali proxy con --proxy-user e ripeti prima di trarre qualsiasi conclusione sul sito. Se stampa 403 sulla riga CONNECT, la lista di autorizzazione del proxy stesso è il confine da esaminare, e l'applicazione non è coinvolta.
Tieni le credenziali fuori dalla cronologia della shell e fuori dalle trascrizioni incollate. Una password proxy digitata su una riga di comando è visibile ad altri utenti locali, e una traccia CONNECT catturata con credenziali è peggio di nessuna traccia.
Mantieni leggibile il verdetto invece di riscrivere la pagina
Una volta che sai quale componente ha rifiutato, conserva quella risposta. Un proxy inverso che rietichetta un 403 dell'origine come timeout 504, o lo sostituisce con una pagina di successo, nasconde una decisione di autorizzazione dietro una storia di disponibilità e manda il prossimo responsabile al team sbagliato. Le pagine di errore personalizzate vanno bene quando mantengono lo stato e aggiungono contesto.
La cache merita la stessa cura. L'RFC 9111 regola come le cache condivise possono riutilizzare le risposte, e un rifiuto prodotto per un chiamante non deve essere consegnato a un altro come se fosse un permesso. Se le risposte di rifiuto vengono archiviate, mantienile private e delimitate, e non aggiungere mai una regola di freschezza pubblica solo per ridurre il traffico a monte.
Chiudi con un verdetto scritto che nomini il componente, lo stato che ha prodotto e l'indirizzo di origine che l'origine ha visto. Registra la richiesta esatta, le impostazioni proxy in vigore e l'ora, così che il prossimo rapporto possa essere confrontato con le stesse prove invece di essere riderivato dalla memoria. Quel registro risponde al prossimo rapporto in pochi secondi e impedisce che lo stesso 403 venga ridiagnosticato come un'interruzione VPN.