Como um proxy público chega a uma origem privada através de uma VPN

Publicar um site através de um túnel e dar aos usuários acesso VPN são dois arranjos diferentes que compartilham um cabo. No primeiro, um proxy reverso público aceita a solicitação do visitante e a encaminha pelo túnel até uma origem que ninguém consegue alcançar diretamente. No segundo, o usuário precisa entrar na VPN antes que a aplicação seja acessível. Misturar as duas descrições é como um backend privado acaba exposto publicamente.

Dois modelos que parecem iguais num diagrama

Desenhe as setas antes de escolher qualquer coisa. Um modelo de publicação pública vai do navegador ao proxy por HTTPS, depois do proxy à origem pelo túnel, e a origem nunca aceita uma conexão da internet. Um modelo somente VPN vai do cliente ao gateway, e a aplicação só é acessível por dentro desse caminho. O laptop do usuário fica na mesma rede que a aplicação, e esse é todo o sentido desse modelo.

Os modelos diferem em quem autentica e onde. No primeiro, o proxy é a entrada pública e repassa qualquer solicitação que chegue, inclusive uma hostil, sujeita à política configurada nele. No segundo, a acessibilidade em si é o portão, o que é uma admissão grosseira, mas real.

Onde o TLS para, e o que ele realmente prova

O TLS entre navegador e proxy protege esse salto e permite ao navegador verificar o site que pretendia visitar. Se o proxy termina o TLS, a solicitação existe em forma legível dentro desse processo antes de ser encaminhada. Uma segunda sessão TLS até a origem pode proteger o próximo salto e verificar separadamente o endpoint da aplicação. Nenhuma das sessões decide qual pessoa pode usar a aplicação. Um certificado curinga no proxy também não se estende a esse segundo salto.

Esta é a parte que as pessoas resumem na palavra criptografado. Confidencialidade, integridade e identidade do servidor são propriedades de transporte; autorização é uma decisão da aplicação. Um endereço privado atrás de um túnel muda quem pode alcançar o socket, não quem pode fazer login depois de chegar.

Confie nos cabeçalhos encaminhados apenas vindos do proxy

As aplicações que registram ou autorizam pelo endereço do cliente costumam ler um cabeçalho que o proxy adiciona. Esse cabeçalho é apenas texto, então qualquer coisa capaz de alcançar a origem diretamente pode reivindicar qualquer endereço que quiser. Restrinja a origem para que apenas o endereço do túnel do proxy possa conectar, e configure a aplicação para aceitar o cabeçalho apenas desse endereço.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Se essa solicitação tiver sucesso a partir de um host que não é o proxy, a origem está confiando num cabeçalho que deveria ignorar. Corrija o listener antes de tocar na aplicação. Uma negação é um resultado muito melhor do que uma linha de log com um endereço falsificado.

Mantenha a origem acessível a partir de exatamente um lugar

Vincule o listener da origem ao endereço do túnel ou cerque-o com um firewall em direção ao proxy, e depois confirme o que está realmente escutando. Um serviço iniciado com uma vinculação curinga aceita conexões em todas as interfaces que o host tem, inclusive uma que você esqueceu ser roteável. A tabela de escuta é a verdade básica, não o arquivo de configuração que você pretendia aplicar. Se a vinculação curinga é intencional, o firewall ainda precisa ser o componente que a restringe.

ss -ltnp | grep -E ':(80|443)'

Faça a mesma revisão para as interfaces de administração, que são a exposição acidental habitual. Depois escreva os dois modelos separadamente: o site público através do proxy e a interface de administração acessível apenas pelo túnel. A frase de que o servidor está atrás de uma VPN não diz nada disso.