Cómo un proxy público llega a un origen privado a través de una VPN

Publicar un sitio web a través de un túnel y dar acceso VPN a los usuarios son dos arreglos distintos que comparten un cable. En el primero, un proxy inverso público acepta la petición del visitante y la reenvía por el túnel hasta un origen que nadie puede alcanzar directamente. En el segundo, el usuario debe unirse a la VPN antes de que la aplicación sea siquiera accesible. Mezclar ambas descripciones es como un backend privado termina expuesto públicamente.

Dos modelos que se parecen en un diagrama

Dibuje las flechas antes de elegir nada. Un modelo de publicación pública va del navegador al proxy por HTTPS, luego del proxy al origen por el túnel, y el origen nunca acepta una conexión desde internet. Un modelo solo VPN va del cliente a la pasarela, y la aplicación solo es accesible desde dentro de esa ruta. El portátil del usuario está en la misma red que la aplicación, y ese es todo el sentido de ese modelo.

Los modelos difieren en quién autentica y dónde. En el primero, el proxy es la entrada pública y reenvía cualquier petición que llegue, incluida una hostil, sujeta a la política configurada en él. En el segundo, la accesibilidad misma es la puerta, que es una admisión tosca pero real.

Dónde se detiene TLS y qué demuestra en realidad

TLS entre el navegador y el proxy protege ese salto y permite al navegador verificar el sitio que pretendía visitar. Si el proxy termina TLS, la petición existe en forma legible dentro de ese proceso antes de reenviarse. Una segunda sesión TLS hacia el origen puede proteger el siguiente salto y verificar por separado el extremo de la aplicación. Ninguna de las dos sesiones decide qué persona puede usar la aplicación. Un certificado comodín en el proxy tampoco se extiende a ese segundo salto.

Esta es la parte que la gente reduce a la palabra cifrado. La confidencialidad, la integridad y la identidad del servidor son propiedades de transporte; la autorización es una decisión de la aplicación. Una dirección privada detrás de un túnel cambia quién puede llegar al socket, no quién puede iniciar sesión una vez que llega.

Confíe en las cabeceras reenviadas solo desde el proxy

Las aplicaciones que registran o autorizan por la dirección del cliente suelen leer una cabecera que añade el proxy. Esa cabecera es solo texto, así que cualquier cosa capaz de llegar directamente al origen puede reclamar cualquier dirección que quiera. Restrinja el origen para que solo la dirección del túnel del proxy pueda conectarse, y configure la aplicación para aceptar la cabecera solo 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/

Si esa petición tiene éxito desde un host que no es el proxy, el origen confía en una cabecera que debería ignorar. Arregle el listener antes de tocar la aplicación. Una denegación es un resultado mucho mejor que una línea de registro con una dirección falsificada.

Mantenga el origen accesible desde exactamente un lugar

Ate el listener del origen a la dirección del túnel o bloquéelo con un cortafuegos hacia el proxy, y luego confirme qué está escuchando realmente. Un servicio iniciado con un enlace comodín acepta conexiones en cada interfaz que tiene el host, incluida una que olvidó que era enrutable. La tabla de escucha es la verdad básica, no el archivo de configuración que pensaba aplicar. Si el enlace comodín es intencionado, el cortafuegos sigue teniendo que ser el componente que lo estrecha.

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

Haga la misma revisión para las interfaces de administración, que son la exposición accidental habitual. Luego escriba los dos modelos por separado: el sitio público a través del proxy y la interfaz de administración accesible solo por el túnel. La frase de que el servidor está detrás de una VPN no dice nada de eso.