Frage zu SSL/Reverse Proxy

Schechner · 31. Mai 2021

Hallo

und vorab schon mal Entschuldigung wenn ich da etwas durcheinander würfele oder nicht richtig erläutere, ich gebe aber mein bestes.

Aber ich habe zu dem Thema ein paar Fragen die ich nicht verstehe.

Also erstmal zu meinen System ich benutze eine Synology 218+ ich hab einen DDNS von Synology und von no-ip.com eingerichtet.

bei no-ip ist der Name

https://xxx.ddns.net:5001/ --> damit komm ich auf meine Synology (erfolgreich)

bei synology gibt es ja die Option (die hat bei no-ip nicht funktioniert) von sub domains, hier habe ich

https://xxx.synology.me/ (mit https://xxx.synology.me:10443/ connecte ich auf mein gitlab container)
https://git.xxx.synology.me/https://vpn.xxx.synology.me/https://reg.xxx.synology.me/
So ich hoffe das reicht an Informationen zu meine System und meinen Beschaffenheiten ansonsten bitte melden

jetzt zu dem was ich nicht verstehe, eigentlich hatte ich mal angedacht, das ich nur einen DDNS nehme (den von Synology)
und damit über

https://xxx.synology.me/--> auf meine Synology connecte
https://git.xxx.synology.me/ --> auf mein Gitlab container
https://reg.xxx.synology.me/ --> für meine Gitlab regestry
https://peer.xxx.synology.me/ --> peertube
usw.....

jetzt ist es aber so (weil ich es nicht besser weiß bzw. hinbekomme) das ich per no-ip (https://xxx.ddns.net:5001/) auf meine synology connecte und mit der synology (https://xxx.synology.me:10443/) auf mein gitlab container.

Ich würde es aber gern einfacher/schöner halten in dem ich es wie oben mache.

Meine Frage, ich habe mir den Reverse Proxy im Anwendungsportal angeschaut. Jedoch hat das nie (richtig) funktioniert.

wäre es einfacher und/oder besser per Docker einen container für den Reverse Proxy zu erstellen? oder langt der von Synology?
Mach ich evtl. bei meiner container erstellung (gitlab netzwerk) falsch damit ich nicht connecten kann?
Muss ich die nginx per ssh bearbeiten?

ich hoffe ihr könnt mir helfen. Vielen vielen Dank schon mal

Gruß Marco

Anzeige · 31. Mai 2021

Hallo Schechner,

Bücher und Hardware zum Thema gibt es bei Amazon: Frage zu SSL/Reverse Proxy

Ulfhednir · 31. Mai 2021

Schechner schrieb:
wäre es einfacher und/oder besser per Docker einen container für den Reverse Proxy zu erstellen? oder langt der von Synology?

Wenn du schon mit dem Standard-GUI von Synology überfordert bist, wäre es keine gute Idee einen NGINX über Docker aufzusetzen.
Also hier mal der Reihe nach. Der Reverse Proxy macht dann Sinn, wenn man den Zugriff nur über einen zentralen Port laufen lassen und sich die zusätzlichen Portfreigaben ersparen möchte. Zusätzlich gibt es einen kleinen Sicherheitsgewinn, weil man zusätzlich zum Zugriff die URL benötigt.

Das heißt also für dich:

Angenommen, du möchtest dir im Browser die Eingabe des Ports ersparen, dann nimmst du hierfür einen Standardport. Idealerweise den für HTTPS - sprich 443. Hierzu richtest du dein Forwarding von deinem Router zur Diskstation ein. Also 443 an 443 (TCP).
Am Beispiel von Git würdest du dann im Reverse Proxy eine Regel definieren:

Das sähe dann ungefähr so aus:

Wobei das Ziel genauer zu definieren wäre. Ist Git auf der Diskstation gehostet, dann kannst du "theoretisch" localhost stehen lassen. Läuft Git über eine eigene IP, dann logischerweise ersetzen. Ebenso was den Port angeht. Im Kern gehören da die Daten rein, so wie du Git lokal ansprechen würdest.

Möchtest du auf DSM zugreifen, wäre HTTPS / localhost / 5001 reinzuklimpern.

Ich hoffe, dass dir damit ein wenig geholfen ist.

Schechner · 01. Jun 2021

Vielen Dank für deine Antwort.

Ulfhednir schrieb:
Wenn du schon mit dem Standard-GUI von Synology überfordert bist, wäre es keine gute Idee einen NGINX über Docker aufzusetzen.
Also hier mal der Reihe nach. Der Reverse Proxy macht dann Sinn, wenn man den Zugriff nur über einen zentralen Port laufen lassen und sich die zusätzlichen Portfreigaben ersparen möchte. Zusätzlich gibt es einen kleinen Sicherheitsgewinn, weil man zusätzlich zum Zugriff die URL benötigt.

Naja, überfordert würde ich nicht sagen, vielleicht noch nicht richtig eingewiesen

Es läuft ja soweit alles, ich wollte halt nur gerne einen DDNS benutzen für alles.

https://xxx.synology.me/--> auf meine Synology connecte
https://git.xxx.synology.me/ --> auf mein Gitlab container
https://reg.xxx.synology.me/ --> für meine Gitlab regestry
https://peer.xxx.synology.me/ --> peertube

Dazu brauch ich halt den Reverse Proxy ... aber irgendwie funktioniert die Weiterleitung von Synology zum Container nicht.

Ulfhednir schrieb:
Angenommen, du möchtest dir im Browser die Eingabe des Ports ersparen, dann nimmst du hierfür einen Standardport. Idealerweise den für HTTPS - sprich 443. Hierzu richtest du dein Forwarding von deinem Router zur Diskstation ein. Also 443 an 443 (TCP).
Am Beispiel von Git würdest du dann im Reverse Proxy eine Regel definieren:

ich würde mir gerne einmal den Port gerne sparen und auch noch (wie oben geschrieben) eine einfache zu merkende Syntax mit Sub Domains

Ulfhednir schrieb:
Das sähe dann ungefähr so aus:

Wobei das Ziel genauer zu definieren wäre. Ist Git auf der Diskstation gehostet, dann kannst du "theoretisch" localhost stehen lassen. Läuft Git über eine eigene IP, dann logischerweise ersetzen. Ebenso was den Port angeht. Im Kern gehören da die Daten rein, so wie du Git lokal ansprechen würdest.

Möchtest du auf DSM zugreifen, wäre HTTPS / localhost / 5001 reinzuklimpern.

ich kann leider das Bild nicht anschauen.

Git ist auf meiner DS als Container gehostet. Wie finde ich die Container ip raus? was ist wenn die ip nicht in meinem Subnetz ist?

aber vielen danke nochmal für deine Unterstützung

gruß
Marco

Ulfhednir · 02. Jun 2021

Schechner schrieb:
Naja, überfordert würde ich nicht sagen, vielleicht noch nicht richtig eingewiesen

Das kann man sich jetzt schönreden wie man will - Fakt ist, du hast es nicht autodidaktisch auf die Kette bekommen. ?

Schechner schrieb:
Es läuft ja soweit alles, ich wollte halt nur gerne einen DDNS benutzen für alles.

https://xxx.synology.me/--> auf meine Synology connecte
https://git.xxx.synology.me/ --> auf mein Gitlab container
https://reg.xxx.synology.me/ --> für meine Gitlab regestry
https://peer.xxx.synology.me/ --> peertube

Dazu brauch ich halt den Reverse Proxy ... aber irgendwie funktioniert die Weiterleitung von Synology zum Container nicht.

Dein Problem wurde ausreichend beschrieben, es hilft auch nicht nochmal eine Auflistung deiner gewünschten DDNS zu machen.

Schechner schrieb:
ich würde mir gerne einmal den Port gerne sparen und auch noch (wie oben geschrieben) eine einfache zu merkende Syntax mit Sub Domains

Auch hier nochmal der Hinweis: Mir ist vollkommen klar, was du vor hast. Ich habe ein ähnliches Konstrukt - allerdings tatsächlich mit einem Nginx (Docker). Was du vorhast geht prinzipiell mit den Werkeinstellungen deiner DS.

Schechner schrieb:
ich kann leider das Bild nicht anschauen.

Dann schau mal, dass du auf i.imgur.com zugreifen kannst (Firewall / DNS)

Schechner schrieb:
Git ist auf meiner DS als Container gehostet. Wie finde ich die Container ip raus? was ist wenn die ip nicht in meinem Subnetz ist?

Ich bin Freund der Didaktik - da geht es vom einfachen zum schweren. Also vergiss erst einmal GIT und versuche erst einmal auf deine Diskstation raufzukommen.

Punkt 1.) Port 443 an Port 443 der Diskstation weiterleiten
Punkt 2.) DynDNS registrieren und prüfen, ob der DynDNS auch tatsächlich auf deine externe IP greift
Punkt 3.) Reverse Proxy Eintrag

Code:

Quelle:
Protokoll: HTTPS
Hostname: DeinDYNS.xyz
Port: 443

Ziel:
Protokoll: HTTPS
Hostname: localhost
Port: 5001

Heißt zu Deutsch - wenn du extern über https://DeinDYNS.xyz:443 zugreifst, wirst du auf die Diskstation weitergeleitet.
Bevor das nicht funktioniert, macht es keinen Sinn sich über dein Git-Repository zu unterhalten.

Aber eines gerne noch Vorweg: Du solltest dich wohlmöglich mit den Netzwerkgrundlagen von Docker beschäftigen. Stichwort Network Driver (Host / Bridge / macVLAN). Damit ergibt sich deine Frage, "was ist wenn die IP nicht in meinem Subnetz ist?".

Schechner · 02. Jun 2021

Ulfhednir schrieb:
Ich bin Freund der Didaktik - da geht es vom einfachen zum schweren. Also vergiss erst einmal GIT und versuche erst einmal auf deine Diskstation raufzukommen.

Punkt 1.) Port 443 an Port 443 der Diskstation weiterleiten
Punkt 2.) DynDNS registrieren und prüfen, ob der DynDNS auch tatsächlich auf deine externe IP greift
Punkt 3.) Reverse Proxy Eintrag

Den ersten Punkt hätte ich auf meiner Liste abgehackt

über https://xxx.synology.me/ komm ich jetzt auf meine DS

Ulfhednir schrieb:
Heißt zu Deutsch - wenn du extern über https://DeinDYNS.xyz:443 zugreifst, wirst du auf die Diskstation weitergeleitet.
Bevor das nicht funktioniert, macht es keinen Sinn sich über dein Git-Repository zu unterhalten.

Das Funktioniert ich kann über https://xxx.synology.me/ zugreifen. (lokal und über i-net)

Ulfhednir schrieb:
Aber eines gerne noch Vorweg: Du solltest dich wohlmöglich mit den Netzwerkgrundlagen von Docker beschäftigen. Stichwort Network Driver (Host / Bridge / macVLAN). Damit ergibt sich deine Frage, "was ist wenn die IP nicht in meinem Subnetz ist?".

Das heißt ich müsste am besten ein macVLAN machen?

weil aktuell mein Container per Bridge so nicht funktioniert?

vielen dank nochmal für deine Hilfe

Ulfhednir · 02. Jun 2021

Schechner schrieb:
Das heißt ich müsste am besten ein macVLAN machen?

weil aktuell mein Container per Bridge so nicht funktioniert?

Anhang anzeigen 62376

Dann scheinst du den Unterschied zwischen Bridge und macVLAN nicht verstanden zu haben. Für deine Schritte sollte es erstmal keinen Unterschied machen. Die Frage wäre hier: Mit welchem Port deiner Diskstation ist denn dein Gitlab verknüpft? Das ergibt sich aus deiner Darstellung nicht.
Du schriebst etwas von Port 10443 - ist das deine GIT-Weboberfläche? Dann wäre analog zu der Konfiguration von DSM die Einstellung zu hinterlegen.
Allerdings mit dem Unterschied, dass du mutmaßlich als Ziel HTTP auswählen musst.

Es wäre auch hilfreich, wenn du deine "Installationsanleitung" oder .yaml bereitstellst, ebenfalls die Porteinstellungen sowie Umwelt deiner Docker-Container. Sonst ist das alles nur Rätselraten. Es kann sogar sein, dass du dem Container deine gewünschte URL als Variable mitgeben musst.

Schechner · 02. Jun 2021

Ulfhednir schrieb:
Die Frage wäre hier: Mit welchem Port deiner Diskstation ist denn dein Gitlab verknüpft? Das ergibt sich aus deiner Darstellung nicht.

ich kann auf gitlab mit https://xxx.synology.me:10443/ connecten

Ulfhednir schrieb:
Du schriebst etwas von Port 10443 - ist das deine GIT-Weboberfläche?

Ja genau

Ulfhednir schrieb:
Dann wäre analog zu der Konfiguration von DSM die Einstellung zu hinterlegen.
Allerdings mit dem Unterschied, dass du mutmaßlich als Ziel HTTP auswählen musst.

Ich habe das mal probiert mit HTTPS und HTTP

jedoch wenn ich git.xxx.synology.me eingebe werde ich weitergeleitet auf https://git.xxx.synology.me:5001/ (das https ist durchgestrichen) und ich komme auf das login meiner Synology

Ulfhednir schrieb:
Es wäre auch hilfreich, wenn du deine "Installationsanleitung" oder .yaml bereitstellst, ebenfalls die Porteinstellungen sowie Umwelt deiner Docker-Container.

meinst du meine Docker-compose ?

Code:

version: '3.7'

services:
  redis:
    restart: always
    container_name: redis
    image: redis:5.0.9
    command:
    - --loglevel warning
    volumes:
    - ${HomeDir}/redis:/var/lib/redis
    env_file:
    - ./.env

  postgresql:
    restart: always
    container_name: postgresql
    image: sameersbn/postgresql:12-20200524
    volumes:
    - ${HomeDir}/postgresql:/var/lib/postgresql
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm,btree_gist
    env_file:
    - ./.env

  gitlab:
    restart: always
    image: sameersbn/gitlab:13.10.3
    container_name: gitlab
    depends_on:
    - redis
    - postgresql
    ports:
    - "${GitlabHttpPort}:80"
    - "${GitlabsshPort}:22"
    - "${GitlabsslPort}:443"
    volumes:
    - ${HomeDir}/gitlab/config:/etc/gitlab
    - ${HomeDir}/gitlab/logs:/var/log/gitlab
    - ${HomeDir}/gitlab/data:/home/git/data
    - ${HomeDir}/gitlab/opt:/var/opt/gitlab
    healthcheck:
      test: ["CMD", "/usr/local/sbin/healthcheck"]
      interval: 5m
      timeout: 10s
      retries: 3
      start_period: 5m
    environment:
    - DEBUG=true

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=Europe/Berlin
    - GITLAB_TIMEZONE=Berlin

    - GITLAB_HTTPS=true
    - SSL_SELF_SIGNED=true

    - GITLAB_HOST= ${GitlabHost}
    - GITLAB_PORT=${GitlabsslPort}
    - GITLAB_SSH_PORT=${GitlabsshPort}
    - GITLAB_SECRETS_DB_KEY_BASE=${GitlabSecretDB}
    - GITLAB_SECRETS_SECRET_KEY_BASE=${GitlabSecretSecret}
    - GITLAB_SECRETS_OTP_KEY_BASE=${GitlabSecretOtp}

    - GITLAB_ROOT_PASSWORD=${GitlabRootPw}
    - GITLAB_ROOT_EMAIL=${GitlabMail}

    - GITLAB_NOTIFY_ON_BROKEN_BUILDS=true
    - GITLAB_NOTIFY_PUSHER=false

    - GITLAB_EMAIL=notifications@example.com
    - GITLAB_EMAIL_REPLY_TO=noreply@example.com
    - GITLAB_INCOMING_EMAIL_ADDRESS=reply@example.com

    - GITLAB_BACKUP_SCHEDULE=daily
    - GITLAB_BACKUP_TIME=01:00

    - SMTP_ENABLED=true
    - SMTP_DOMAIN=gmail.com
    - SMTP_HOST=smtp.gmail.com
    - SMTP_PORT=587
    - SMTP_USER=${GitlabMail}
    - SMTP_PASS=${GitlabSmtpPw}
    - SMTP_STARTTLS=true
    - SMTP_AUTHENTICATION=login
    env_file:
    - ./.env

  gitlab-runner:
    restart: always
    image: gitlab/gitlab-runner:latest
    container_name: gitlab-runner
    depends_on:
    - gitlab
    volumes:
    - /run/docker.sock:/var/run/docker.sock
    - ${HomeDir}/gitlab-runner/config:/etc/gitlab-runner
    env_file:
    - ./.env

in meiner env ist folgendes

Code:

#Homedir
HomeDir=/volume1/docker/gitlab

#Gitlab env
GitlabHost=xxx.synology.me
GitlabHttpPort=10080
GitlabsshPort=10022
GitlabsslPort=10443

Ulfhednir schrieb:
Sonst ist das alles nur Rätselraten. Es kann sogar sein, dass du dem Container deine gewünschte URL als Variable mitgeben musst.

Immer nur sagen wenn was fehlt, ich probiere alles, damit es (so einfach wie möglich) funktioniert.

Ulfhednir · 02. Jun 2021

Schechner schrieb:
#Gitlab env
GitlabHost=xxx.synology.me
GitlabHttpPort=10080
GitlabsshPort=10022
GitlabsslPort=10443

Als GitlabHost sollte wahrscheinlich eher https://git.xxx.synology.me/ anstelle von xxx.synology.me stehen (DSM)?! Das heißt den Container mit der richtigen URL neu erstellen. Hier wird möglicherweise der Redirect auf dein DSM erzeugt.

Schechner · 02. Jun 2021

Ulfhednir schrieb:
Als GitlabHost sollte wahrscheinlich eher https://git.xxx.synology.me/ anstelle von xxx.synology.me stehen (DSM)?! Das heißt den Container mit der richtigen URL neu erstellen.

ich habe es geändert auf git.xxx.synology.me und neu erstellt.
Wenn ich git.xxx.synology.me in den Browser eingeben komm folgendes.

400 Bad Request

The plain HTTP request was sent to HTTPS port

nginx

Ulfhednir schrieb:
Hier wird möglicherweise der Redirect auf dein DSM erzeugt.

Das versteh ich nicht ganz, muss ich da was machen oder macht das die DSM da was?

Ulfhednir · 02. Jun 2021

Schechner schrieb:
ich habe es geändert auf git.xxx.synology.me und neu erstellt.

Zum Verständnis: Du hast den Container gelöscht, die #Gitlab env abgeändert und den Container neu erstellt, korrekt?
Wenn ja: Bitte noch als Ziel anstelle der 10443 die 10080 (HTTP) probieren.

Schechner · 03. Jun 2021

Ulfhednir schrieb:
Zum Verständnis: Du hast den Container gelöscht, die #Gitlab env abgeändert und den Container neu erstellt, korrekt?

Ja genau über ssh "docker-compose down" werte in der env geändert und dann "docker-compose up -d"

Ulfhednir schrieb:
Wenn ja: Bitte noch als Ziel anstelle der 10443 die 10080 (HTTP) probieren.

habe ich geändert und in der DS angepasst.

im Docker unter dem Gitlab container wird mir bei der Umgebungsvariablen auch das "richtige" angezeigt

wenn ich jetzt im browser git.xxx.synology.me eingebe leitet der mich an an https://git.xxx.synology.me:10080/ weiter und bringt folgendes

Die Verbindung mit dieser Website ist nicht sicher.

git.xxx.synology.me hat eine ungültige Antwort gesendet.

Versuchen Sie, die Windows-Netzwerkdiagnose auszuführen.

ERR_SSL_PROTOCOL_ERROR

Schechner · 07. Jun 2021

Ich hab jetzt auch mal in den Einstellungen rum gespielt..... sprich
GITLAB_HTTPS=true/false
SSL_SELF_SIGNED=true/false

in verschiede Kombinationen, jedoch ohne erfolg.

Benares · 07. Jun 2021

Leg mal unter /usr/local/etc/nginx/sites-enabled eine Datei git-rewrite.conf mit folgendem Inhalt an:

Code:

server {
        listen 80;
        server_name git.xxx.synology.me;

        return 301 https://$host$request_uri;
}

Schechner · 07. Jun 2021

ok, ist angelegt. muss ich dann irgendwas Neu starten?

wie sollten meine Einstellung aussehen?

GITLAB_HTTPS=true
SSL_SELF_SIGNED=true
GITLAB_HOST= git.xxx.synology.me
GITLAB_PORT=10443

wenn ich jetzt git.xxx.synology.me eingebe leitet er mich an https://git.xxx.synology.me:10080/ weiter mit dem Error:

Die Verbindung mit dieser Website ist nicht sicher.

git.xxx.synology.me hat eine ungültige Antwort gesendet.

Versuchen Sie, die Windows-Netzwerkdiagnose auszuführen.

ERR_SSL_PROTOCOL_ERROR

Benares · 07. Jun 2021

Zumindest nginx solltest du mal durchstarten (synoservicecfg --restart nginx).
Momentan leitest du ja https über den Reverse-Proxy nach http weiter, deshalb auch diese rewrite-rule. Jetzt bleib erstmal bei http und dreh nicht an mehreren stellen gleichzeitig.

Schechner · 07. Jun 2021

Benares schrieb:
Zumindest nginx solltest du mal durchstarten (synoservicecfg --restart nginx).

habe ich ausgeführt

Benares schrieb:
Momentan leitest du ja https über den Reverse-Proxy nach http weiter, deshalb auch diese rewrite-rule. Jetzt bleib erstmal bei http und dreh nicht an mehreren stellen gleichzeitig.

ja schon, aber da ich schon ein bisschen rumprobiert habe, wollte ich nur noch mal auf Nummer sicher gehen, das wir den selben nenner haben.

Benares · 07. Jun 2021

Ich habe kein Git installiert, dafür aber einige andere Dienste, die lokal als http laufen, aber von extern über https und Reverse-Proxy mit rewrite-rule angesprochen werden. Bei allen ist gleich, dass erstmal http://<ip-der-ds>:<port> lokal funktionieren muss, bevor man den Reverse-Proxy darüber setzt.

Schechner · 07. Jun 2021

Benares schrieb:
Ich habe kein Git installiert, dafür aber einige andere Dienste, die lokal als http laufen, aber von extern über https und Reverse-Proxy mit rewrite-rule angesprochen werden. Bei allen ist gleich, dass erstmal http://ip-der-dsort lokal funktionieren muss, bevor man den Reverse-Proxy darüber setzt.

also was funktioniert hat ist https://xxx.synology.me:10443 oder https://192.168.x.x:10443/ (jedoch mit durchgestrichenem https) wäre ja wie du schreibst schon mal ein anfang oder?

Benares · 08. Jun 2021

Dann hast du aber auch 10443 in der Fritzbox an die DS weitergeleitet, oder?
Dass https mit der IP nicht funktioniert ist klar, da das Zertifikat ja nicht auf die IP ausgestellt ist.

Hast du es auch schon mal mit einem Reverse-Proxy
HTTPS,git.xxx.synology.me,443 -> HTTPS,localhost,10443
probiert?

Schechner · 08. Jun 2021

Benares schrieb:
Dann hast du aber auch 10443 in der Fritzbox an die DS weitergeleitet, oder?

ja

Benares schrieb:
Dass https mit der IP nicht funktioniert ist klar, da das Zertifikat ja nicht auf die IP ausgestellt ist.

muss ich dann in den config doch was ändern?

Benares schrieb:
Hast du es auch schon mal mit einem Reverse-Proxy
HTTPS,git.xxx.synology.me,443 -> HTTPS,localhost,10443
probiert?

ja habe ich, jedoch funktioniert das nicht

Frage zu SSL/Reverse Proxy

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

400 Bad Request​

Benutzer

Benutzer

Die Verbindung mit dieser Website ist nicht sicher.​

Benutzer

Benutzer

Benutzer

Die Verbindung mit dieser Website ist nicht sicher.​

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Kaffeautomat

400 Bad Request

Die Verbindung mit dieser Website ist nicht sicher.

Die Verbindung mit dieser Website ist nicht sicher.