Per què un 403 d'un lloc VPN no és una fallada del proxy

Els usuaris desconnecten la VPN, reben un 403 en un lloc intern i informen que el proxy està espatllat. Tres coses separades poden produir aquella pàgina: l'origen va refusar la petició, el proxy directe va refusar obrir el túnel o el proxy va exigir les seves pròpies credencials. Cadascuna és una resposta correcta a una pregunta diferent, i aplanar-les en una pàgina genèrica de fallada destrueix l'única prova que teniu. Classifiqueu el refús pel component que el va fer i després compareu el camí de xarxa que cada component utilitza realment.

Anomeneu el component que va produir el 403

Un codi d'estat HTTP pertany a la part que l'ha enviat. Quan l'origen retorna 403, ha analitzat la petició i ha decidit que el sol·licitant potser no té el recurs, cosa que és una resposta d'autorització i no un problema de transport. Quan un proxy directe respon 403 a un CONNECT, ha refusat construir el túnel del tot i no s'ha contactat res més amunt. Quan respon 407, vol les seves pròpies credencials, que no tenen res a veure amb l'inici de sessió de l'aplicació.

El RFC 9110 defineix aquests papers, inclòs el repte específic del proxy. Llegiu l'estat propi de la resposta i qualsevol capçalera Proxy-Authenticate abans de llegir el cos, perquè una pàgina d'error HTML amistosa sol amagar quin component la va escriure.

Què amaga un túnel CONNECT a un relé de bytes

Un cop un proxy retorna 200 a CONNECT, està retransmetent bytes i el navegador manté la seva pròpia sessió TLS amb l'origen. Per tant, un proxy que retransmet bytes no pot llegir el 403 xifrat dins d'aquella sessió i mai no es converteix en l'autor de la denegació. Un refús abans que s'obri el túnel és un esdeveniment completament diferent, produït una capa més avall.

Un proxy invers que acaba el TLS és en una posició diferent: posseeix la frontera TLS, analitza HTTP i pot reescriure o interceptar respostes legítimament. Aquesta capacitat és una elecció de configuració, no una propietat del proxy en general, i no autoritza saltar-se la política d'accés de l'aplicació. Llegir la resposta és una capacitat; decidir què pot veure el sol·licitant continua sent feina de l'origen.

La conseqüència pràctica és que heu de saber quina de les tres formes executeu abans d'interpretar un 403. Afegir regles d'inspecció HTTP a un proxy de flux no li dona visibilitat, i esperar que un relé de bytes expliqui una denegació d'origen us farà mirar el registre equivocat.

Compareu el camí de sortida del proxy amb l'adreça del túnel del navegador

Un navegador connectat a una VPN no trasllada automàticament un servidor proxy separat a aquell túnel. L'origen veu l'adreça de sortida del proxy, i si el proxy encara surt per la ruta predeterminada local, el lloc protegit veu una adreça a la qual mai no s'havia configurat confiar. L'adreça VPN interna de l'ordinador és invisible per a aquell origen. Aquesta és la raó més habitual que un túnel que funciona encara doni un 403 d'un lloc que es comporta correctament per a tota la resta.

Proveu els dos camins per separat perquè les adreces no es puguin confondre.

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

La primera petició mostra què respon l'origen per a la vostra adreça, la segona mostra què respon per a la del proxy. Una parella de 403 coincidents apunta a les regles d'autorització de l'origen; un 200 seguit d'un 403 apunta al camí del proxy. Pregunteu a l'amo de l'origen quines adreces d'origen admet realment el conjunt de regles en lloc de suposar que la piscina VPN hi és inclosa.

Proveu cada frontera amb una petició que l'aïlli

Aïlleu la capa de proxy demanant-li una cosa que no pugui refusar per motius d'aplicació. Un CONNECT a un amfitrió al qual el proxy té permís d'arribar, amb la sortida descartada, us diu si l'admissió al túnel funciona del tot.

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'

Si això imprimeix un 200 per al CONNECT i després un handshake TLS, l'admissió del proxy està bé i el 403 posterior va venir de l'origen. Si imprimeix 407, proporcioneu credencials del proxy amb --proxy-user i repetiu abans de treure cap conclusió sobre el lloc. Si imprimeix 403 a la línia CONNECT, la llista de permisos pròpia del proxy és la frontera que cal examinar, i l'aplicació no hi té res a veure.

Manteniu les credencials fora de l'historial de l'intèrpret i fora de les transcripcions enganxades. Una contrasenya de proxy escrita en una línia d'ordres és visible per a altres usuaris locals, i un rastre CONNECT capturat amb credencials és pitjor que cap rastre.

Manteniu el veredicte llegible en lloc de reescriure la pàgina

Un cop sapigueu quin component va refusar, preserveu aquella resposta. Un proxy invers que reetiqueta un 403 d'origen com a temps d'espera 504, o el substitueix per una pàgina d'èxit, amaga una decisió d'autorització darrere d'una història de disponibilitat i envia el següent responsable a l'equip equivocat. Les pàgines d'error personalitzades estan bé quan mantenen l'estat i afegeixen context.

L'emmagatzematge en memòria cau mereix la mateixa cura. El RFC 9111 regeix com les memòries cau compartides poden reutilitzar respostes, i una denegació produïda per a un sol·licitant no s'ha de lliurar a un altre com si fos permís. Si les respostes de denegació s'emmagatzemen, manteniu-les privades i abastades, i no afegiu mai una regla de frescor pública només per reduir el trànsit ascendent.

Acabeu amb un veredicte escrit que anomeni el component, l'estat que va produir i l'adreça d'origen que va veure l'origen. Registreu la petició exacta, la configuració de proxy vigent i l'hora, perquè el proper informe es pugui contrastar amb les mateixes proves en lloc de tornar a derivar-se de la memòria. Aquest registre respon el proper informe en segons i evita que el mateix 403 es torni a diagnosticar com una caiguda de la VPN.