-
@alcamar
Das HAproxy Log könnte hierunter zu finden sein:
-
@viragomann die meinte ich, die keinen zeitlichen Bezug zu meinen Anmeldeversuche auf der App haben.
Ein ähnliches Verhalten habe ich auch mit einer anderen App. Die verbindet sich mit Kameras und man kann wahlweise Hostname und IP-Adresse eingeben. Bei Hostname ist das gleiche wie mit der ersten App für Hausautomation. Wenn ich allerdings die IP-Adresse nehme und VPN aufgebaut ist, kann ich mich auf den Kameras anmelden. Habe ich einen Knoten in der Namensauflösung? Leider geht die Kombi IP und VPN mit der ersten App auch nicht.
-
@alcamar
Lief der Proxy auf der Synology auch auf SSL und Port 443? -
@viragomann Die Einstellungen habe ich noch. Was ich nicht analog im HAProxy identifizieren kann, ist ein Haken bei "HSTS aktivieren" in der Synology.
Sonst sind dort die Kameras und die Hausautomation drin. Die Funktionsweise war auch die gleiche wie auf HAProxy. Wenn über Port 80 etwas kommt, wird es auf Port 443 weitergeleitet und dort dann an den entsprechenden Server (Hausautomationsserver).
Bei den Kameras ist es etwas anders gewesen:
Die Kameras kamen auf Port 80 und wurden auf Port 80 belassen. Nur der Name änderte sich. Damit zielt Deine Frage in die richtige Richtung für die Kameras. -
@alcamar
HSTS kannst du im Backend aktivieren. Einfach die gewünschte Zeit im Feld eintragen.
Allerdings würde ich das erst machen, wenn alles andere funktioniert.Dass das nicht aktiv ist, macht es jetzt nicht schlechter. Es weist die Browser / Clients lediglich an, diese Seite nur noch per HTTPS aufzurufen.
Heißt also, was zuvor über SSL gelaufen ist, geht jetzt auch nur so.Vielleicht kannst du den Zustand von zuvor erst mal in HAproxy nachstellen.
-
@viragomann Das war mein Ziel. Wenn ich das rekapituliere, gibt es eine Stelle, die ich seit Deiner Frage mit dem Port prüfe, aber intellektuell noch nicht verarbeiten kann. Im Frontend bei HAProxy habe ich ein HTTP to HTTPS redirect, der alle Anfragen auf https biegt.
Mit dem Browser klappt der Zugang auf diesem Weg. Die Apps hingegen gehen nicht. Kann ich diese Redirect anders lösen, ohne gleich alles neu zu stricken? -
@alcamar
Ja, vermutlich schon. Aber ist es überhaupt das Problem?Kann die App HTTPS?
Wenn ja, vertraut sie dem Zertifikat?Ggf. leite mal Port 80 aufs Backend zum Test.
-
@viragomann Die App verlangt neben der Adresse auch den Port 443. Damit müsste sie ja HTTPS können, oder? Aus der Fehlermeldung der App würde ich nicht zwangsläufig auf ein Zertifikatsproblem schlussfolgern. Dort heisst es sehr "hilfreich":
'Es gab einen Fehler beim Verbinden. Dies könnte ein Problem des Servers oder der App-Einstellungen sein.'Wie leite Port 80 auf Backend? Im http-https die Action von rule:scheme https entfernen?
-
@alcamar said in App kommt nicht durch HAProxy:
Die App verlangt neben der Adresse auch den Port 443. Damit müsste sie ja HTTPS können, oder?
Wie? Der Port muss gesondert zusätzlich angegeben werden?
Zwingend ist es nicht, aber doch anzunehmen, wenn sie sich bei Schema HTTPS bzw. Port 443 nicht beklagt.
Aus der Fehlermeldung der App würde ich nicht zwangsläufig auf ein Zertifikatsproblem schlussfolgern. Dort heisst es sehr "hilfreich":
'Es gab einen Fehler beim Verbinden. Dies könnte ein Problem des Servers oder der App-Einstellungen sein.'
Je nach Qualität der App kann das alles mögliche bedeuten.
Wie leite Port 80 auf Backend? Im http-https die Action von rule:scheme https entfernen?
Ja, und eine Weiterleitung auf das Backend im Port 80 Frontend einrichten.
-
@viragomann Die App ist keine womit man zum Mond fliegen könnte, aber sie macht das wenige. :-) Die Einstellungen sind überschaubar:
Der interne Port ist optional. Den bestimme ich ohnehin im HAProxy abhängig von der Adresse.Da HAProxy grundsätzlich geht, muss ich schauen, wie ich die Einstellungen beibehalte und die Portweiterleitung testen kann. Die ersten Versuche in diese Richtung waren nicht von Erfolg gekrönt.
-
@alcamar
Nachdem die App einen SSL-Schalter hat, sollte das auch funktionieren.
Ob HTTPS aber das Zugriffsprotokoll ist, geht hier nicht hervor.
Allerdings hast du anfangs erwähnt, im Browser funktioniert genau diese Adresse?Der interne Port ist optional. Den bestimme ich ohnehin im HAProxy abhängig von der Adresse.
Damit ist also der Part gemeint, auf den der Server tatsächlich lauscht?
-
@alcamar und warum ist in der App dann überhaupt ein interner Port konfiguriert?
Das klingt eher wie die App von HomeAssistant, die unterscheiden will/kann ob der Zugriff von extern geht oder intern und je nachdem andere Verbindungseinstellungen nutzt. Und ggf. versucht er es dann via Domain+8084 und das klappt dann natürlich nicht.
Ich würde wenn es im Browser geht mal mit Port 443 als internem oder gar keinem probieren, damit er sauber Domain+443 nutzt.
-
@viragomann Der Hausautomationserver bietet je nach Client (Browser, Tablet, Handy) verschiedene Ports (8083-8085). Die App nutzt den Handy-Port, wenn er angegeben wird. Man kann diesen also optional in der App angeben. Ich habe das aber mit dem Namen gelöst. M.Name.de, T.Name.de und Name.de landen auf den richtigen Port, ohne diesen explizit anzugeben. In der App haber ich den eingetragen, aber der Proxy holt mit dem Namen den richtigen Backend und Port.
-
@jegr das ist so einen App. Mit Browser komme ich mit 443 problemlos an Server dran. In der App ist es ein Muss-Feld. Also muss ich diesen angeben. Das war bisher auch so im alten Reverse-Proxy.
Ich habe alle Portkombinationen erfolglos ausprobiert -
@alcamar said in App kommt nicht durch HAProxy:
Der Hausautomationserver bietet je nach Client (Browser, Tablet, Handy) verschiedene Ports (8083-8085). Die App nutzt den Handy-Port, wenn er angegeben wird. Man kann diesen also optional in der App angeben. Ich habe das aber mit dem Namen gelöst. M.Name.de, T.Name.de und Name.de landen auf den richtigen Port, ohne diesen explizit anzugeben.
Und das lief im Synology ebenso über die Namen?
Mir ist nicht klar,. warum das überhaupt über einen HTTP-Proxy laufen muss, wenn die App ohnehin auf einen eigenen Port geht, der in dieser nur einmal eingestellt werden muss. Mir wäre ziemlich gleichgültig, welcher das ist.
-
@viragomann das lief über die Namen. Ich habe auf der Fritz nur Port 443 und Port 80 offen und VPN. Das ist auch meine Motivation für einen Proxy. Vor Jahren hatte ich alle Ports für die Hausautomation offen. Mit dem Proxy habe ich alle geschlossen.
-
@alcamar Ja aber wenn du das über den Namen gelöst hast, warum dann nicht so:
- m.sub.domain.de (wird ja nur für Mobile benutzt?)
- extern auflösen auf IP der Fritte
- checken, dass 443 dann auf den Homeserver weitergereicht wird an den richtigen Port
- intern direkt auf den Homeserver auflösen lassen via DNS Override!
- dadurch intern kein Proxy nötig, weil er direkt mit m.sub.domain.de:8084 an den Server rangeht/rankommt, während er extern dann :443 nutzt und via Proxy umgesetzt wird.
Und die anderen Kisten nutzen dann ja eh eine andere Domain und werden entsprechend anders gehandelt?
Damit hast du extern immer noch nur 80/443 offen und intern verbindest du dich ohne Proxy direkt mit der Kiste was eh schneller sein dürfte. Und gut ist :) -
@jegr Hallo Jens, danke. Ich werde das alternativ prüfen. Im gleichen Augebenblick, wie Dein Post kam, aber ich eine "Lösung"., die ich zwar noch nicht kapiere, und eher zufällig gefunden habe. Wenn ich beim Default Backend den Hausautomationsserver eintrage, macht die App keine zicken. ob das wirklich eine Lösung ist, weiß ich nicht, weil vielleicht geht jetzt irgendetwas anderes nicht. Muss ich prüfen...
-
@alcamar
Das deutet darauf hin, dass sonst für die Zugriffe vom Handy keine Regel angewandt wurde. -
@jegr die m.sub.domain.de, die nur das Handy nutzt, lässt sich als Host im DNS HostOverride nicht eingeben. Der Hostname muss wohl ohne "." sein. Mein m.sub will er nicht.
Ich habe das Prinzip auf die Kamera-App angewandt, wo ich ein sehr ähnliches Problem habe. Exterene Auflösung klappt, 443 landet auf auf der pfsense, wo ich ein Host Override auf die Cam1 habe. Trotzdem meldet sich die App nicht an der Cam an.
