Reverse Proxy für lokale SSL-Zertifikate mit NGINX und Pihole -> Port 443 Konflikt

[yosemite]

Hallo,

ich möchte gerne die Lösung für einen Reverse Proxy nebst lokalen SSL-Zertifikaten gemäß diesem Vorschlag umsetzen.

https://www.youtube.com/watch?v=nmE28_BA83w
https://www.wundertech.net/local-ssl-for-home-lab-services-nginx-proxy-manager/

Die nötigen Einrichtungen in Cloudflare sind alle vorgenommen und funktionieren auch.

Ich nutze das compose-file aus der Verlinkung, welches ich für meine Bedürfnisse angepasst habe und auch die Änderungen für Pihole V6 durchgeführt habe (hatte ich anfänglich übersehen).

version: "3"
# Instructions: https://www.wundertech.net/local-ssl-for-home-lab-services-nginx-proxy-manager/
services:
  npm:
    container_name: npm
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      # These ports are in format <host-port>:<container-port>
      - '80:80' # Public HTTP Port
      - '443:443' # Public HTTPS Port
      - '81:81' # Admin Web Port
    volumes:
      - /volume4/docker/npm/data:/data
      - /volume4/docker/npm/letsencrypt:/etc/letsencrypt
    networks:
     npm_zbridge:
       ipv4_address: 192.168.100.10
       priority: 900
     npm_network:
       ipv4_address: 192.168.1.197
       priority: 1000
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
      - "80:80/tcp"
    environment:
      TZ: 'Europe/Berlin'
      FTLCONF_webserver_api_password: meinpasswort
      FTLCONF_dns_listeningMode: local
    # Volumes store your data between container upgrades
    volumes:
      - '/volume4/docker/pihole/pihole:/etc/pihole'
      - '/volume4/docker/pihole/dnsmasq.d:/etc/dnsmasq.d'
    networks:
     npm_network:
       ipv4_address: 192.168.1.198
    cap_add:
      - NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
    restart: unless-stopped
networks:
    npm_zbridge:
      name: npm_zbridge
      driver: bridge
      ipam:
        config:
          - subnet: 192.168.100.0/24
            gateway: 192.168.100.1
            ip_range: 192.168.100.0/24
    npm_network:
      name: npm_network
      driver: macvlan
      driver_opts:
        parent: ovs_eth4
      ipam:
        config:
          - subnet: 192.168.1.0/24
            ip_range: 192.168.1.0/24
            gateway: 192.168.1.100

Die Installation für NGINX schlägt fehl ("driver failed external programming..."), da der Port 443 schon in Verwendung sei ("...0.0.0.0:443 is already allocated").

Ich habe bei mir Webstation installiert und da diese neben einer "eigenen" Version von NGINX die Ports 80 und 443 nutzt, kann ich mir vorstellen, dass dies das Problem ist. Warum für Port 80 keine Fehlermeldungen erfolgen, kann ich mangels Netzwerk-Knowhow nicht sagen.

Pihole läuft und lässt sich auch konfigurieren. Wenn ich aus dem compose-file die Zeile mit Port 443 entferne, da läuft auch die Installation von NGINX durch und ich kann auf das Admin-Panel zugreifen. Natürlich ist das aber nicht Sinn der Sache, da NGINX ohne Port 443 seine Arbeit nicht wie vorgesehen durchführen kann.

Wenn meine Recherchen richtig sind, dann sollte man ja Port 80 und 443 nicht verbiegen.
Gibt es dafür eine Lösung, um die Installation doch noch erfolgreich durchzuführen? Ich habe zig Beiträge zu dem Thema gelesen, aber nicht wirklich eine Lösung gefunden.

Kann man vermuten, warum es in dem Video läuft (keine Webstation installiert?), ohne dass es Konflikte gibt?

Auf Mariushosting sehe ich, dass er Port 8341 und 8766 auf 80 und 443 mapped, aber ich würde es lieber so wie von Wundertech beschrieben machen, besonders da ich auch auf die Cloudflare-Einbindung setze.

Danke!

 

[bonnma]

Zum verbiegen der Ports gibt es ein Script hier im Forum. Das muss aber bei jedem Neustart ausgeführt werden. Findest Du bestimmt selber.

Nur zum Verständnis für mich: Die Syno hat einen Reverse Proxy integriert. Was ist so besonders an der Lösung zusätzlich in Docker einen haben zu wollen? Ich habe mehrere Jahre mit der Syno Variante gearbeitet und habe nichts vermisst!

 

[yosemite]

Hallo,

ja, den Weg über das Script kenne ich bzw. habe ich gesehen, aber das kommt für mich nicht in Frage.

Der Syno Reverse Proxy (so wie ich es sehe ist es ja eine angepasste NGINX-Version, aber das wissen die Profis besser) kann meines Erachtens keine Wildcard-Zertifikate (die man über diese Lösung auch nicht ständig erneuern muss), was für mich in Verbindung mit Cloudflare wichtig wäre. Das ganze Zusammenspiel mit NGINX und Pihole ist hier elegant gelöst. Ich muss nichts im Router konfigurieren (kein Port Forwarding).

Den hauseigenen Reverse Proxy habe ich auch schon ab und an mal genutzt und er funktioniert sicherlich. In diesem Fall ist es aber keine Option.

 

[Benares]

Klar geht der Haus-eigene Reverse-Proxy auch mit Wildcard-Zertifikaten. Man muss nur die Apps zu den Zertifikaten korrekt zuordnen.

 

[JohneDoe]

Klar geht der Haus-eigene Reverse-Proxy auch mit Wildcard-Zertifikaten.

Ja? Wie erzeugst du denn ein Wildcard Zertifikat mit Synology Boardmitteln für eine andere Domain als *.synology.me. Du kannst doch kein Wildcard für *.example.com bekommen. Du musst dich da selber um die Zertifikate kümmern...

@yosemite Ich würde mir überlegen, ob es vielleicht einfacher wäre, wenn du dir eine kleine VM installierst und da dann dein NPM. Dann hast du keine Probleme mit den Ports und das System ist auch noch mal isolierter.

 

[yosemite]

Klar geht der Haus-eigene Reverse-Proxy auch mit Wildcard-Zertifikaten. Man muss nur die Apps zu den Zertifikaten korrekt zuordnen.

Exakt all das entfällt mit der in dem Video beschriebenen Methode. Ich will definitiv nicht diese ewigen "Bastelarbeiten" sondern eine strukturierte Vereinfachung.

Das ist jetzt vielleicht eher Ansichtssache oder persönlicher Geschmack.

Es bleibt die Frage nach dem Port 443.

 

[JohneDoe]

Mit den Ports ist es eben nicht getan. Du richtest dir ein MACVLAN ein (wenn du nicht weißt, was das bedeutet, dann musst du mal googlen), das heißt du kannst nicht ohne "Bastelei" zwischen Host und Container kommunizieren. Du kannst dann also in deinem NPM keinen Dienst auf der NAS erreichen. Dafür musst du erst eine Bridge einrichten. Dies muss bei jedem Boot passieren. Daher die Vorschlag mit der VM

 

[Benares]

Ja? Wie erzeugst du denn ein Wildcard Zertifikat mit Synology Boardmitteln für eine andere Domain als *.synology.me

Mit neilpang-acme.sh als Docker-Container auf der DS1522+. Der übernimmt nicht nur die Erneuerung, sondern auch die Verteilung auf meine andere DS, einer DS415+

 

[plang.pl]

Wenn der erweiterte Umfang eines separaten RPs nicht gebraucht wird und es nur um die Certs geht, würde ich auch eher auf den nativen RP der DS + acme.sh setzen. Oder den RP stattdessen auf einem anderen Host oder in einer VM laufen lassen

 

[JohneDoe]

@Benares Ja, aber das ist ja nicht Boardmitteln und hat nichts mit dem Reverse Proxy der Synology zu tun. DSM ist eben nur eine Option die acme.sh unterstützt zum Zertifikate deployen. Andere RPs haben den Vorteil, dass die sich selber drum kümmern. Man muss da nichts konfigurieren. Bei Caddy z.B. holt er für jede Domain die du nutzt von sich auch ein Zertifikat.

 

[Benares]

Ich zähle auch Docker-Container zu den Bordmitteln, und acme.sh halt halt auch einen Deploy-Hook für DSM.

 

[JohneDoe]

Nach der Definition würde auch der Nginx Proxy Manager oder jeder andere RP zu Boardmitteln zählen

Aber @yosemite, wenn du keine VM oder ein anderes Gerät als RP nutzen willst, dann bleibt dir nichts anderes übrig, als dich in MACVLAN einzuarbeiten. Ich nutze kein MACVLAN, weil es gefühlt mehr Probleme bringt als es löst.

 

[plang.pl]

Oder die Belegung der Ports durch DSM deaktivieren.
MACVLAN kann man auch machen. Wenn man sich damit aber nicht auskennt, kommen gerne wilde Fehler zusammen, die einem graue Haare verpassen können.
Ich sehe beide Optionen als Bastelei und instabil / fehleranfällig. Sauberer ist m.E. RP auf anderem Host / VM oder nativer nginx + acme.sh

 

[haydibe]

Ergänzung zu macvlan: wenn ich mich recht erinnere funktioniert macvlan nicht, wenn man die Syno-Firewall verwendet.
Korrigiert mich, wenn ich mich falsch erinnern sollte.

 

[yosemite]

Danke für das umfangreiche Feedback. Das weiß ich immer sehr zu schätzen.

Aber die Diskussion geht etwas in die falsche Richtung. Dass mit dem macvlan, der bridge etc. funktioniert prinzipiell alles bestens. Wer mag schaut sich noch einmal das Video und vielleicht auch das passende Cloudflare-Video an, welche den Sinn dieser Konfiguration vermitteln. Ich nutze bereits jetzt sehr elegant und performant den Zugang über eine dafür registrierte Domain nebst verschiedenen Diensten mit Cloudflare und kann praktisch von Drive bis DSM zugreifen. Diese Funktionalität möchte ich allerdings wie in dem Video zu sehen etwas eleganter gestalten und auch noch zusätzlich die Vorteile mit Pihole nutzen (Pihole läuft als einzelner Docker wunderbar).
Ich möchte auch keine Raspberries, VMs oder native Lösungen.

Der Thread kann geschlossen werden.

 

[JohneDoe]

Wenn dein MACVLAN funktionieren würde, dann hättest du kein Port Problem. Nur noch soviel dazu.

@haydibe oh ok. Hat Synology da wieder was eigenes verbaut? Da ich beides nicht nutze, kann ich dazu leider nichts sagen.

 

[plang.pl]

wenn ich mich recht erinnere funktioniert macvlan nicht, wenn man die Syno-Firewall verwendet.

Es ist anders herum. Wenn man MACVLAN verwendet, funktioniert die Firewall nicht
Also die Firewall der DS greift nicht auf MACVLAN Container. Dort ist quasi immer alles offen.

 

[haydibe]

Danke für die Korrektur. War auch falsch geschrieben von mir: ich hatte nur im Hinterkopf, dass die Syno-Firewall damit nicht klarkommt.
Ich wusste nicht mehr, ob alles durchgelassen oder blockiert wird.

 

[JohneDoe]

Aber das liegt ja nur an Synology oder? Auf einem Debian z.B. kann man sowas normal mit Firewall regeln. Da kann man allerdings auch mit IPs arbeiten. Also als Quelle und Ziel....

 

[plang.pl]

Ich hab keine Ahnung, wie eine "normale" Firewall im MACVLAN arbeitet