keine HTTPS via Docker

[saho1]

Hallo @ all,

egal welche Container ich erstelle, es werden keine HTTPS-Ports weitergereicht.

Konkret aktuell bei ecoDMS und ioBroker. Egal ob ich die Ports manuell Eintage oder via "Identisch wie Host" anbinde. Ich bekomme keine Verbindung zu HTTPS-Seiten. Eine Auswertung via nmap hat ergebenen, dass die entsprechenden Ports auf der DS auch nicht offen sind.
Die Container laufen, nur es wird keine Verbindung via ssl aufgebaut, wie auch wenn der Port nicht offen ist, er hat ja kein Ziel.

Bei Container die unverschlüsselte Konfigurationsseiten haben funktioniert alles auf Anhieb und da sind auch die entsprechenden Ports offen.

Zu den Rahmenbedingungen:
Bin jüngst von einer DS212J auf die 218+ umgezogen, keine Ahnung ob dies von Relevanz ist.

Evtl. sehe ich den Wald vor Bäumen nicht und wäre über einen Hinweis dankbar.

Grüße

Saho

 

[Benares]

Am besten leitest du alles über den Reverse-Proxy der DS. Dann hast du eine Stelle, wo du das/die Zertifikat(e) pflegen musst und die Umsetzung https->http erfolgt und brauchst nicht für jeden Container was eigenes.
Lies mal z.B. hier.

 

[saho1]

Herzlichen Dank für deine Antwort!

Das Problem ist doch schon dass vom Docker der Zielport nicht geöffnet wird.

Am Beispiel ecoDMS:
Im Container unter Details steht das der lokale Port 17001 an den Container-Port 17001verbunden ist.


Schaue ich jetzt via nmap auf der DS ist dieser Port aber nicht geöffnet und wäre somit ja auch nicht für den Reverse Proxy erreichbar.

Dennoch habe ich grad ein ReverseProxyProfil angelegt


Wie erwartet kann ich die Seite unter https://ip-der-ds:150 nicht erreichen

Saho

 

[Benares]

Lerne den Reverse-Proxy erst mal kennen. Er triggert auf den "Hostname" der Quelle und leitet ihn ans Ziel weiter.
In deinem Fall müsstest du als Quelle einen Hostname wählen, für den auch das Zertifikat gilt, und den dann auch verwenden. Ziel ist dann HTTP(nicht HTTPS)/localhost/17001

 

[Fusion]

17001 ist der Client Port.
Webserver ist 17004.
Das Image bietet gar keinen https Port laut Install Doku.

Zudem stimmt eventuell was mit dem Image nicht, weil auch auf 8080 kein Web-interface lauscht. Jedenfalls habe ich das schon auf zwei DS zuletzt gesehen, aber keine Ursachenforschung betrieben.

 

[saho1]

Herzlichen Dank für deine Mühe!

Das habe ich schon verstanden. Nur wie soll eine Umleitung via Reverse Proxy auf einen Port funktionieren der schon intern nicht erreichbar/offen ist?

Wo ist hier mein Denkfehler?

Um eine externe Erreichbarkeit geht es mir gar nicht. Ich erreiche den ecoContainer schon im lokalen Netzwerk nicht unter ip-derDS:17001. Wie soll dann eine Umleitung diesen Port erreichen?

@Fusion der Port 17004 ist genauso nicht erreichbar bzw. offen. Dies hatte ich mir bei der Doku nämlich auch schon gedacht.

Sorry und Danke

Saho

 

[Benares]

Na ja, http://IP-der-DS:<Port> muss erst mal klappen, bevor man einen Reverse-Proxy mit https darüber setzt. Dafür kenne ich aber ecoDMS zu wenig.

 

[Fusion]

Wie gesagt, ich denke mit dem ecodms docker image selbst stimmt etwas nicht. Ob es das Image selbst ist, oder nur im Zusammenhang mit der Syno-docker etc habe ich noch nicht untersucht.
17001 ist kein Web-interface.

 

[saho1]

@Benares: ganz da war ja mein Verständnisproblem, aber denke dies ist geklärt, habe mich wohl nicht klar genug ausgedrückt

Gleiche Thematik habe ich mit dem ioBroker Container. Beispielsweise ccuHistorian (kein HTTPS) läuft ohne Probleme.

Habe mal das LOG von ecoDMS gescannt:

Sobald ich eine Connection auf einen der geöffneten Ports aufmache kommt folgende Exception im LOG von ecoDMS:

2020-06-16 18:07:12,663 ERROR |Could not accept connection from tcp://172.21.0.1:34364 : {} 
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
	at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
	at sun.security.ssl.InputRecord.read(InputRecord.java:527)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:750)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
	at org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedOutputStream.java:115)
	at java.io.DataOutputStream.flush(DataOutputStream.java:123)
	at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:194)
	at org.apache.activemq.transport.AbstractInactivityMonitor.doOnewaySend(AbstractInactivityMonitor.java:335)
	at org.apache.activemq.transport.AbstractInactivityMonitor.oneway(AbstractInactivityMonitor.java:317)
	at org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:181)
	at org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:84)
	at org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:74)
	at org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)
	at org.apache.activemq.broker.TransportConnection.start(TransportConnection.java:1066)
	at org.apache.activemq.broker.TransportConnector$1$1.run(TransportConnector.java:218)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Also kommt ja der Request an. Gleicher Container läuft jedoch auf einer anderen DS (Freund von mir) mit nach außen hin identischer Konfiguration ohne Probleme, weswegen ich den Container ausschließen möchte und eine interne Sache in dem Docker vermutet hatte

@Fusion: den Port 17004 umgeleitet auf 8080 gem. Doku erreiche nur leider ebenso nicht

Saho

 

[Fusion]

Gleiches Image... OK.
Der Container wird ja erst auf der DS erzeugt.

Was meinst du mit 'docker intern'?

Dann hast du doch prima Voraussetzungen, dass ihr mal alle Einstellungen zum Container abprüft, Ordner, Berechtigungen etc.
Irgendwo muss ja ein Unterschied sein.

 

[saho1]

Und genau diese Einstellungen des Container haben wir bereits abgeglichen. Einzig was wir noch nicht verglichen haben ist die Versionsnummer des Docker-Paket von Sync. Mag sein das mein Bekannter noch auf einer älteren Version unterwegs ist (er ist etwas "Updatescheu").

Mit "Dockerintern" meine ich, dass ggf meine Installation/Version des Docker anders ist. Merkwürdig ist nur, dass ich bei ioBroker das identische Verhalten (keine Erreichbarkeit via http(s)) habe. Hier habe ich nur keine so genaue Auswertemöglichkeit bzw habe sie noch nicht gefunden.

Ich werde berichten wenn ich mit ihm gesprochen habe...

 

[saho1]

Das Problem lag am Image von ecoDMS und in erster Line zwischen den Ohren des Nutzer!!!

Gem. Doku von ecoDMS ist der Webdienst automatisch aktiviert. Leider ist bei dem aktuellen Image nicht so!
Was ich nicht wußte (ist meine erste Nutzung von ecoDMS) dass es einen Desktopclienttool gibt (RTF!!!) und man mit diesen den Webservice freigeben kann.

Entschuldigt das durcheinander und vielen Dank für eure Unterstützung!!!

Gruß

Saho

 

[Fusion]

Eine Frage dazu. Mit welchen credentials hast du den connector / desktop client verbunden? Mit den erwarteten ecodms/ecodms hat es auf 17001 nicht funktioniert mit allinone 1809 Image.