Server administrieren - wo fange ich an?

  • Welche Relevanz hat der angegeben Port in diesem Fall? Ich habe ja http portainer 9000 angegeben, und jetzt erst gemerkt das portainer bei mir unter 8000 bzw 9443 läuft - warum funktioniert das trotzdem?

    Soll ich bei weiteren Containern dann auch einfach http container name 9000 angeben?

    Denn als ich soeben das gleiche für nginx versucht habe, hat es mit Port 81 nicht funktioniert.


    Edit: Funktioniert nicht, stimmt so nicht, das Zertifikat will nicht - weil Plesk dazwischen funkt?! Wo kommt das denn her?!


    pasted-from-clipboard.png

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Edited once, last by Bud ().

  • Welche Relevanz hat der angegeben Port in diesem Fall? Ich habe ja http portainer 9000 angegeben, und jetzt erst gemerkt das portainer bei mir unter 8000 bzw 9443 läuft - warum funktioniert das trotzdem?

    Soll ich bei weiteren Containern dann auch einfach http container name 9000 angeben?

    Denn als ich soeben das gleiche für nginx versucht habe, hat es mit Port 81 nicht funktioniert.

    Das ist komisch - eigentlich sollte es nur 9443 gehen.

    Zu NPM: ich hab http 127.0.0.1 81

  • Wenn ich in nginx einen Proxy Host temporär deaktiviere - hat das negative Auswirkungen auf das LE-Zertifikat? Oder andere Auswirkungen an welche ich gerade nicht denke?


    Und damit mit den Ports 80:80 etc. muss ich mir definitiv nochmal genauer anschauen.

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • Moin, ich hoffe, ich erzähle dir jetzt nichts, was du schon weisst, aber was du dir auf jeden Fall anschauen solltest, ist Die Dockerhub/Github Seite der verschiedenen Container. Da sind die "Exposed Ports" nämlich Dokumentiert.


    Am Beispiel Portainer:

    8000 - Port für den SSH-Tunnel zwischen Client und der Portainer-Instanz

    9000 - Port zum Zugriff auf die GUI und die API

    9443 - Port zum Zugriff auf die GUI und die API (SSL)


    Über die 3 Ports kannst du also auf den Portainer Container zugreifen.

    Da du das mit einem SSL Proxy planst, war für dich 9000 interessant.


    Wenn man jetzt also mal die Firewall aussen vor lässt, wäre dein Sever dann von aussen so erreichbar:


    DeineIP:80 -> nginx HTTP

    DeineIP:443 -> nginx HTTPS

    DeineIP:9000 -> Portainer HTTP

    DeineIP:9443 -> Portainer HTTPS


    Du sagst dann dem Proxy, dass er bitte folgendes tut:

    DeineSubDomain:443 -> localhost:9000


    Das mit dem 80:80 (Portmapping) wird dann spannend, wenn du mehrere Container hast, die alle z.B. ein Webinterface auf Port 80 anbieten wollen. Damit kommen sie dann ja in Konkurrenz untereinander.

    Da kannst du dann definieren, dass der Port 80 des Containers z.B. auf Port 30080 nach aussen gemapped werden soll.

    Die Syntax 30080:80 hätte also zum Beispiel zur Folge, dass der HTTP Port eines Containers extern auf Port 30080 erreichbar ist:

    DeineIP:30080 -> ContainerXY HTTP


    und ergänzend im Proxy:

    DeineSubDomain2:443 -> localhost:30080


    Dazu ist es aber wichtig zu wissen welche Ports vom jeweiligen Container bereitgestellt werden - und natürlich welche Ports auf deinem System noch frei sind.


    Ich bin jetzt bewusst nicht auf Firewall, Plesk und Docker Netzwerke eingegangen, denn ich denke, es ist wichtig, erstmal die Idee dahinter zu verstehen.


  • Guten Morgen CK111 - vielen Dank für die Erklärung!


    Dadurch, dass meine Webinterface-Dienste alle im gleichen Netzwerk laufen, wäre die Konfiguration dann wie folgt – oder?

    Dienst 1: 8081:80
    Dienst 2: 8082:80
    Dienst 3: 8083:80
    Dienst 4: 8084:80
    Dienst 5: 8085:80

    Und dann jeweils subdomain:443 -> localhost:808X?

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • Im Prinzip, ja!


    Zu beachten ist allerdings, dass einige Anbieter von Containern bereits mitdenken und eben genau aus dem Grund nicht Port 80 sondern einen anderen Port benutzten. Genau aus dem Grund läuft Portainer z.B. auf 9000, da eben viele Anwender Portainer nicht zum Selbstzweck installieren und daher die Ports 80 und 443 selber brauchen.


    Da kommen dann die Dokus wieder ins Spiel und man muss schauen, ob man nun Port 80, 81, 8080, oder 9000 für diesen Zweck nach außen gemapped bekommt. ;)

  • Aber ist es wichtig, dass ich die Ports der Doku verwende, oder kann ich meine eigenen Ports angeben?

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • Erstmal sind die Ports wichtig, die vom Container bereitgestellt werden, bei Portainer z.B. 9000.

    Da lässt sich erstmal nicht dran drehen. (Viele lassen es zu, aber das lasse ich jetzt bewusst aus).


    DeineIP:9000 -> Portainer HTTP

    DeineIP:9090 -> Timeout


    Diese kannst du dann nach belieben in der Konfiguration für deine Instanz verändern: 9090:9000 ->

    DeineIP:9000 -> Timeout

    DeineIP:9090 -> Portainer HTTP


    Damit änderst nicht den internen Port, sondern das Mapping danach.

    Das ist wie Portforwarding in einer Firewall. Du hast den Dienst auf Port 9000 und möchtest ihn auf Port 9090 im Internet publizieren.

  • Möchte hier nochmal aufgreifen wenn man das wie TBThier beschrieben hat macht dass man die Ports gar nicht nach draußen legen braucht.


    Wenn beide Container im Gleichen Docker Netzwerk sind und man den Containern Namen gibt kann man einfach mit den namen Arbeiten und nimmt einfach den Port der als Standard genutzt wird.


    Also das 8080:80 braucht man nicht machen.


    im Beispiel Portainer wenn der container portainer heist würde man dann im Nginx das angeben.


    http:// portainer:9000


    oder uptimekuma z.b.

    http:// uptimekuma:3001


    oder wenn es z.b. nur ein nginx container mit ner website ist:

    http:// nginx:80


    Die Dienste sind dann nur über die angegebene SubDomain erreichbar. IP:Port geht dann von draußen nicht!

  • @philw95: Hübscher geht immer, aber ich hatte es verstanden, dass er erstmal die Basics verstehen möchte und ein exponierter Port gibt halt feedback, ob der Container arbeitet, oder nicht.


    Wenn ich das richtig verstehe, macht er das auch über Plesk und da kannst du aus der Box raus auch nicht die Netzwerknamen definieren, da gibt's ein default netz pro Container, wenn ich mich recht entsinne.

  • Wenn ich das richtig verstanden habe, läuft mein Docker so wie von TBT beschrieben. Incoming-Traffic wird komplett geblockt, außer für 22 und 4949 (Munin). 80 und 443 werden von Docker selbst weitergeleitet.

    Deswegen ja meine obige Frage. Wenn ein Dienst auf 8081:80 läuft, wird er von nginx hinter der FW weitergeleitet (http - service - 8081), mit einem Zertifikat versehen und nach außen über 443 geleitet.


    pasted-from-clipboard.png


    Oder habe ich das falsch verstanden? Über IP:PORT ist nichts erreichbar.
    Ich würde ja sogar gerne 80 aus der UFW entfernen, aber ich hatte mal irgendwo gelesen, dass dies trotzdem keine gute Idee ist. Ich glaube, LE braucht den, oder?

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • Wenn ich das richtig verstanden habe, läuft mein Docker so wie von TBT beschrieben. Incoming-Traffic wird komplett geblockt, außer für 22 und 4949 (Munin). 80 und 443 werden von Docker selbst weitergeleitet.

    Deswegen ja meine obige Frage. Wenn ein Dienst auf 8081:80 läuft, wird er von nginx hinter der FW weitergeleitet (http - service - 8081), mit einem Zertifikat versehen und nach außen über 443 geleitet.

    D.h. du hast im Docker Compose File:

    Code
     ports:
       - "8081:80"

    Den Teil kannst du an sich weggelassen, da die exposden Ports von einem Container innerhalb vom Docker Netzwerk erreichbar sind.

    Quote


    Dienst 1: 8081:80
    Dienst 2: 8082:80
    Dienst 3: 8083:80
    Dienst 4: 8084:80
    Dienst 5: 8085:80

    Das brauchst du auch nicht, da jeder Container quasi ein eigener Server ist, daher auch seine eignen Ports hat bzw. diese nicht in Konflikt miteinander geraten.

    Quote

    Oder habe ich das falsch verstanden? Über IP:PORT ist nichts erreichbar.

    Welche IP hast du verwendet? Du musst die interne von Docker verwenden (nicht die deines Servers). Aber den Namen zu verwenden ist eh besser, da sich die interne IP auch mal ändern können (Das mit den Namen funktioniert, da Docker intern die Namen zu den Ips auflöst, innerhalb eines Netzwerkes)

    Mit docker container inspect

    pasted-from-clipboard.png

  • Den Teil kannst du an sich weggelassen, da die exposden Ports von einem Container innerhalb vom Docker Netzwerk erreichbar sind.

    Aber ich dachte das der erste Teil, also in dem Fall 8081 der "interne exposed" Port ist?

    Das brauchst du auch nicht, da jeder Container quasi ein eigener Server ist, daher auch seine eignen Ports hat bzw. diese nicht in Konflikt miteinander geraten.

    Aber nginx selbst fragt ja auch nach einem "Forwarded Port"

    Ich habe das Gefühl ich habe irgendwo einen Denkfehler, bzw Verständnisfehler.

    Welche IP hast du verwendet? Du musst die interne von Docker verwenden (nicht die deines Servers). Aber den Namen zu verwenden ist eh besser, da sich die interne IP auch mal ändern können (Das mit den Namen funktioniert, da Docker intern die Namen zu den Ips auflöst, innerhalb eines Netzwerkes)

    Keine IP, siehe Screenshot. Ich nutzte die Namen der Container, also z. B. portainer oder wikijs-one, und die sind alle in dem Netzwerk nginx_default


    Zusammenfassend habe ich gedacht:
    8081:80 bedeutet, dass der Container im Netzwerk nginx_default den Port 8081 hat, und so die Zuordnung durch nginx funktioniert. 80 ist für mich der Port, über welchen der Dienst publiziert wird, aber nginx packt ein LE-Zertifikat davor und publiziert über 443 inkl. Zuordnung der Subdomain.

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • Aber ich dachte das der erste Teil, also in dem Fall 8081 der "interne exposed" Port ist?

    Alle Ports die in dem Dockerfile als "EXPOSE" definiert sind, sind im Docker Netzwerk erreichbar:

    => Bei "Forward Port" musst du den Port eintragen, der entsprechend definiert ist im Dockerfile - welcher das ist steht immer in der Dokumenation bei Portainer z.B. 9443 für HTTPS.

    Den Port den du angeben im Compose definierst, gibt quasi an, an welchen Port von deinem Server der interen Port gebunden wird.

    Sagen wir dein Server hat die externe IP 1.1.1.1

    Code
    ports:
       - "8081:80"

    Führt dann dazu, dass du mit: 1.1.1.1:8081 auf den Service von Container zugreifen kannst.

    Nun seien die Container: c1, c2 im Netzwerk n1 (mit den IPs 10.10.10.i) und c3 in Netzwerk n2 mit 10.10.11.2

    • Die Ip ist nicht aus dem Internet erreichbar (von c1,c2,c3)
    • Aber von dem Server alle (d.h. du kannst 10.10.11.2 anpingen aber auch 10.10.10.1 und 10.10.10.2)
    • Jeder Container im selben Netz kann auf die IP zugreifen: c1 kann auf c2 zugreifen
      • Wenn c1 eine Service auf Port 80 anbietet
      • kann c2 mit 10.10.10.1:80 auf den Service zugreifen
      • c3 kann aber nicht auf c1 oder c2 zugreifen

    Solltest du jetzt für c1 folgendes definieren: "ports: 8081:80" => 1.1.1.1:8081 leitet auf 10.10.10.1

    Quote

    Keine IP, siehe Screenshot. Ich nutzte die Namen der Container, also z. B. portainer oder wikijs-one, und die sind alle in dem Netzwerk nginx_default

    Das war nur auf den vorherigen Satz bezogen "Über IP:PORT ist nichts erreichbar." und sollte nur zum Verständnis beitragen.


    Alls Analogie kannst du dir vorstellen:

    • Die Container sind "Server" in deinem lokalen Netzwerk
    • Dabei hängt c1 und c2 in einem Netz z.B. am gleichen Switch
    • c2 hat ein eignes Netz
    • Aber alle 3 sind mit dem Router verbunden "=>" der Router (dein Server) kann auf alle zugreifen und entscheidet, welchen er den Zugriff nach außen erlaubt

    Wie sieht den dein Docker Compose File aus?


    Da wird es auch nochmal erklärt https://docs.docker.com/compose/networking/):

    Quote

    It is important to note the distinction between HOST_PORT and CONTAINER_PORT. In the above example, for db, the HOST_PORT is 8001 and the container port is 5432 (postgres default). Networked service-to-service communication uses the CONTAINER_PORT. When HOST_PORT is defined, the service is accessible outside the swarm as well.

  • Möchte mich gerne an die NPM Diskussion dranhängen, denn so richtig läuft mein NPM Setup noch nicht (auf Ubuntu 22.0.4 LTS):.

    Ich schreib mal kurz was ich bisher verstanden und gemacht habe.


    Durchgeführt:

    - jewiligen Subdomains für den NPM angelegt => Zeigen auf Server, funktioniert


    - Portainer Agent auf dem Server installiert, wird über meine Portainer Instanz auf meinem Heimnetz Raspi gesteuert. Dazu in der UFW Port 9001 tcp auf dem Server für den Portainer Agent Container freigegeben => funktioniert


    - NPM Container installiert => läuft


    - Zum Test noch Heimdall Container installiert => läuft


    - Neues Netzwerk "NPM-Network" eingerichtet und sowohl den NPM als auch Heimdall da hinzugefügt. Aus den Netzen, in denen die beiden Container vorher waren, habe ich sie entfertn. Sind jetzt jeweils nur noch in "NPM-Network". => So korrekt?


    - Proxy hosts in NPM für Heimdall und für NPM eingerichtet und jeweils SSL Zertifikate dazu => funktioniert


    - UNter "Access Lists" einen User samt PW vergeben und auf beiden Proxy Hosts aktiviert => Funktioniert 1a für Heimdall, wenn ich die NPM Domain aufrufe kann ich die Zugangsdaten gemäß Access List eingeben, komme auf die Loginseite von NPM, kann mich aber nicht einloggen (Zugangsdaten korrekt, eingesetzt aus Keepass, selbe wie für Heimdall) => Ideen woran das liegen kann?


    - Die NPM Login Seite ist aber nach wie vor unter IP:81 zu erreichen. => Sollte doch durch u.g. Maßnahmen nicht mehr sein, oder?


    Grundsätzliche Fragen:

    - Irgendwo hab ich gelesen, in meinem Fall Raspi Portainer und Server Portainer würden auch über Port 8000 kommunizieren? Hab ich nicht freigegeben, läuft trotzdem. Benötigt?


    - Auf dem Server läuft kein Webserver. D.h. es würde reichen, wenn ich dort in er UFW Port 80 & 443 TCP für den NPM Container und das NPM-Network freigebe. Generelle Freigabe von 80 & 443 ist nciht mehr nötig => Hab ich das so richtig verstanden?


    - Ihr schreibt, man braucht keine Ports mehr exposen. Aktuell sieht das so aus. D.h. ich würde Portainer interne und externe Ports löschen, so dass da gar nix mehr steht?

    Screenshot 2024-07-20 200606.jpg


    - Wenn ich nun die Ports entferne und ein anderer Container lauscht auch intern auf z.B. Port 80? Wird da dann doch die Einstellung im NPM http => Containername => Port 80 geregelt, oder gibt es dann Fehler.


    Wäre super, wenn Ihr mal schauen könntet, ob ich richtig liege bzw. wo der fehler leigt.


    Danke

  • - Neues Netzwerk "NPM-Network" eingerichtet und sowohl den NPM als auch Heimdall da hinzugefügt. Aus den Netzen, in denen die beiden Container vorher waren, habe ich sie entfertn. Sind jetzt jeweils nur noch in "NPM-Network". => So korrekt?

    Jep. Kann man so machen.


    - UNter "Access Lists" einen User samt PW vergeben und auf beiden Proxy Hosts aktiviert => Funktioniert 1a für Heimdall, wenn ich die NPM Domain aufrufe kann ich die Zugangsdaten gemäß Access List eingeben, komme auf die Loginseite von NPM, kann mich aber nicht einloggen (Zugangsdaten korrekt, eingesetzt aus Keepass, selbe wie für Heimdall) => Ideen woran das liegen kann?

    Access Lists würde ich nur verwenden, wenn der Container keine eigene Benutzerverwaltung hat, d.h. keinen eigenen Login. Sonst ist das m.E. doppelt gemoppelt. Also einfach weglassen, wenn die Anwendung eine eigene Benutzerverwaltung hat. Wofür man diesen Teil gut verwenden kann: man kann z.B. nur lokale Netze drauf zugreifen lassen (mit DNS Name), nicht von außerhalb des LANs aus (wenn das gewünscht ist).

    - Die NPM Login Seite ist aber nach wie vor unter IP:81 zu erreichen. => Sollte doch durch u.g. Maßnahmen nicht mehr sein, oder?

    Sobald NPM sicher unter https://npm.domain.de erreichbar ist, kannst Du den Port 81 aus dem Docker Compose File nehmen (mit # auskommentieren) und den Container neu starten. Er wird dann nicht mehr rausgelegt und ein http://1.2.3.4:81 (wobei 1.2.3.4 die lokale IP des Docker Hosts ist) wird nicht mehr funktionieren, wohl aber weiterhin https://npm.domain.de .


    Beim Reverse Proxy MÜSSEN Port 80 und 443 IMMER herausgelegt (exposed) sein (sonst können sie ihre Funktion nicht erfüllen, der 81er Verwaltungsport muss aber nicht rausgelegt werden.


    Bei allen anderen Containern kann auf das Herauslegen von Ports die auf Weboberflächen gehen, z.B. auf irgendwelchen höheren Ports (3000, 9000, 8080, etc.) verzichtet werden, wenn die Weboberflächen erfolgreich geproxied werden können (zuerst den Proxy einrichten, testen, dann die betreffenden exposed Ports auskommentieren).


    Wenn ein Container andere Ports benötigt, die von außen ansprechbar sein müssen, die keine Website hinter sich haben (z.B. Port 21 bei einem FTP Server, oder die diversen Ports für IMAP(S), SMTP(S) etc., dann MÜSSEN diese exposed bleiben. Aber auch bei solchen Containern können die Web(admin)interfaces über den Proxy laufen. Z.B. Webadminoberfläche eines FTP Servers über Proxy und nicht exposed, Port 21 dazu exposed.

    - Auf dem Server läuft kein Webserver. D.h. es würde reichen, wenn ich dort in er UFW Port 80 & 443 TCP für den NPM Container und das NPM-Network freigebe. Generelle Freigabe von 80 & 443 ist nciht mehr nötig => Hab ich das so richtig verstanden?

    Auf dem Server läuft absolut ein Webserver. Nämlich NPM. Auf einem Port kann nur ein Service laufen, daher läuft auch nur NPM auf diesem Port. Imho ist es kein Unterschied, ob Du das so oder so machst.


    - Ihr schreibt, man braucht keine Ports mehr exposen. Aktuell sieht das so aus. D.h. ich würde Portainer interne und externe Ports löschen, so dass da gar nix mehr steht?

    Screenshot 2024-07-20 200606.jpg


    - Wenn ich nun die Ports entferne und ein anderer Container lauscht auch intern auf z.B. Port 80? Wird da dann doch die Einstellung im NPM http => Containername => Port 80 geregelt, oder gibt es dann Fehler.

    Das stimmt so nicht. NPM braucht essentiell 80/443 exposed (81 nicht, s.o.), sonst kann er nicht funktionieren. Aber wenn man nen Reverse Proxy hat, braucht kein anderer Container ein exponiertes Webinterface. Wohl aber andere Ports, die für die jeweilige Applikation relevant sind.


    Ein Container, der "in seinem Container" auf Port 80 lauscht ist isoliert von einem anderen Port, der auch auf Port 80 lauscht. Das ist ein bisschen wie eine VM neben einer anderen VM. Dass hier gleiche Ports verwendet werden ist also kein Problem, da im Docker Netzwerk beide Container separate Einheiten sind, die jede für sich alle Ports haben können.


    Bei einem Reverse Proxy musst Du ja neben dem Port (80) auch den Namen (oder die IP) des Zielcontainers angeben. Damit stellst Du dann ein, wohin eine Anfrage gehen soll.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Like 1
  • Wenn ich einen Zugriff auf all meine Server via SSH nur für eine IP erlaube (VPN Server), bringt mir ein SSH-Key dann noch irgendeinen Vorteil, oder kann ich mir das sorgenfrei sparen?

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE