Por que un 403 dun sitio VPN non é un fallo do proxy

Os usuarios desconectan a VPN, reciben un 403 nun sitio interno e informan de que o proxy está roto. Tres cousas separadas poden producir esa páxina: a orixe rexeitou a solicitude, o proxy directo negouse a abrir o túnel ou o proxy esixiu as súas propias credenciais. Cada unha é unha resposta correcta a unha pregunta distinta, e aplanalas nunha páxina xenérica de fallo destrúe a única proba que ten. Ordene o rexeitamento polo compoñente que o produciu e despois compare a ruta de rede que cada compoñente usa realmente.

Nomee o compoñente que produciu o 403

Un código de estado HTTP pertence á parte que o enviou. Cando a orixe devolve 403, analizou a solicitude e decidiu que o chamador pode non ter o recurso, o que é unha resposta de autorización e non un problema de transporte. Cando un proxy directo responde 403 a un CONNECT, negouse a construír o túnel por completo e nunca se contactou con nada augas arriba. Cando responde 407, quere as súas propias credenciais, que non teñen nada que ver co inicio de sesión da aplicación.

O RFC 9110 define estes roles, incluído o reto específico do proxy. Lea o estado propio da resposta e calquera cabeceira Proxy-Authenticate antes de ler o corpo, porque unha páxina de erro HTML amable adoita ocultar que compoñente a escribiu.

Que oculta un túnel CONNECT a un relé de bytes

Unha vez que un proxy devolve 200 a CONNECT, está retransmitindo bytes e o navegador mantén a súa propia sesión TLS coa orixe. Polo tanto, un proxy que retransmite bytes non pode ler o 403 cifrado dentro desa sesión e nunca se converte no autor da denegación. Un rexeitamento antes de que se abra o túnel é un suceso completamente distinto, producido unha capa máis abaixo.

Un proxy inverso que remata TLS está noutra posición: posúe o límite TLS, analiza HTTP e pode reescribir ou interceptar respostas lexitimamente. Esa capacidade é unha elección de configuración, non unha propiedade do proxy en xeral, e non autoriza saltarse a política de acceso da aplicación. Ler a resposta é unha capacidade; decidir que pode ver o chamador segue sendo tarefa da orixe.

A consecuencia práctica é que debe saber cal das tres formas executa antes de interpretar un 403. Engadir regras de inspección HTTP a un proxy de fluxo non lle dá visibilidade, e esperar que un relé de bytes explique unha denegación da orixe faralle mirar no rexistro equivocado.

Compare a ruta de saída do proxy coa dirección do túnel do navegador

Un navegador conectado a unha VPN non traslada automaticamente un servidor proxy separado a ese túnel. A orixe ve a dirección de saída do proxy, e se o proxy segue saíndo pola ruta predeterminada local, o sitio protexido ve unha dirección á que nunca se configurou para confiar. A dirección VPN interna do portátil é invisible para esa orixe. Esta é a razón máis habitual pola que un túnel que funciona segue dando un 403 dun sitio que se comporta correctamente para todos os demais.

Probe as dúas rutas por separado para que as direccións non 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/private

A primeira solicitude mostra que responde a orixe para a súa propia dirección, a segunda mostra que responde para a do proxy. Un par de 403 coincidentes apunta ás regras de autorización da orixe; un 200 seguido dun 403 apunta á ruta do proxy. Pregunte ao propietario da orixe que direccións de orixe admite realmente o conxunto de regras en lugar de supoñer que o grupo VPN está incluído.

Probe cada límite cunha solicitude que o illa

Illa a capa de proxy pedíndolle algo que non poida negar por motivos de aplicación. Un CONNECT a un host ao que o proxy ten permiso de chegar, coa saída descartada, dille se a admisión ao túnel funciona sequera.

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 iso imprime un 200 para o CONNECT e despois un handshake TLS, a admisión do proxy está ben e o 403 posterior veu da orixe. Se imprime 407, proporcione credenciais de proxy con --proxy-user e repita antes de sacar calquera conclusión sobre o sitio. Se imprime 403 na liña CONNECT, a lista de permitidos propia do proxy é o límite que hai que examinar, e a aplicación non está implicada.

Manteña as credenciais fóra do historial da shell e fóra das transcricións pegadas. Un contrasinal de proxy escrito nunha liña de comandos é visible para outros usuarios locais, e un rastro CONNECT capturado con credenciais é peor que ningún rastro.

Manteña o veredicto lexible en lugar de reescribir a páxina

Unha vez que saiba que compoñente rexeitou, preserve esa resposta. Un proxy inverso que reetiqueta un 403 da orixe como un tempo de espera 504, ou o substitúe por unha páxina de éxito, oculta unha decisión de autorización tras unha historia de dispoñibilidade e envía o seguinte responsable ao equipo equivocado. As páxinas de erro personalizadas están ben cando manteñen o estado e engaden contexto.

A caché merece o mesmo coidado. O RFC 9111 regula como as cachés compartidas poden reutilizar respostas, e unha denegación producida para un chamador non debe entregarse a outro coma se fose permiso. Se as respostas de denegación se almacenan, manteñaas privadas e acoutadas, e nunca engada unha regra de frescura pública só para reducir o tráfico augas arriba.

Remate cun veredicto escrito que nomee o compoñente, o estado que produciu e a dirección de orixe que viu a orixe. Rexistre a solicitude exacta, a configuración de proxy vixente e a hora, para que o seguinte informe poida contrastarse coas mesmas probas en lugar de volver derivarse da memoria. Ese rexistro responde ao seguinte informe en segundos e evita que o mesmo 403 se volva diagnosticar como unha caída da VPN.