¿Cómo maneja un proxy inverso TLS para contenedores de servidores domésticos?

Un proxy inverso maneja TLS para contenedores de servidores domésticos aceptando la conexión cifrada del navegador, presentando el certificado para el nombre de host solicitado, descifrando la solicitud HTTP, seleccionando el contenedor correspondiente y creando una conexión ascendente separada a ese servicio.

Por lo tanto, las conexiones navegador-proxy y proxy-contenedor son diferentes límites de seguridad. La primera normalmente usa un certificado confiable público o privado; la segunda puede usar una red HTTP aislada, una conexión HTTPS separada o un paso TLS cuando el backend debe mantener la clave privada.

¿Dónde termina la conexión TLS del navegador?

Con la terminación TLS, el proxy inverso termina el TLS del cliente. El navegador autentica el punto final del proxy y negocia el cifrado con él en lugar de directamente con el contenedor de la aplicación.

Por lo tanto, el proxy posee la clave privada del certificado y puede leer el método HTTP descifrado, el nombre de host, la ruta, los encabezados, las cookies y el cuerpo. Esa visibilidad le permite enrutar, autenticar, filtrar, comprimir, almacenar en caché o agregar encabezados de seguridad.

La terminación no significa que el backend posea el certificado público. Desde la perspectiva del navegador, el proxy inverso es el servidor HTTPS; desde la perspectiva del contenedor, el proxy es un nuevo cliente que realiza una solicitud separada.

¿Cómo puede un puerto HTTPS alcanzar varios contenedores?

Un nombre DNS público dirige a los clientes al proxy inverso, y los nombres de host seleccionan la ruta del contenedor correspondiente. Cada nombre de host puede tener su propio certificado y destino ascendente mientras comparte el puerto 443.

Durante el apretón de manos TLS, el cliente normalmente suministra el nombre del servidor previsto para que el proxy pueda elegir un certificado coincidente. Después de la descifrado, el encabezado HTTP Host y la ruta configurada determinan si la solicitud va a Jellyfin, Home Assistant, Vaultwarden u otro contenedor.

Una ruta predeterminada debería rechazar los nombres de host desconocidos en lugar de reenviarlos a un panel arbitrario. Centralizar la entrada no requiere que cada servicio interno sea accesible a través del proxy público.

¿Cómo se emiten y renuevan los certificados?

Los proxies inversos pueden actuar como clientes ACME, y los desafíos DNS automatizan la renovación de certificados creando un registro DNS temporal que prueba el control del dominio solicitado.

Un desafío HTTP prueba el control a través de un punto final web, mientras que un desafío DNS puede emitir certificados para servicios internos o nombres comodín sin publicar cada contenedor directamente. El método de validación cambia la exposición y los requisitos de credenciales.

La automatización traslada la expiración del certificado de una tarea manual en el calendario al estado de la infraestructura. También convierte el token API DNS del proxy, los datos de la cuenta ACME y el almacenamiento de certificados en activos sensibles que necesitan permisos restringidos y respaldo.

¿Está el tráfico encriptado entre el proxy y el contenedor?

El enlace ascendente se configura de forma independiente, por lo que los enlaces ascendentes pueden usar HTTP o HTTPS. Terminar TLS público no decide automáticamente si la conexión interna está encriptada.

HTTP simple puede ser razonable en una red de contenedores privada confinada a un host confiable, pero el proxy puede leer y modificar ese tráfico. Si el enlace ascendente cruza hosts, redes no confiables o límites de confianza más fuertes, una conexión HTTPS verificada por separado reduce la exposición.

La re-encriptación crea dos sesiones TLS y dos decisiones de certificado. El proxy debe validar el certificado del backend y el nombre esperado; simplemente habilitar HTTPS sin verificación reemplaza la encriptación con un túnel no autenticado.

¿Cómo aprende el contenedor el contexto original del cliente?

La conexión TCP ascendente se origina en el proxy, por lo que las conexiones del proxy ocultan la dirección original del cliente. Los encabezados reenviados llevan la IP del cliente, el esquema original, el nombre de host y el puerto que la aplicación necesita.

Sin el esquema HTTPS original, una aplicación puede generar redireccionamientos HTTP, marcar incorrectamente las cookies seguras o construir la URL de devolución incorrecta. Sin una dirección de cliente confiable, los registros, los límites de tasa y las políticas de acceso pueden identificar solo al proxy.

El proxy debe establecer estos valores de manera consistente, y el marco del contenedor debe configurarse para confiar en el recuento de saltos correcto o en la red del proxy. Reenviar un encabezado e interpretarlo de forma segura son tareas separadas.

¿Qué nuevo límite de confianza crea la terminación TLS?

Los clientes pueden enviar encabezados de reenvío falsificados por sí mismos, por lo que los proxies confiables deben sanear los encabezados reenviados antes de que el backend los use para decisiones de seguridad.

El acceso directo al contenedor debe bloquearse cuando la aplicación confía en la identidad proporcionada por el proxy. De lo contrario, un cliente puede evitar el proxy, enviar su propio valor X-Forwarded-For o esquema, e impersonar el contexto que la aplicación asume proviene del ingreso confiable.

el ingreso en contenedores reescribe la ruta visible del cliente. Protege las claves privadas del proxy, restringe su interfaz de gestión, expón solo las rutas previstas y monitorea la renovación de certificados y la salud aguas arriba porque el proxy ahora es una dependencia de seguridad compartida.

Preguntas Frecuentes

¿Cada contenedor necesita su propio certificado TLS público?

No cuando el proxy inverso termina TLS. El proxy puede tener certificados para varios nombres de host y reenviar solicitudes descifradas a contenedores internos separados.

¿Es HTTP desde el proxy a un contenedor siempre inseguro?

Depende del límite de confianza. Una red aislada en el mismo host tiene una exposición diferente a una red enrutada o compartida. HTTPS con verificación de certificado ofrece una protección más fuerte a través de segmentos no confiables.

¿Puede un proxy inverso enrutar HTTPS sin descifrarlo?

Sí. El paso de TLS puede enrutar usando información del apretón de manos como SNI mientras el backend termina TLS, pero el proxy pierde la visibilidad y el filtrado normales a nivel HTTP.

¿Por qué los contenedores deberían rechazar el acceso externo directo?

Cuando una aplicación confía en los encabezados reenviados, el acceso directo permite a los clientes evitar la sanitización del proxy y enviar valores falsificados de identidad, esquema o nombre de host.

Conclusión Final

Un proxy inverso maneja TLS convirtiéndose en el punto criptográfico público y creando una segunda conexión, gobernada por separado, hacia cada contenedor. La seguridad confiable depende de una correcta enrutación por nombre de host, renovación automatizada pero protegida de certificados, cifrado deliberado aguas arriba, encabezados de reenvío saneados y bloqueo de rutas que eviten el proxy confiable.