Como un proxy público chega a unha orixe privada a través dunha VPN

Publicar un sitio web a través dun túnel e dar acceso VPN aos usuarios son dous arranxos distintos que comparten un cable. No primeiro, un proxy inverso público acepta a petición do visitante e reenvíaa polo túnel ata unha orixe á que ninguén pode chegar directamente. No segundo, o usuario debe unirse á VPN antes de que a aplicación sexa accesible. Mesturar as dúas descricións é como un backend privado acaba exposto publicamente.

Dous modelos que parecen iguais nun diagrama

Debuxe as frechas antes de escoller nada. Un modelo de publicación pública vai do navegador ao proxy por HTTPS, despois do proxy á orixe polo túnel, e a orixe nunca acepta unha conexión desde internet. Un modelo só VPN vai do cliente á pasarela, e a aplicación só é accesible desde dentro desa ruta. O portátil do usuario está na mesma rede que a aplicación, e ese é todo o sentido dese modelo.

Os modelos difiren en quen autentica e onde. No primeiro, o proxy é a entrada pública e reenvía calquera petición que chegue, incluída unha hostil, suxeita á política configurada nel. No segundo, a accesibilidade mesma é a porta, que é unha admisión groseira pero real.

Onde se detén TLS e que demostra en realidade

TLS entre o navegador e o proxy protexe ese salto e permite ao navegador verificar o sitio que pretendía visitar. Se o proxy remata TLS, a petición existe en forma lexible dentro dese proceso antes de reenviarse. Unha segunda sesión TLS cara á orixe pode protexer o seguinte salto e verificar por separado o extremo da aplicación. Ningunha das dúas sesións decide que persoa pode usar a aplicación. Un certificado comodín no proxy tampouco se estende a ese segundo salto.

Esta é a parte que a xente reduce á palabra cifrado. A confidencialidade, a integridade e a identidade do servidor son propiedades de transporte; a autorización é unha decisión da aplicación. Un enderezo privado detrás dun túnel cambia quen pode chegar ao socket, non quen pode iniciar sesión unha vez que chega.

Confíe nas cabeceiras reenviadas só desde o proxy

As aplicacións que rexistran ou autorizan pola dirección do cliente adoitan ler unha cabeceira que engade o proxy. Esa cabeceira é só texto, así que calquera cousa capaz de chegar directamente á orixe pode reclamar calquera enderezo que queira. Restrinxa a orixe para que só a dirección do túnel do proxy poida conectarse, e configure a aplicación para aceptar a cabeceira só desde esa dirección.

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

Se esa petición ten éxito desde un host que non é o proxy, a orixe confía nunha cabeceira que debería ignorar. Arranxe o listener antes de tocar a aplicación. Unha denegación é un resultado moito mellor que unha liña de rexistro cun enderezo falsificado.

Manteña a orixe accesible desde exactamente un lugar

Ate o listener da orixe á dirección do túnel ou bloquéxeo cun cortafuegos cara ao proxy, e despois confirme que está escoitando realmente. Un servizo iniciado cunha vinculación comodín acepta conexións en cada interface que ten o host, incluída unha que esqueceu que era encamiñable. A táboa de escoita é a verdade básica, non o ficheiro de configuración que pensaba aplicar. Se a vinculación comodín é intencionada, o cortafuegos segue tendo que ser o compoñente que a estreita.

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

Faga a mesma revisión para as interfaces de administración, que son a exposición accidental habitual. Despois escriba os dous modelos por separado: o sitio público a través do proxy e a interface de administración accesible só polo túnel. A frase de que o servidor está detrás dunha VPN non di nada diso.