ElabNET Technik Forum

Bisher hatte ich das auch immer so wie Göran gehandhabt und habe mich mal dran gemacht, wie Yves im Post #8 beschrieben hat zu testen.

Webinterface des Dockers ist auf Port 8080 erreichbar, Mappen tue ich diesen auf 9082, Portainer zeigt 172.17.0.6 als IP.
Richte ich dann den Reverse Proxy ein, kann ich das mit der IP aus Portainer und dem Port 9082 machen oder auch mit Port 8080 (hatte Matthias @ms20de mal in einem anderen Post geschrieben, wäre wohl eigentlich richtig.

Ergebnis:
1. http://[IP-TWS]:9082 funktioniert und zeigt das Webinterface, aber das nutzt dann ja auch nicht den Proxy. Alles normal bedienbar.
2. http://172.17.0.6:9082 im Proxy angegeben und mit https://[IP-TWS]/proxy/dockername ergibt "502 Bad Gateway (nginx)"
3. http://172.17.0.6:8080 im Proxy angegeben und mit https://[IP-TWS]/proxy/dockername öffnet das Webinterface, aber total verzerrt, mit falschem (quasi kein) Design und Popups können auch nicht geöffnet werden. Unbrauchbar leider. Slash am Ende im Reverse-Proxy und im Browseraufruf machen keinen Unterschied. Alle Varianten probiert.
Mit oder ohne Authentifizierung ändert auch nichts.

Nun bin ich wieder mit dem Latein am Ende und würde es so lassen, wie vorher, mit eigener IP. Eigentlich schade, aber ich bekomme es einfach nicht zum laufen.

Hi

Marino hat geschrieben: ↑Sa Sep 14, 2024 4:19 pm Bisher hatte ich das auch immer so wie Göran gehandhabt und habe mich mal dran gemacht, wie Yves im Post #8 beschrieben hat zu testen.

Da es mittlerweile um verschiedene Images ging: Von welchem Image sprichst Du genau?

Marino hat geschrieben: ↑Sa Sep 14, 2024 4:19 pm Webinterface des Dockers ist auf Port 8080 erreichbar, Mappen tue ich diesen auf 9082, Portainer zeigt 172.17.0.6 als IP.

Das macht keinen Sinn bzw. meinst Du wahrscheinlich genau die andere Richtung. Mapping ist immer von aussen nach innen, also welcher Port vom Host wird auf welchen Port im Container gemappt. Ich gehe schwer davon aus, dass das Port-Mapping bei Dir so aussieht:

8080:9082

Ist dem so? Screenshots vom Portainer wären hilfreich...

Marino hat geschrieben: ↑Sa Sep 14, 2024 4:19 pm 2. http://172.17.0.6:9082 im Proxy angegeben und mit https://[IP-TWS]/proxy/dockername ergibt "502 Bad Gateway (nginx)"

Klar, wenn Du Port 8080 auf den Container mappst, dann wirst Du auf Port 9082 keinen Erfolg haben.

Marino hat geschrieben: ↑Sa Sep 14, 2024 4:19 pm 3. http://172.17.0.6:8080 im Proxy angegeben und mit https://[IP-TWS]/proxy/dockername öffnet das Webinterface

Das ist korrekt. Wenn sich das WebIf öffnet, ist das Portmapping grundsätzlich in Ordnung.

Marino hat geschrieben: ↑Sa Sep 14, 2024 4:19 pm aber total verzerrt, mit falschem (quasi kein) Design und Popups können auch nicht geöffnet werden. Unbrauchbar leider. Slash am Ende im Reverse-Proxy und im Browseraufruf machen keinen Unterschied. Alle Varianten probiert.

Und hier wäre wieder die Frage von oben relevant. Um welches Image geht's genau? Was läuft dort?

Danke Yves (@starwarsfan ) für die Antwort.

Ich habe mal einen neuen Thread aufgemacht: viewtopic.php?t=5417
Ich würde echt gerne verstehen, wie ich den Reverse Proxy nutzen kann und was ich falsch mache.

gbglace hat geschrieben: ↑Do Aug 08, 2024 6:11 pm Da ich es bei mir auch noch nie zum laufen bekommen habe irgendeinen Service des TWS mit einem URL-Namen aufzurufen, benutze ich durchweg nur die IP-Adressen. Und da habe ich dann einfach 225 >> TWS, 226 SSH, 227 MQTT Broker, 228 NR, 229 HA. Und dann eben die Ports noch hinten dran. Und dann steckt das alles einfach in Lesezeichen im Browser.

Ich habe aus Sicherheitsgründen ("Brandabschnitte") meine Container auf mehrere (Sub-)Netzwerke aufgeteilt, daher verwende ich MacVLAN. Auch wenn das der Grundidee der Container widersprechen sollte - ich wüsste nicht wie ich es anders lösen könnte und: es funktioniert.

Für die Namensauflösung (Beispiel: mqtt-broker.meine.lokale.domain) ist der lokale DNS zuständig, der bei den meisten Heim-Setups im Router integriert sein dürfte. Du kannst also einen Eintrag aus URL und IP im lokalen DNS konfigurieren. Nach einem Neustart des Dienstes "DNS" bzw. des Routers sollte alles korrekt aufgelöst werden.

Ich habe bei mir etwas "geschummelt", um mir die Übersichtlichkeit zu erhalten: Ich habe die MAC Adressen der Container manuell im DHCP mit Hostname und IP konfiguriert, auch wenn die Container eine statische IP haben und DCHP nicht nutzen. In meinem Router/Firewall (pfsense) ist der DHCP so eingestellt, dass er seine Einträge automatisch an den lokalen DNS gibt, daher funktioniert das. Klärt mich gerne auf wenn das eine ganz dumme Idee war!

Im Ursprungspost von @speckenbuettel stand auch die Frage nach der Domain. Die Domain ist einfach sprechend für dein lokales Netz (unter der Annahme dass deine Container lokal laufen). Hier gibt's ja verschiedene mehr oder weniger bekannte Beispiele: .local, .home.arpa, .speedport, .fritz.box usw. Auch wenn die Einstellung im Portainer keine Auswirkung auf die Auflösung durch deinen lokalen DNS (siehe oben) hat, so weiß der Container immerhin selbst wie er heißt (hostname.domain). Manche zeigen das ja hier oder dort an und dann ist es schön wenn es vollständig und korrekt ist. Für die Auflösung braucht man dennoch den Eintrag im lokalen DNS (siehe oben).

Nur mal als kurzer Einwurf:

Die FRITZ!Box-Benutzeroberfläche kann auch über “fritzbox.internal” und “fritzbox.home.arpa” im Heimnetz aufgerufen werden.

Vielleicht fragen irgendwann die Nutzer ob diese Urls auch beim TWS im Zertifikat mit enthalten sein sollten.

Hi Michael,

richtig, es ist für diese Zwecke eine neue TLD von der IANA vorgesehen: .internal.

Derzeit geht das noch durch die Abstimmungsprozesse, aber es wird angenommen, dass .internal für diesen Anwendungszweck das Rennen macht und die Router-Hersteller sollten dies dann auch übernehmen und wir haben intern bereits dafür abgestimmt, werden wir gerne dann auch automatische Zertifikate mit .internal bereitstellen werden.

Wenn man die Fritzbox bereits über fritzbox.internal ansprechen kann, dann umso besser.

lg

Stefan

Hallo miteinander

gurumeditation hat geschrieben: ↑Mi Sep 18, 2024 10:10 pm Ich habe aus Sicherheitsgründen ("Brandabschnitte") meine Container auf mehrere (Sub-)Netzwerke aufgeteilt, daher verwende ich MacVLAN. Auch wenn das der Grundidee der Container widersprechen sollte - ich wüsste nicht wie ich es anders lösen könnte

Das ist einfach. Aber wie immer, man muss eben wissen, wie es geht!

Here we go:

1. In Portainer ein neues Netzwerk anlegen. Ich hab's für das Beispiel hier einfach "2nd" genannt:



Damit gibt es nun das Standardnetz "Bridge" im Range 172.17.* und das Netz "2nd" im Range 172.20.*


2. Die Container in die gewünschten Netze konfigurieren. Für das Beispiel habe ich vier ssh-Container konfiguriert, wobei die ersten beiden im Bridge-Netz und anderen beiden im 2nd-Netz sind:

Container #1:




Container #2:




Container #3:




Container #4:




Damit befinden sich die Container in zwei verschiedenen Subnetzen:




3. Test der Separierung. Dazu bin ich per ssh auf allen vier Containern und führe auf allen Containern gleichzeitig die folgenden Schritte aus:
- IPs der Container ermitteln
- Ping auf die IP eines Containers im Bridge-Netz
- Ping auf die IP eines Containers im 2nd-Netz




Im Screenshot sind die beiden oberen Container im Bridged- und die beiden unteren Container im 2nd-Netz. Dabei ist zu sehen, dass der erste Ping, also der Ping im Bridge-Netz nur bei diesen beiden Containern erfolgreich ist. Der zweite Ping auf eine IP im 2nd-Netz ist dann nur bei den beiden unteren Containern erfolgreich, weil sich diese im 2nd-Netz befinden.

Das ist schlussendlich genau das, was auch auf einem OpenShift-Cluster gemacht wird. Dort hat jeder Namespace seinen eigenen IP-Range resp. ein eigenes Subnet, womit die Separierung zwischen den Namespaces erreicht wird. Alle Container innerhalb eines Namespaces befinden sich im gleichen Docker-Netz und damit im gleichen Subnetz und können sich direkt unterhalten. Alles andere drumherum ist aus diesem Netz heraus nicht zu sehen und muss bei benötigtem Zugriff entsprechend geroutet werden. Somit ist das aus Netzwerksicht nichts anderes als ein weiteres (Sub)Netz.

StefanW hat geschrieben: ↑Do Sep 19, 2024 8:40 am ...wir haben intern bereits dafür abgestimmt, werden wir gerne dann auch automatische Zertifikate mit .internal bereitstellen werden.

Das wäre wirklich schön! Ich würde dann meine interne Domain von .home.arpa auf .internal umstellen wenn es nur mit .internal geht.

Macht das denn für euch überhaupt einen Unterschied, für welche Domain Kunden ein Zertifikat benötigen oder ist das am Ende nur ein String der über ein Formular übergeben werden kann?

Hi Guru,

gurumeditation hat geschrieben: ↑Do Sep 19, 2024 7:13 pmMacht das denn für euch überhaupt einen Unterschied, für welche Domain Kunden ein Zertifikat benötigen oder ist das am Ende nur ein String der über ein Formular übergeben werden kann?

Im Moment erfolgt die Erstellung automatisch alle 11 Monate und theoretisch ist der Eintrag "nur" ein weiterer String im Abschnitt "alternativer Hostname".

Aber da nun ein Interface zu bauen für "wunschdomäne" oder auch "ich habe eigene Zertifikate" ist schon ein größerer Aufwand, aber ich halte das mal im Kopf.

lg

Stefan