Por que um 403 de um site VPN não é uma falha do proxy

Os usuários desconectam a VPN, recebem um 403 num site interno e relatam que o proxy está quebrado. Três coisas separadas podem produzir essa página: a origem recusou a solicitação, o proxy direto recusou-se a abrir o túnel ou o proxy exigiu suas próprias credenciais. Cada uma é uma resposta correta a uma pergunta diferente, e achatá-las numa página genérica de falha destrói a única evidência que você tem. Classifique a recusa pelo componente que a produziu e depois compare o caminho de rede que cada componente realmente usa.

Nomeie o componente que produziu o 403

Um código de status HTTP pertence à parte que o enviou. Quando a origem retorna 403, ela analisou a solicitação e decidiu que o chamador pode não ter o recurso, o que é uma resposta de autorização e não um problema de transporte. Quando um proxy direto responde 403 a um CONNECT, ele recusou-se a construir o túnel por completo, e nada a montante foi contatado. Quando responde 407, quer suas próprias credenciais, que não têm nada a ver com o login da aplicação.

O RFC 9110 define esses papéis, incluindo o desafio específico do proxy. Leia o status da própria resposta e qualquer cabeçalho Proxy-Authenticate antes de ler o corpo, porque uma página de erro HTML amigável costuma esconder qual componente a escreveu.

O que um túnel CONNECT esconde de um relé de bytes

Depois que um proxy retorna 200 a CONNECT, ele está retransmitindo bytes e o navegador mantém sua própria sessão TLS com a origem. Um proxy que retransmite bytes não pode, portanto, ler o 403 cifrado dentro dessa sessão, e nunca se torna o autor da negação. Uma recusa antes de o túnel abrir é um evento completamente diferente, produzido uma camada abaixo.

Um proxy reverso que termina TLS está noutra posição: possui a fronteira TLS, analisa HTTP e pode legitimamente reescrever ou interceptar respostas. Essa capacidade é uma escolha de configuração, não uma propriedade do proxy em geral, e não autoriza contornar a política de acesso da aplicação. Ler a resposta é uma capacidade; decidir o que o chamador pode ver continua sendo tarefa da origem.

A consequência prática é que você precisa saber qual das três formas executa antes de interpretar um 403. Adicionar regras de inspeção HTTP a um proxy de fluxo não lhe dá visibilidade, e esperar que um relé de bytes explique uma negação da origem fará você procurar no log errado.

Compare o caminho de saída do proxy com o endereço do túnel do navegador

Um navegador conectado a uma VPN não move automaticamente um servidor proxy separado para esse túnel. A origem vê o endereço de saída do proxy, e se o proxy ainda sai pela rota padrão local, o site protegido vê um endereço em que nunca foi configurado para confiar. O endereço VPN interno do notebook é invisível para essa origem. Esta é a razão mais comum para um túnel que funciona ainda dar 403 de um site que se comporta corretamente para todos os outros.

Teste os dois caminhos separadamente para que os endereços não se confundam.

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 solicitação mostra o que a origem responde para o seu próprio endereço, a segunda mostra o que ela responde para o do proxy. Um par de 403 coincidentes aponta para as regras de autorização da origem; um 200 seguido de um 403 aponta para o caminho do proxy. Pergunte ao dono da origem quais endereços de origem o conjunto de regras realmente admite, em vez de supor que o pool VPN está incluído.

Teste cada fronteira com uma solicitação que a isole

Isole a camada de proxy pedindo-lhe algo que ela não possa recusar por razões de aplicação. Um CONNECT a um host que o proxy tem permissão de alcançar, com a saída descartada, diz se a admissão ao túnel funciona sequer.

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 isso imprimir um 200 para o CONNECT e depois um handshake TLS, a admissão do proxy está bem e o 403 posterior veio da origem. Se imprimir 407, forneça credenciais de proxy com --proxy-user e repita antes de tirar qualquer conclusão sobre o site. Se imprimir 403 na linha CONNECT, a lista de permissões do próprio proxy é a fronteira a examinar, e a aplicação não está envolvida.

Mantenha as credenciais fora do histórico do shell e fora das transcrições coladas. Uma senha de proxy digitada numa linha de comando é visível para outros usuários locais, e um rastro CONNECT capturado com credenciais é pior do que nenhum rastro.

Mantenha o veredito legível em vez de reescrever a página

Depois de saber qual componente recusou, preserve essa resposta. Um proxy reverso que renomeia um 403 da origem como tempo limite 504, ou o substitui por uma página de sucesso, esconde uma decisão de autorização atrás de uma história de disponibilidade e envia o próximo responsável para a equipe errada. Páginas de erro personalizadas são boas quando mantêm o status e acrescentam contexto.

O cache merece o mesmo cuidado. O RFC 9111 rege como os caches compartilhados podem reutilizar respostas, e uma negação produzida para um chamador não deve ser entregue a outro como se fosse permissão. Se as respostas de negação forem armazenadas, mantenha-as privadas e limitadas, e nunca acrescente uma regra de frescor pública só para reduzir o tráfego a montante.

Termine com um veredito escrito que nomeie o componente, o status que ele produziu e o endereço de origem que a origem viu. Registre a solicitação exata, as configurações de proxy em vigor e a hora, para que o próximo relatório possa ser confrontado com as mesmas evidências em vez de ser deduzido novamente da memória. Esse registro responde ao próximo relatório em segundos e impede que o mesmo 403 seja diagnosticado outra vez como queda de VPN.