Frage zu SSL/Reverse Proxy

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
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 :D

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
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.262
Punkte für Reaktionen
921
Punkte
174
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:
qDdReZP.png


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

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Vielen Dank für deine Antwort.

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 :D
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.

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


Das sähe dann ungefähr so aus:
qDdReZP.png


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

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.262
Punkte für Reaktionen
921
Punkte
174
Naja, überfordert würde ich nicht sagen, vielleicht noch nicht richtig eingewiesen :D
Das kann man sich jetzt schönreden wie man will - Fakt ist, du hast es nicht autodidaktisch auf die Kette bekommen. ?

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.

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.

ich kann leider das Bild nicht anschauen.
Dann schau mal, dass du auf i.imgur.com zugreifen kannst (Firewall / DNS)
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

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
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


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)

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?

1622609816058.png

vielen dank nochmal für deine Hilfe
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.262
Punkte für Reaktionen
921
Punkte
174
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

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
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

Du schriebst etwas von Port 10443 - ist das deine GIT-Weboberfläche?
Ja genau

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

1622631937473.png

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

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

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

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.262
Punkte für Reaktionen
921
Punkte
174
#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

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
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

1622642825280.png

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

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.262
Punkte für Reaktionen
921
Punkte
174
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

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
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"

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

git.png

1622710196325.png

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.

ERR_SSL_PROTOCOL_ERROR
 

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
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;
}
 
Zuletzt bearbeitet:

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
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.

ERR_SSL_PROTOCOL_ERROR
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
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

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Zumindest nginx solltest du mal durchstarten (synoservicecfg --restart nginx).
habe ich ausgeführt

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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
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.
 
Zuletzt bearbeitet:

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
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.
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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
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

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Dann hast du aber auch 10443 in der Fritzbox an die DS weitergeleitet, oder?
ja
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?

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
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat