Gately v0.6.0.3 veröffentlicht

28. Oktober 2026

Dies ist ein Fehlerbehebungs-Update der Reihe v0.6.0 ohne neue Funktionen. Nutzern einer Kette „öffentliches Gately → Tunnel → Gately im LAN“ wird das Upgrade empfohlen.

v0.6.0.3 herunterladen · GitHub Release

HTTPS über vertrauenswürdige PROXY-Quellen

Terminierte ein öffentliches Gately TLS und leitete Klartext-HTTP mit PROXY-v2-Header über einen frp-tcp-Tunnel an ein Gately im LAN weiter, sah das Gately im LAN die öffentliche Adresse des Besuchers und vertraute X-Forwarded-Proto: https nur vom lokalen Host und aus privaten Netzen. Solche Anfragen galten daher als Klartext: Der OIDC-Identitätsanbieter mit https-Aussteller leitete Anmelde-, Autorisierungs- und Token-Anfragen um oder lehnte sie ab, und Sitzungs-Cookies für Web-Authentifizierung, geteilte Benutzer, Single Sign-on und Freigabelinks hatten kein Secure.

X-Forwarded-Proto: https auf Verbindungen aus einer „vertrauenswürdigen PROXY-Quelle“ wird jetzt ebenfalls übernommen und einheitlich verwendet für:

• die HTTPS-Prüfung des OIDC-Ausstellers und das Secure-Flag aller Sitzungs-Cookies;
• die Rücksprungadresse der Anmeldung über Drittanbieter und das an Forward-Auth-Dienste übergebene Schema;
• Ports, die Klartext-HTTP auf HTTPS umleiten, leiten solche Anfragen nicht mehr um, damit keine Weiterleitungsschleife entsteht;
• Reverse-Proxy-Sites mit „X-Forwarded-* hinzufügen“ senden X-Forwarded-Proto: https an das Backend, sodass Backend-Apps korrekte https-Links erzeugen.

Die Einrichtung beschreiben die Dokumentationen OIDC-Identitätsanbieter und Webdienst: Auf der öffentlichen Site „X-Forwarded-* hinzufügen“ und „PROXY v2 an das Backend senden“ einschalten, am Listener des Gately im LAN das PROXY-Protokoll annehmen und die lokale Quelladresse des Tunnels zu den vertrauenswürdigen PROXY-Quellen hinzufügen. Von nicht vertrauenswürdigen Quellen und öffentlichen Besuchern wird der Header weiterhin ignoriert.

Port belegt beim Neustart eines Listeners

Wurde ein Webdienst-Listener, der WebDAV-Dienst oder der temporäre HTTP-01-Listener direkt nach dem Start gestoppt oder neu gestartet, konnte der alte Port noch belegt sein, und das erneute Lauschen schlug gelegentlich mit „address already in use“ fehl (etwa beim zweimaligen Speichern der Listener-Einstellungen). Der Listener wird beim Stoppen jetzt synchron geschlossen, sodass ein Neustart sofort funktioniert.

Hinweise zum Upgrade

• Docker: neues Image ziehen und den Container neu erstellen. OpenWrt: das neue .apk / .ipk über das alte installieren. fnOS: das neue .fpk im App Center installieren. Andere Installationen lassen sich in den Systemeinstellungen online aktualisieren.