Naja, du brauchst halt vermutlich noch ein Zertifikat.
Wenn es dann noch keine Warnung im Browser geben soll braucht es natürlich ebenfalls noch einen FQDN (lösen wir hier so).
Bei Let’s Encrypt gibt es aber halt leider Limits welche die schöne Idee ein valides Zertifikat pro Knoten zu haben etwas kaputt machen. Da müsste man dann also vermutlich mal die Erhöhung des Limits anfragen.
Aktuell ist der Port noch geschlossen, daher liegt eine Fehlkonfiguration vor.
daher bekomme ich kein Zertifikatsfehler sondern ein Verbindungsaufbau abgelehnt.
ich dachte ich kann das Zertifikat umgehen durch die 301 Umleitung.
list listen_http '0.0.0.0:80'
list listen_http '[::]:80'
list listen_https '0.0.0.0:443'
list listen_https '[::]:443'
bei der firewall sieht’s plausibel aus.
config rule
option name 'https'
list proto 'tcp'
option dest_port '443'
option target 'ACCEPT'
Also nochmal in Kurzform (was aber zumindest Dir ja klar ist, aber falls noch andere drüber stolpern sollten)
den Firewall-Port freischalten
dem Webserver sagen, dass er auch auf tls/443 antwortet
überhaupt irgendeine form von tls auf den Router bringen
überlegen wie man das mit dem Zertifikat machen möchte und
schauen ob das Flash des Routers überhaupt reicht dafür
automatische/erzwungene Umleitung von http auf https ist übrigens ein zweischneidiges Schwert, weil evtl. andere Gerät im Netz kein TLS können und bei so einem redirekt nicht hinterkommen. z.B. wenn andere Gluon-Nodes von diesem Router per Script Infos abfragen. Oder irgendwelche ESPs (ja, soll Leute geben, die soetwas basteln. Ist aber natürlich kein Standard. Aber da wir uns hier in einem Szenario bewegen „wo Menschen im Freifunk auch mal basteln“, da sei das sicherheitshalber erwähnt.)