VLAN und Isolierung von Docker Containern

[mgutt 752]

On 1/19/2021 at 10:55 PM, mgutt said:

Ich schaue mal ob ich damit Erfolg habe:

https://github.com/docker/for-mac/issues/1390#issuecomment-284467649

 

 

Schritt für Schritt was dadurch passiert.

 

Nach Ausführen von diesem Befehl:

docker network create nextcloud_internal --internal

 

Bekomme ich eine ID zurück. Außerdem werden dadurch diese zwei neuen Einträge in iptables hinzugefügt:

-A DOCKER-ISOLATION-STAGE-1 ! -s 172.18.0.0/16 -o br-28d52fb72e46 -j DROP
-A DOCKER-ISOLATION-STAGE-1 ! -d 172.18.0.0/16 -i br-28d52fb72e46 -j DROP

 

Diese neue IP-Range hat Docker selbst angelegt. Normalerweise liegen meine bridge-Container nämlich in 172.17.0.2/32.

 

Beim Erstellen des Containers sehe ich nun ein neues Custom-Netzwerk. Eine feste IP-Adresse kann man nicht vergeben (das Feld muss also leer bleiben):

 

Außerdem füge ich eine Port-Weiterleitung hinzu:

 

Nun sieht das ganze so aus:

 

Nextcloud lässt sich nicht öffnen:

 

Versuche ich innerhalb des Nextcloud-Containers auf das Internet zuzugreifen, dann ist das nicht möglich:

 

Dann habe ich den Nginx Proxy Manager ganz normal im Bridge-Modus gestartet. Dieser lauscht also auf 3 Ports:

 

Nun verbinde ich den Proxy Manager mit dem nextcloud_internal Netzwerk:

docker network connect nextcloud_internal NginxProxyManager

 

Ich öffne dessen Konsole und stelle fest, dass er nun eine IP aus dem Netz von Nextcloud hat, nämlich die 172.18.0.3:

 

Von der Konsole des Nextcloud-Containers kann ich nun den Proxy Manager erreichen:

 

Meinen Router erreiche ich allerdings nicht:

 

Der Proxy Manager erreicht dagegen meinen Router:

 

Bis hierhin sieht das schon mal gut aus. Allerdings besteht natürlich nach wie vor die Gefahr, dass der Angreifer den Nextcloud Container übernimmt und von da aus versucht den Proxy Manager zu attackieren. Ich denke damit muss man leben.

 

Was aber schon mal gut ist, dass der Nextcloud-Container keine Pakete nachladen kann (der Angreifer kann also keine weiteren Tools holen):

 

Allerdings fehlt mir jetzt noch die Möglichkeit den Proxy Manager von meinem restlichen Netz auszuschließen. Also er soll zwar mit meinem Router kommunizieren können, aber mit keiner anderen IP des Netzes. Braucht es dafür eine separate iptables Regel oder kann ich das auch über Docker umsetzen?

 

Außerdem habe ich ein Problem. Der Proxy Manager kann zwar Nextcloud mit dessen interne IP erreichen, aber nicht über dessen Host-IP:

 

Da ich ja keine feste interne IP vergeben kann, wie soll ich dann einen Proxy-Reverse konfigurieren?! Welchen Sinn hätte dann überhaupt die Port-Freigabe 8666?!

[mgutt 752]

Zu dem Problem, dass der Port nichts durchlässt:

https://github.com/moby/moby/issues/36174#issuecomment-363615950

As far as I'm aware, this is by design, and --internal networks should not be reachable, even with -p being used 

 

In dem Post ist von HaProxy als Lösung die Rede. Das muss ich mal testen.

[mgutt 752]

Also man kann eine feste IP vergeben, wenn man eine eigene IP-Range angibt. zB so:

docker network create --subnet=172.19.0.0/24 nextcloud_internal --internal

 

Danach habe ich wie schon zuvor Nextcloud darin erstellt, aber diesmal mit der festen IP 172.19.0.5 und NPM damit nachträglich verbunden. Dann in NPM die Proxy Regel erstellt und läuft. Nun noch MariaDB dem internen Netz zugewiesen um Nextcloud fertig installieren zu können und läuft ebenfalls.

 

Dann habe ich noch mal in MariaDB geschaut was ich machen kann:

 

Das eine Ergebnis kam mir komisch vor, also habe ich nachgehakt und leider kann MariaDB auf die Login-Seite von Unraid zugreifen:

 

Nextcloud auch:

 

 

Wirklich verstehen tue ich das nicht. Beide Container sind im Netz 172.19.0.0/24 und es gibt keine Port Mappings. Außerdem habe ich testweise NPM von nextcloud_internal wie folgt getrennt, was aber auch nicht geholfen hat:

docker network disconnect nextcloud_internal NginxProxyManager

 

 

Also der Container kann wirklich nichts machen außer auf die Weboberfläche von Unraid zugreifen. Das muss man doch auch irgendwie unterbinden können.

 

[ich777 1230]

@mgutt Wenn du deinen Container verbieten willst das sie auf den Host zugreifen können schmeiß sie in Custom: br0 und sie haben keine Zugriff mehr auf den host (vorausgesetzt das du 'Host access to custom networks' deaktiviert hast).

[mgutt 752]

8 minutes ago, ich777 said:

schmeiß sie in Custom: br0

 

Damit hat der Container aber Zugriff auf das Internet und das gesamte lokale Netz. Also alles erlaubt außer die IP von Unraid. Selbst die Fritz!Box könnte man so angreifen:

 

Das "internal" Netz schottet dagegen alles ab. Bis auf die IP von Unraid. Also genau das Gegenteil. Mit der iptables Regel ist es dann komplett dicht.

 

 

[mgutt 752]

Also warum der Container auf Unraid zugreifen kann weiß ich wie gesagt nicht, aber man kann es mit der folgenden iptables Regel leicht lösen:

iptables -A INPUT -s 172.19.0.0/24 -d 192.168.178.0/24 -j DROP

 

Damit darf also kein Container, der eine IP aus 172.19.0.0/24 besitzt, Kontakt zu einem Teilnehmer aus dem 192.168.178.0/24 Netz aufnehmen.

 

Testergebnis an Hand des Nextcloud-Containers:

 

Was mich wundert, dass die Nextcloud-Konsole trotzdem noch funktioniert. Weil das Webterminal wird ja durch Unraid geladen, also durch eine IP aus dem 192.168.178.0/24 Netz. Oder gilt das jetzt als eingehende Verbindung und ist daher erlaubt? Naja, keine Ahnung. Schadet jedenfalls nicht, dass es geht

 

Bis hier hin läuft die Sache aber schonmal so wie ich es mir vorgestellt habe. Der Traffic aus dem Internet landet bei NPM und von da wird er intern an die anderen Container weitergeleitet. Damit ist der einzige Schwachpunkt nun NPM, wo noch folgendes zu machen wäre:

1. Internetzugang verhindern
2. Zugang zu 192.168.178.0/24 verhindern bis auf 192.168.178.1 (Router)
3. Möglichst viele "Capabilites" entfernen, was auch von RedHat empfohlen wird.

Was mir noch aufgefallen ist: Wenn man die Ports von NPM verstellt, dann muss man den folgenden Befehl noch mal ausführen:

docker network connect nextcloud_internal NginxProxyManager

 

Am besten führt man ihn also jedes mal aus, wenn man den Container startet. Geht das nicht über das Feld "Post Arguments"? Darüber könnte man dann ja auch gleich die iptables Regel raushauen 😬

[Smolo 19]

On 1/21/2021 at 8:36 AM, ich777 said:

So war es nicht gemeint...

 

Sieh dir mal das Konzept von ipFire an die haben bis zu 4 Schnittstellen Rot=WAN, Grün=LAN, Orange=DMZ, Blau=WLAN

Klick

 

Du machst alles auf einer Firewall und teilst dort auf.

 

Ja mit IPFire habe ich vor Jahren mal rumexperimentiert das UI schaut ja immer noch grusselig aus  
Hast du die Fritzen dann vor dem IPFire oder dahinter?

 

Bin ja immer noch am überlegen die Firewall über ne VM zu regeln *ja du darfst Steine schmeißen* 🤣

 

On 1/20/2021 at 8:13 PM, mgutt said:

Meine Stromrechnung, weshalb ich die Fritz!Box auch nur sehr ungern gegen Router + Modem + X ersetzen will. Und parallel weiterlaufen lassen schon gar nicht.

 

Youtube ist gar nicht unter 13 Jahren erlaubt. Oder geht es um ältere Kinder? Ab 13 werde ich denke ich kaum noch was filtern. Wenn nur wie jetzt die nächtliche Nutzung per Google Family Link bzw Microsoft Family Safety unterbinden.

D.h. du hast deinen Container jetzt direkt > Fritte > ProxyManger > Docker Container eingerichtet oder?

[ich777 1230]

4 hours ago, Smolo said:

Ja mit IPFire habe ich vor Jahren mal rumexperimentiert das UI schaut ja immer noch grusselig aus  

Naja ich find das halb so wild, mir ost es lieber ich hab ne firewall die ordentlich funktioniert und da is mir die UI egal.

Ipfire ist wirklich sehr resourcenschonend, zumindest war es das früher als ich es verwendet hab.

 

4 hours ago, Smolo said:

Firewall über ne VM zu regeln

Das kann man ja machen nur gehen da die Meinungen auseinander und ich bin hald auch auf der seite das es nicht die beste lösung is.

Sobald die VM down is, hast du kein Internet mehr.

Vergiss auch nicht wenn du zB ein Plugin installiert hast das beim Start von Unraid nach updates sucht hast du dann auch pech, da du dann noch kein internet hast.

[mgutt 752]

9 hours ago, Smolo said:

D.h. du hast deinen Container jetzt direkt > Fritte > ProxyManger > Docker Container eingerichtet oder?

 

Noch nicht. Ich muss noch den NPM hätten und testen. Danach mache ich dazu ein Video.

[Smolo 19]

3 hours ago, mgutt said:

 

Noch nicht. Ich muss noch den NPM hätten und testen. Danach mache ich dazu ein Video.

Ja das wäre super ansonsten bin ich echt am überlegen temporär erstmal IPFire als VM aufzusetzen...3 virtuelle LANs dran und in die DMZ vom IPFire die Docker Container rein. Das sollte doch von der Thematik leichter zu konfigurieren und sicherer sein als in die Container Config einzugreifen die es einem bei einem Update auch zerlegen kann oder?

[mgutt 752]

36 minutes ago, Smolo said:

Das sollte doch von der Thematik leichter zu konfigurieren und sicherer sein als in die Container Config einzugreifen die es einem bei einem Update auch zerlegen kann oder?

 

Dazu kann ich dir noch keine verbindliche Antwort geben, aber ich werde versuchen das so zu konfigurieren, dass die gemachten Einstellungen direkt im Container Template hinterlegt sind. Soll heißen, wenn startet der immer mit diesen Regeln. Auch nach einem Update. Die Container hinter dem NPM können auch nach einem Update nicht auf das restliche Netzwerk zugreifen, da sie ja dem "internal" Netzwerk zugewiesen werden.

 

In einer VM hätte ich persönlich gar keinen Bock Container zu betreiben, da man dann den Overhead der VM hat. Und nicht zu knapp. Schließlich läuft dann ja alles virtuell. Also selbst der Netzwerk-Traffic läuft dann ja durch die KVM Treiber.

[Smolo 19]

5 hours ago, mgutt said:

In einer VM hätte ich persönlich gar keinen Bock Container zu betreiben, da man dann den Overhead der VM hat. Und nicht zu knapp. Schließlich läuft dann ja alles virtuell. Also selbst der Netzwerk-Traffic läuft dann ja durch die KVM Treiber.

Hm da haben wir glaube ich anhand der vorherigen Diskussion grad etwas vorbei geredet. Wenn ich jetzt nur die Container absichern möchte kann ich das natürlich wie du grad testest so machen das man dem Container selbst nichts zuweist bzw. Alles verbietet. Meiner Meinung nach könnte sich das als ziemlich Fehler anfällig erweisen weil du ja nicht in den Container drinnen steckst.

 

Die andere Idee wäre eine IPFire VM aufsetzen d.h. der externe traffic geht immer gegen die FW und ein virtuelles DMZ Netz für die Container aufspannen. Die Container selbst laufen ganz normal unter unraid aber mit dem speziellen Netz.

 

Ich habe es mir noch nicht weiter angeschaut unter Unraid aber bei den QNAPs kann man virtuelle Switch anlegen und entsprechend die Ports zuweisen.

[mgutt 752]

On 29.1.2021 at 8:40 PM, Smolo said:

Die Container selbst laufen ganz normal unter unraid aber mit dem speziellen Netz

 

Ähnliches könnte ich vermutlich jetzt schon machen, in dem ich br0.100 verwende, denn diese VLAN 100 route ich an Gast-LAN4 meiner Fritz!Box, wie hier beschrieben:

https://janscholten.de/blog/2014/09/vlans-im-heimnetz-mit-netgear-unifi-und-fritzbox/

 

Allerdings hat der Container dann Internetzugriff. Er kann also Pakete nachladen, was ich nicht möchte.

 

Stattdessen könnte ich also eine VLAN nehmen, die schlicht nicht existiert. Der getaggte Traffic findet also kein Ziel.

 

Bisher wusste ich nicht wie ich den eingehenden Traffic aus dem Internet nun dahin bekomme. Nur sollte das nicht gehen, wenn die Fritz!Box 80/443 an NPM freigibt und ich den NPM Container mit dem br.fake Netz verlinke? Muss ich mal ausprobieren.

 

Wenn das geht, könnte ich bei Bedarf kurz mit Nextcloud auf br0.100 wechseln um eine App aus dem Internet zu installieren und dann wieder zurück auf br0.fake und der Container wäre wieder offline bzw ausschließlich über NPM erreichbar.

 

Gerade wegen Plex habe ich aber denke ich noch ein Problem. Ich dachte ja einfach lokal über eine Domain auf Plex zuzugreifen. Aber dann gehen doch alle Clients hin und erzwingen Transcoding oder nicht (weil "Plex über Internet verbunden")? Kommt darauf an ob der Client mit einer lokalen IP bei Plex anklopft oder nicht. Ich befürchte fast, da NAT Loopback durch die Fritz Firewall läuft, dass ich dann von einer öffentlichen IP komme. Muss ich auch noch testen.

[Ford Prefect 206]

@mgutt: Ist ja schon ein wenig her...hast Du Erfolg gehabt?...gerade das hier gesehen:

...könnte das interessant für Deinen UseCase sein?

[SuperMeatBoy666 1]

@mgutt bist du an dem Thema noch dran?

[mgutt 752]

On 1/22/2021 at 9:55 PM, mgutt said:

Also warum der Container auf Unraid zugreifen kann weiß ich wie gesagt nicht, aber man kann es mit der folgenden iptables Regel leicht lösen:

Dazu habe ich auch diesen Bug Report gefunden:

https://github.com/moby/libnetwork/issues/1151

[Pillendreher 2]

On 2/19/2021 at 10:17 PM, Ford Prefect said:

@mgutt: Ist ja schon ein wenig her...hast Du Erfolg gehabt?...gerade das hier gesehen:

...könnte das interessant für Deinen UseCase sein?

 

Ich hab mir das mal angesehen, verstehe aber nicht so recht, was dieser Docker macht. So wie ich das jetzt laienhaft verstehe, schiebt er sich dazwischen mit einer VPN Verbindung. Auf welche VPN Verbindung bezieht sich das Ganze aber? Kann man da seine VPN Daten (Wireguard) des Unraid Servers eintragen? Und wie bin ich dann "geschützter" im Vergleich zu vorher?

[Ford Prefect 206]

 
Auf welche VPN Verbindung bezieht sich das Ganze aber? Kann man da seine VPN Daten (Wireguard) des Unraid Servers eintragen? Und wie bin ich dann "geschützter" im Vergleich zu vorher?

Ich habe ihn auch nicht ausprobiert.
Die VPN Verbindung ist hier eigentlich ein externer Service, aber es sollte doch auch "von innen" gegen einen lokalen Dienst laufen.
Der "Schutz" besteht mMn im eingebauten Kill-Switch. Die Docker kommen nicht aus dem VPN Kontext raus, wenn die Verbindung zum VPN abbricht (sonst natürlich auch nicht).
Aber damit wäre ein Leak in Richtung unraid Server/Host eben auch nicht mehr möglich.

...ist halt von "hinten durch die Brust ins Auge" gedacht und nur eine erste Idee.



Gesendet von meinem SM-G960F mit Tapatalk

[Morrtin 7]

Ich bin ein wenig ausgestiegen was noch offen ist, falls noch was offen ist. Wollte nur sagen das ich mit Hilfe von Spaceinvaders Videos mein Nextcloud, bitwarden und den swag Container im eigenen "proxynet" laufen habe. Auf der pfsense habe ich dann ein port forward von 443 auf den Unraidserver:443 geht was aber im Docker die 172.18.0.3:443 (swag conatiner) ist... Im DNS Resolver der pfsense habe ich dann eingetragen das dann nextcloud.mydomain.at auf die IP vom Unraidserver aufgelöst werden soll.

Das heißt ich kann vom LAN und von Außen mit nextcloud.mydomain.at arbeiten. Der Nextcloud Container kann aber fix nach hause telefonieren, da ich so auch die Updates und Plugins rein bekomme... Aber damit habe ich kein Problem.

[Pillendreher 2]

10 hours ago, Morrtin said:

Ich bin ein wenig ausgestiegen was noch offen ist, falls noch was offen ist. Wollte nur sagen das ich mit Hilfe von Spaceinvaders Videos mein Nextcloud, bitwarden und den swag Container im eigenen "proxynet" laufen habe.

Magst du das Video verlinken?

[Morrtin 7]

How to Setup Nextcloud on unRAID for your Own Personal Cloud Storage

https://www.youtube.com/watch?v=fUPmVZ9CgtM

 

How to Setup and Configure a Reverse Proxy on unRAID with LetsEncrypt & NGINX (Swag nehmen)

https://www.youtube.com/watch?v=I0lhZc25Sro

 

Swag nehmen, dann muss man das letzte Video nicht mehr machen:

 

How to Migrate from Letsencrypt to the New Swag Container

https://www.youtube.com/watch?v=qnEuHKdf7N0

 

[Pillendreher 2]

On 1/21/2021 at 11:30 PM, mgutt said:

Also man kann eine feste IP vergeben, wenn man eine eigene IP-Range angibt. zB so:

docker network create --subnet=172.19.0.0/24 nextcloud_internal --internal

 

Danach habe ich wie schon zuvor Nextcloud darin erstellt, aber diesmal mit der festen IP 172.19.0.5 und NPM damit nachträglich verbunden. Dann in NPM die Proxy Regel erstellt und läuft. Nun noch MariaDB dem internen Netz zugewiesen um Nextcloud fertig installieren zu können und läuft ebenfalls.

 

Dann habe ich noch mal in MariaDB geschaut was ich machen kann:

 

Das eine Ergebnis kam mir komisch vor, also habe ich nachgehakt und leider kann MariaDB auf die Login-Seite von Unraid zugreifen:

 

Nextcloud auch:

 

 

Wirklich verstehen tue ich das nicht. Beide Container sind im Netz 172.19.0.0/24 und es gibt keine Port Mappings. Außerdem habe ich testweise NPM von nextcloud_internal wie folgt getrennt, was aber auch nicht geholfen hat:

docker network disconnect nextcloud_internal NginxProxyManager

 

 

Also der Container kann wirklich nichts machen außer auf die Weboberfläche von Unraid zugreifen. Das muss man doch auch irgendwie unterbinden können.

 

Ich wollte das mal bei mir ausprobieren, aber leider geht so manches nicht. MariaDB, Nextcloud und NginxProxyManager hängen alle in einem internen Docker Netzwerk. Soweit so gut.

 

Über die jeweilige Container-Console erreiche ich per curl bzw. ping die jeweils anderen Container, d.h. sie sehen sich und können miteinander kommunizieren. In der config.php von Nextcloud habe ich die IP Adresse von MariaDB geändert, was scheinbar auch funktioniert hat, denn der occ Befehl im Nextcloud-Container geht durch und wirft mir nicht wie vor der Änderung Datenbank-Fehler aus.

 

Mein Problem ist nun aber: Obwohl ich in der Proxy Host Datei für Nextcloud die IP Adresse auf den neuen Adressraum des isolierten Containers geändert habe, klappt die Weiterleitung von der duckdns Adresse nicht. Darüber hinaus kann ich auch das Webinterface des ProxyManagers nicht öffnen - in Unraid möchte er sich noch über die alte IP-Adresse verbinden und selbst wenn ich die neue IP-Adresse eingebe und mit dem weitergeleiteten WebIF-Port versehe, kommt keine Verbindung zustande.

 

Hast du hierfür noch irgendwelche besonderen Einstellungen vorgenommen?

 

EDIT: Oh Mann, ich Depp. Das wird daran liegen, dass das Netzwerk keine Verbindungen von außen zulässt - "ping" von meinem Laptop aus landet auch im Nirgendwo...

 

EDIT2: Mein Hauptfehler lag darin, den NginxProxyManager in Unraid dauerhaft dem internen Netzwerk zuzuweisen. Dein "network connect" Befehl von oben brachte Abhilfe. Jetzt komme ich auf das WebIF des NginxProxyManager wieder drauf, jedoch klappt die Weiterleitung von der duckdns Adresse weiterhin nicht: Es kommt eine Verbindung zustande, jedoch erscheint dann eine "502 Bad Gateway" Fehlermeldung. Mal schauen, woran das liegt...

Edited May 1 by Pillendreher

[mgutt 752]

33 minutes ago, Pillendreher said:

Es kommt eine Verbindung zustande, jedoch erscheint dann eine "502 Bad Gateway" Fehlermeldung. Mal schauen, woran das liegt...

Wenn du die IP von NPM + den http Port öffnest, musst du eine Statusseite von NPM sehen können. Dann läuft NPM schon mal. Das selbe Spiel könntest du testen, in dem du im Router den Port testweise auch öffnest und deine DuckDNS Domain mit dem Port öffnest. Dann weißt du schon mal, dass der Traffic beim NPM landet. Dann liegt der Fehler nur noch beim Forward.

[i-B4se 31]

40 minutes ago, Pillendreher said:

Jetzt komme ich auf das WebIF des NginxProxyManager wieder drauf, jedoch klappt die Weiterleitung von der duckdns Adresse weiterhin nicht: Es kommt eine Verbindung zustande, jedoch erscheint dann eine "502 Bad Gateway" Fehlermeldung. Mal schauen, woran das liegt...

Ich hatte letzten das gleiche Problem mit "502" also ich alles auf einzelne IPs umgestellt habe. Ich nutze zwas kein DuckDNS, aber bei mir lag der Fehler darin, dass nicht alles mit br0 konfiguriert war.

Läuft alles, was du für NPM/Nextcloud etc. mit br0 unter verschiedenen IPs?

[Pillendreher 2]

Also im Moment ist das Ganze so konfiguriert:

 

MariaDB und Nextcloud sind in Unraid dem internen Netzwerk mit festen IPs zugeteilt (192.168.179.3 für MariaDB, 192.168.179.4 für Nextcloud). Nginx Proxy Manager ist in Unraid als "Bridge" konfiguriert und gleichzeitig mit dem internen Netzwerk verbunden:

 

root@Tower:~# docker network inspect isoliertes_netzwerk
[
    {
        "Name": "isoliertes_netzwerk",
        "Id": "***",
        "Created": "2021-05-01T09:50:21.852711971+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "192.168.179.0/24"
                }
            ]
        },
        "Internal": true,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "***": {
                "Name": "NginxProxyManager",
                "EndpointID": "***",
                "MacAddress": "***",
                "IPv4Address": "192.168.179.2/24",
                "IPv6Address": ""
            },
            "***": {
                "Name": "mariadb",
                "EndpointID": "***",
                "MacAddress": "***",
                "IPv4Address": "192.168.179.3/24",
                "IPv6Address": ""
            },
            "***": {
                "Name": "nextcloud",
                "EndpointID": "***",
                "MacAddress": "***",
                "IPv4Address": "192.168.179.4/24",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]

 

Wenn ich meine externe IPv4-Adresse aufrufe, erscheint Folgendes:

 

 

Nginx Proxy Manager scheint also zu laufen.

 

Nextcloud scheint wie gesagt auch eine Verbindung zu MariaDB hergestellt zu haben, denn der occ Befehl "geht durch", bringt also keine Fehlermeldung.

 

Im Nginx Proxy Manager sieht meine Weiterleitungs-Konfiguration so aus:

 

 

Und Nextcloud ist in Unraid als Docker Container so konfiguriert:

 

 

2 hours ago, mgutt said:

Wenn du die IP von NPM + den http Port öffnest, musst du eine Statusseite von NPM sehen können. Dann läuft NPM schon mal. Das selbe Spiel könntest du testen, in dem du im Router den Port testweise auch öffnest und deine DuckDNS Domain mit dem Port öffnest. Dann weißt du schon mal, dass der Traffic beim NPM landet. Dann liegt der Fehler nur noch beim Forward.

 

Tut mir Leid, aber verstehe nicht, was du mir hier empfiehlst. Ich habe in der Fritzbox ja bereits die Ports 443 und 80 für den Unraid Server geöffnet. Reicht das denn nicht?

 

1 hour ago, i-B4se said:

Ich hatte letzten das gleiche Problem mit "502" also ich alles auf einzelne IPs umgestellt habe. Ich nutze zwas kein DuckDNS, aber bei mir lag der Fehler darin, dass nicht alles mit br0 konfiguriert war.

Läuft alles, was du für NPM/Nextcloud etc. mit br0 unter verschiedenen IPs?

 

Ah, das würde darauf hindeuten, dass die Konfiguration nicht passt, also die Weiterleitung im Nirgendwo landet. Wie passt das aber damit zusammen, dass ich vom Nginx Proxy Manager Container erfolgreich einen Ping Richtung 192.168.179.4 (Nextcloud) schicken kann, und gleichzeitig der Nextcloud Container erfolgreich einen Ping Richtung 192.168.178.24 (Unraid Server) schicken kann? Andererseits frage ich mich aber: Müsste der Ping zum Unraid Server gerade nicht verhindert werden?!

Edited May 1 by Pillendreher