Gately v0.6.0.3 publicado

28 de octubre de 2026

Esta es una actualización de correcciones de la serie v0.6.0, sin funciones nuevas. Se recomienda actualizar a quienes usan una cadena «Gately público → túnel → Gately de la LAN».

Descargar v0.6.0.3 · GitHub Release

HTTPS reenviado por orígenes PROXY de confianza

Cuando un Gately público terminaba TLS y reenviaba HTTP en claro con una cabecera PROXY v2 a un Gately de la LAN por un túnel tcp de frp, el Gately de la LAN veía la dirección pública del visitante y solo confiaba en X-Forwarded-Proto: https del propio equipo y de redes privadas, así que trataba esas peticiones como HTTP en claro: el proveedor de identidad OIDC con emisor https redirigía o rechazaba las peticiones de inicio de sesión, autorización y tokens, y las cookies de sesión de autenticación web, usuarios compartidos, inicio de sesión único y enlaces compartidos no llevaban Secure.

Ahora también se acepta X-Forwarded-Proto: https en las conexiones que llegan desde un «Origen PROXY de confianza», y se usa de forma coherente para:

• la comprobación HTTPS del emisor OIDC y el indicador Secure de todas las cookies de sesión;
• la dirección de retorno del inicio de sesión con terceros y el esquema que se pasa a los servicios de autenticación reenviada;
• los puertos que redirigen HTTP en claro a HTTPS ya no redirigen estas peticiones, lo que evita un bucle;
• los sitios de proxy inverso con «Añadir X-Forwarded-*» envían X-Forwarded-Proto: https al backend, para que las aplicaciones generen enlaces https correctos.

La configuración se explica en la documentación de proveedor de identidad OIDC y Servicio web: en el sitio público activa «Añadir X-Forwarded-*» y «Enviar PROXY v2 al backend», en el listener del Gately de la LAN activa la recepción del protocolo PROXY y añade la dirección de origen local del túnel a los orígenes PROXY de confianza. La cabecera sigue sin aceptarse de orígenes no confiables ni de visitantes públicos.

Puerto en uso al reiniciar un listener

Si un listener del Servicio web, el servicio WebDAV o el listener temporal de HTTP-01 se detenía o reiniciaba justo después de arrancar, el puerto anterior podía seguir ocupado y volver a escuchar fallaba a veces con «address already in use» (por ejemplo, al guardar dos veces seguidas los ajustes del listener). Ahora el listener se cierra de forma síncrona al detenerse y el reinicio funciona al momento.

Notas de actualización

• Docker: descargue la nueva imagen y vuelva a crear el contenedor. OpenWrt: instale el nuevo .apk / .ipk sobre el anterior. fnOS: instale el nuevo .fpk en el Centro de aplicaciones. El resto de instalaciones puede actualizarse en línea desde Ajustes.