ich habe versucht, eine “externe Seite” in die Cloud einzubinden, die App in NC heißt “external sites”. (Zweiter Button oben)
Ich habe das Problem, dass ich 404-Nachrichten bekomme, v.a. in den Logs des externen server tauchen Anfragen auf, die sicher an die Cloud gerichtet sein sollten, z.B.
Daher funktioniert die Cloudseite nicht mehr, bis ich im Browser “Umschalt”-STRG und R drücke.
Leider funktioniert es innerhalb der Schule (!)
Meine Situation ist: beide Server stehen in der DMZ, beide werden mit FQDN (bzw. Alias) angesprochen (cloud.meineschule.de und docker.meineschule.de als externe seite)
Hat jemand eine Idee, woher die Verwirrung kommt? Offensichtlich weiß jemand (browser? cache? haproxy auf dem IPFire? cloudserver?) nicht, mit wem er jetzt grade reden soll.
sehr verrückt ist:
Wenn ich die externe Seite in meiner privaten NC (mit privater Domäne) einrichte, dann kann ich ohne Probleme zwischen den Apps wechseln. Im Log (von docker.schule.de) kommt genau das an, was soll.
ebenso unterstützt mein cloud.privat.de scheinbar kein HTTP/2
Sobald ich google-chrome --disable-http2 starte,funktioniert alles, wie es soll. Die neue Technik (zusammen mit der alten) ist also Auslöser!
Wenn man nämlich die HTTP-Request-Header anschaut, dann fällt auf, dass der Chrome gar kein “Host: cloud.meine-schule.de” Header mehr schickt, stattdessen so Pseudo HTTP/2-header: F12 im Chrome zeigt:
Sehr schön, jetzt sind beide webserver mit http2 enabled, allerdings geht es immernoch nicht.
Jetzt funktioniert die Cloud einwandfrei. Sobald ich auf die “externe Seite” gehe, bekomme ich im Frame ein 404, “The requested URL /ivo was not found on this server.” irrsinnigerweise mit der Meldung, dass “Apache/2.4.29 (Ubuntu) Server at docker.schule.de Port 443” dies gemeldet hätte. Tatsache ist, dass eine 404-Nachricht nur in der “cloud.schule.de” geloggt wird.
Langsam vermute ich, das hängt mit meinem SSL-Zertifikat zusammen, welches für beide Domänen als Alternative-Name eingetragen ist und geht deswegen so fundamental schief.
VG, Tobias
habe den proxy-server traefik durch nginx ersetzt [1], der zwischen mir und em docker.schule.de stand, weil ich bei traefik http/2 nicht abschalten konnte.
ohne http/2 auf dem docker.schule.de funktionierte es nun, hurra!
Jetzt noch folgendes Experiment: neues Lets encrypt zertifikat für docker.schule.de alleinig erzeugt [2], während die cloud.schule.de das alte LE-Zertifikat behielt, welches mit SAN auf alle beide (und mehr) hostnamen ausgestellt war. Jetzt http/2 bei beiden domänen wieder eingeschalten: tut weiterhin.
Fazit: Wer http/2 verwendet (zufällig, oder absichtlich), der muss darauf achten, dass miteinander verknüpfte Domänen nicht im selben Zertifikat (SAN) stecken. Mit “Verknüpfen” ist hier ein cross-site-aufruf gemeint. Evtl. betrifft das auch Wildcard-Zertifikate?
Fazit 2: Jetzt hab ich einen nginx-proxy mit LE-Zertifikatserstellung und http/2 Beschleunigung für meine Cloud, auch nicht schlecht.
Fazit 3: Man sollte also darauf achten, ein LE-Zertifikat pro Domäne zu erstellen. Evtl. geht das nicht immer, dann sollte man doch einen zentralen reverse-proxy besitzen, der sich auch um individuelle LE-Zertifikate kümmert.