Gately v0.6.5.5 veröffentlicht

11. November 2026

v0.6.5.5 herunterladen · GitHub Release

Port-Knocking (#80)

Das neue Modul Port-Knocking (in der Gruppe „Netzwerk“) bietet eine mit dem fwknop-Client kompatible Single Packet Authorization (SPA): Geschützte Ports sind von außen nicht erreichbar, der Client sendet zuerst ein verschlüsseltes, authentifiziertes Knock-Paket, und nach erfolgreicher Prüfung wird nur diese Quelladresse für begrenzte Zeit freigegeben. Das eignet sich für direkten SSH-Zugang, sodass scp, Remote-Entwicklung aus der IDE und andere Anwendungen, die das Web-Terminal nicht abdeckt, sicher aus dem Internet verbinden können.

• Sicher: Pakete werden mit AES verschlüsselt und mit HMAC authentifiziert, der HMAC wird vor der Entschlüsselung geprüft; jedes Paket ist nur einmal verwendbar (Replay-Schutz), und Pakete mit einem Zeitstempel außerhalb der Gültigkeit (standardmäßig 120 Sekunden) werden abgelehnt; eine Regel kann den Benutzernamen einschränken und verlangen, dass das Paket die freizugebende Adresse angibt;
• Firewall-Blockierung: Knock-Pakete werden standardmäßig auf UDP 62201 empfangen; eine Regel kann die geschützten Ports in die System-Firewall schreiben (nftables, bei Kernen ohne nf_tables iptables + ipset), und eine erfolgreich klopfende Adresse kann während der Freigabedauer (standardmäßig 30 Sekunden) neue Verbindungen aufbauen; bestehende Verbindungen bleiben unberührt;
• Nicht aussperren: „Interne Netze ohne Knock“ ist standardmäßig aktiv, private Adressen und die öffentlichen IPv6-Präfixe der lokalen Schnittstellen brauchen also keinen Knock (der Carrier-Grade-NAT-Bereich 100.64.0.0/10 gehört nicht dazu), und eine Ausnahmeliste lässt sich ergänzen;
• Gately-Einstiege nach Knock freigeben: Die IP-Zugriffskontrolle von Portweiterleitung, Protokollrouting und der eingebauten STUN-Weiterleitung kann „Knock erforderlich“ wählen; Gately entscheidet selbst, ohne Firewall-Rechte, also auch unter Windows, macOS und in Containern ohne NET_ADMIN;
• Nur ein offener Port: Das Protokollrouting kann pro Route einen Knock verlangen und erhält eine Route „Port-Knocking“ (Protokoll spa), die Knock-Pakete per TCP empfängt (fwknop -P tcp); derselbe Port nimmt den Knock an und lässt danach SSH und andere Routen durch;
• Einbruchschutz: Abgelehnte Knocks können als Ereignisquelle dienen, die eingebaute Vorlage „Port-Knocking fehlgeschlagen“ sperrt standardmäßig nach 5 Fehlschlägen in 10 Minuten für einen Tag; UDP-Pakete, die die HMAC-Authentifizierung nicht bestehen, werden nur gezählt und nicht verwendet, weil ihre Quelle gefälscht sein kann; erfolgreiche und abgelehnte Knocks lassen sich in der Benachrichtigungszentrale abonnieren;
• Client-Einrichtung: „Client“ auf der Regelkarte erzeugt die fwknop-Befehlszeile und einen ~/.fwknoprc-Abschnitt, die Schlüssel haben dasselbe Format wie bei fwknop -k.

Siehe Port-Knocking.

Wake-on-LAN: Fern-Herunterfahren über einen Agenten

Das Fern-Herunterfahren erhält die Methode „Agent“: Installieren Sie einen Agenten unter Windows, Linux, macOS oder OpenWrt (als geplante Aufgabe oder als systemd- / OpenRC-, launchd- oder procd-Dienst). Der Agent fragt Gately per Long Polling nach Befehlen, das Gerät braucht also keine offenen Ports, und Gately speichert keine Anmeldedaten des Geräts.

• Der Agent führt nur drei feste Aktionen aus: Herunterfahren, Neustart und Ruhezustand; die API POST /api/wol/devices/{key}/shutdown nimmt {"action": "reboot"} oder {"action": "sleep"} für Neustart oder Ruhezustand an;
• Ein Befehl gilt 10 Sekunden nach dem Senden: Der Agent bestätigt ihn zuerst und führt ihn erst nach der Antwort von Gately aus; ist der Agent offline, schlägt die Anfrage sofort fehl und wird nie für die nächste Verbindung vorgemerkt;
• Der Installationsbefehl prüft zuerst die SHA-256-Prüfsumme des Skripts und bricht bei Abweichung ab; Zugangsdaten werden im Anfragekörper und in Umgebungsvariablen übergeben und erscheinen nie in URLs oder Befehlszeilenargumenten;
• Die Gerätekarte zeigt, ob der Agent online ist, mit dem gemeldeten Hostnamen, System und der Quelladresse; nach dem Neuerzeugen der Zugangsdaten wird der alte Agent sofort getrennt.

Neu ist außerdem die Methode „HTTP-Anfrage“ für Home Assistant, smarte Steckdosen und andere Dienste mit HTTP-API: URL, Methode, Header und Body eingeben, ein Statuscode 2xx gilt als Erfolg. Siehe Wake-on-LAN · Agent.

Web-Dienst: angemeldeten Benutzern vertrauen (#81)

Sites erhalten die Option „Angemeldeten Benutzern vertrauen“: Besucher, die von der Gately-Authentifizierung dieser Site authentifiziert wurden, umgehen die WAF, und ihre Anfragen werden von der Web-Pfadsondierung des Einbruchschutzes nicht gezählt, etwa wenn die WAF oder Köderpfad-Regeln eigene Benutzer blockieren. Vertraut wird Sitzungen der Web-Authentifizierung, einzeln in der Zulassungsliste aufgeführten Identitäten der Drittanbieter-Anmeldung, dem Single Sign-on gemeinsamer Benutzer und geprüfter Basic-Authentifizierung; Identitäten, die über einen Platzhalter Anbieter:* wie github:* zugelassen sind, wird nicht vertraut. Sperren, IP- und Länder-Zugriffskontrolle sowie Ratenbegrenzung gelten weiterhin. Siehe WAF-Firewall.

Nach Benutzer verteilen für weitere Site-Typen (#79)

Auch Sites vom Typ Weiterleitung, statische Dateien, Navigationspanel und fester Text können nach authentifiziertem Benutzer verteilen: Benutzer, die einer Regel entsprechen, gehen per Reverse Proxy an das Backend der Regel, alle anderen Besucher werden wie bisher nach dem Site-Typ behandelt, zum Beispiel gelangen Administratoren in die Verwaltung, während andere angemeldete Benutzer auf eine Infoseite weitergeleitet werden. Siehe Web-Dienst · Nach Benutzer verteilen.

Anfragen von Administratoren umgehen die WAF der Site

Wird die Verwaltungsoberfläche über eine Site mit WAF aufgerufen, umgehen Anfragen mit einer gültigen Administratorsitzung dieser Instanz die WAF der Site, sodass das Speichern von Konfigurationen mit Dateipfaden, HTML oder Skripten nicht mehr von CRS-Regeln mit 403 blockiert wird. Nur-Lese-Konten, Besucher und Verwaltungsanfragen an andere Instanzen werden weiterhin geprüft.

Fehlerbehebungen

• OpenWrt-Pakete (#82): apk in OpenWrt 25.12 ersetzt die Dateien auch nach fehlgeschlagener Architekturprüfung, sodass ein arm64-Paket im Offline-Ordner beim Einbinden von Paketen in ein Firmware-Image dazu führte, dass das Programm nach dem Flashen in einer Absturzschleife lief. Installiert apk jetzt ein Paket für eine andere Architektur, bleibt das laufende gately-Programm erhalten, und eine Meldung weist darauf hin. Legen Sie beim Einbinden in die Firmware oder bei der Offline-Installation nur das gately-Paket für die Gerätearchitektur in den Ordner; siehe Installation · OpenWrt.

Weitere Verbesserungen

• Die API-Dokumentation listet die Modul-Endpunkte ohne Anmeldung (etwa Abfrage, Bestätigung und Skript-Download des Wake-on-LAN-Agenten), vermerkt, dass sie die eigenen Zugangsdaten des Moduls verwenden, und ergänzt die Felder von Port-Knocking.

Hinweise zum Upgrade

• Docker: neues Image ziehen und den Container neu erstellen. OpenWrt: das neue .apk / .ipk über das alte installieren und bei Bedarf der LuCI-Seite auch luci-app-gately in derselben Version installieren. fnOS: das neue .fpk manuell im App Center installieren. Andere Installationen lassen sich unter „Systemeinstellungen“ online aktualisieren.
• Die Firewall-Blockierung von Port-Knocking braucht root oder CAP_NET_ADMIN; unter Docker sind das host-Netzwerk und cap_add: NET_ADMIN nötig.