Por qué un 403 de un sitio VPN no es un fallo del proxy
Un 403 de origen, un CONNECT denegado y un desafío 407 marcan límites distintos. Compare primero la ruta de salida del proxy con la dirección VPN del navegador.
Los usuarios desconectan la VPN, reciben un 403 en un sitio interno e informan de que el proxy está roto. Tres cosas separadas pueden producir esa página: el origen rechazó la solicitud, el proxy directo se negó a abrir el túnel o el proxy exigió sus propias credenciales. Cada una es una respuesta correcta a una pregunta distinta, y aplanarlas en una página genérica de fallo destruye la única prueba que tiene. Ordene el rechazo por el componente que lo produjo y luego compare la ruta de red que cada componente usa realmente.
Nombre el componente que produjo el 403
Un código de estado HTTP pertenece a la parte que lo envió. Cuando el origen devuelve 403, ha analizado la solicitud y ha decidido que el llamador puede no tener el recurso, lo que es una respuesta de autorización y no un problema de transporte. Cuando un proxy directo responde 403 a un CONNECT, se negó a construir el túnel por completo y nunca se contactó con nada aguas arriba. Cuando responde 407, quiere sus propias credenciales, que no tienen nada que ver con el inicio de sesión de la aplicación.
| 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 |
El RFC 9110 define estos roles, incluido el desafío específico del proxy. Lea el estado propio de la respuesta y cualquier cabecera Proxy-Authenticate antes de leer el cuerpo, porque una página de error HTML amable suele ocultar qué componente la escribió.
Qué oculta un túnel CONNECT a un relé de bytes
Una vez que un proxy devuelve 200 a CONNECT, está retransmitiendo bytes y el navegador mantiene su propia sesión TLS con el origen. Por tanto, un proxy que retransmite bytes no puede leer el 403 cifrado dentro de esa sesión y nunca se convierte en el autor de la denegación. Un rechazo antes de que se abra el túnel es un suceso completamente distinto, producido una capa más abajo.
Un proxy inverso que termina TLS está en otra posición: posee el límite TLS, analiza HTTP y puede reescribir o interceptar respuestas legítimamente. Esa capacidad es una elección de configuración, no una propiedad del proxy en general, y no autoriza a saltarse la política de acceso de la aplicación. Leer la respuesta es una capacidad; decidir qué puede ver el llamador sigue siendo tarea del origen.
La consecuencia práctica es que debe saber cuál de las tres formas ejecuta antes de interpretar un 403. Añadir reglas de inspección HTTP a un proxy de flujo no le da visibilidad, y esperar que un relé de bytes explique una denegación del origen le hará mirar en el registro equivocado.
Compare la ruta de salida del proxy con la dirección del túnel del navegador
Un navegador conectado a una VPN no traslada automáticamente un servidor proxy separado a ese túnel. El origen ve la dirección de salida del proxy, y si el proxy sigue saliendo por la ruta predeterminada local, el sitio protegido ve una dirección a la que nunca se configuró para confiar. La dirección VPN interna del portátil es invisible para ese origen. Esta es la razón más habitual por la que un túnel que funciona sigue dando un 403 de un sitio que se comporta correctamente para todos los demás.
Pruebe las dos rutas por separado para que las direcciones no se confundan.
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 primera solicitud muestra qué responde el origen para su propia dirección, la segunda muestra qué responde para la del proxy. Un par de 403 coincidentes apunta a las reglas de autorización del origen; un 200 seguido de un 403 apunta a la ruta del proxy. Pregunte al propietario del origen qué direcciones de origen admite realmente el conjunto de reglas en lugar de suponer que el grupo VPN está incluido.
Pruebe cada límite con una solicitud que lo aísle
Aísle la capa de proxy pidiéndole algo que no pueda negar por motivos de aplicación. Un CONNECT a un host al que el proxy tiene permitido llegar, con la salida descartada, le dice si la admisión al túnel funciona siquiera.
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 eso imprime un 200 para el CONNECT y luego un handshake TLS, la admisión del proxy está bien y el 403 posterior vino del origen. Si imprime 407, proporcione credenciales de proxy con --proxy-user y repita antes de sacar cualquier conclusión sobre el sitio. Si imprime 403 en la línea CONNECT, la lista de permitidos propia del proxy es el límite que hay que examinar, y la aplicación no está implicada.
Mantenga las credenciales fuera del historial del shell y fuera de las transcripciones pegadas. Una contraseña de proxy escrita en una línea de comandos es visible para otros usuarios locales, y un rastro CONNECT capturado con credenciales es peor que ningún rastro.
Mantenga el veredicto legible en lugar de reescribir la página
Una vez que sepa qué componente rechazó, preserve esa respuesta. Un proxy inverso que reetiqueta un 403 del origen como un tiempo de espera 504, o lo sustituye por una página de éxito, oculta una decisión de autorización tras una historia de disponibilidad y envía al siguiente responsable al equipo equivocado. Las páginas de error personalizadas están bien cuando mantienen el estado y añaden contexto.
El almacenamiento en caché merece el mismo cuidado. El RFC 9111 regula cómo las cachés compartidas pueden reutilizar respuestas, y una denegación producida para un llamador no debe entregarse a otro como si fuera permiso. Si las respuestas de denegación se almacenan, manténgalas privadas y acotadas, y nunca añada una regla de frescura pública solo para reducir el tráfico aguas arriba.
Termine con un veredicto escrito que nombre el componente, el estado que produjo y la dirección de origen que vio el origen. Registre la solicitud exacta, la configuración de proxy vigente y la hora, para que el siguiente informe pueda contrastarse con las mismas pruebas en lugar de volver a derivarse de la memoria. Ese registro responde al siguiente informe en segundos y evita que el mismo 403 se vuelva a diagnosticar como una caída de la VPN.