nginxproxymanager vs proxy von der Synology

MattCB

Benutzer
Mitglied seit
31. Jan 2012
Beiträge
382
Punkte für Reaktionen
71
Punkte
28
Okay, man ist also auf die DNS-Anbieter aus der Liste beschränkt. Da ich meinen DNS-Einträge über ipv64 manage, fällt das dann wohl raus. Oder ich schau mich mal bei Netcup um, wenn die mal wieder Domain-Aktionen haben. Bin mit Strato eigentlich ganz zufrieden, da zahle ich aus einer Aktion dauerhaft 79 Cent pro Monat für 2 Domains. Da die aber keine DNS-Challenge können, manage ich meine DNS-Einträge über ipv64.net.

Wobei Strato in der Liste der Anbieter im ProxyManager auch auftaucht, ich sollte das vielleicht mal versuchen. Mehr als nicht funktionieren geht ja nicht. ;-)

Das Problem, wenn man keine Wildcards anlegen kann: man kann ja nur eine bestimmte Anzahl an Zertifikaten pro Tag bei LetsEncrypt anfordern, soweit ich weiß. Dann muss man eine Weile warten.
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Du könntest auch einfach andere Nameserver nutzen. Ich habe meine Domain bei Netcup und nutze die Nameserver von Cloudflare. Dann ist es egal wo die Domains registriert sind.
 
  • Like
Reaktionen: MattCB

MattCB

Benutzer
Mitglied seit
31. Jan 2012
Beiträge
382
Punkte für Reaktionen
71
Punkte
28
Mache ich ja bereits, nutze dafür ipv64, aber der ist halt nicht in der Liste beim Proxy Manager. ;-)

EDIT: Ich sehe gerade, dass mich eine Domain bei Netcup gerade mal 42 Cent pro Monat kostet. Das wäre ja mal ein Versuch wert. Reicht da eine normale Domain, damit ich die per API bearbeiten kann? Oder braucht man da ein teureres Paket?

EDIT2: So wie ich das sehe, kann Netcup von sich aus kein DynDNS? Somit wäre das schon mal raus.
 
Zuletzt bearbeitet:

MattCB

Benutzer
Mitglied seit
31. Jan 2012
Beiträge
382
Punkte für Reaktionen
71
Punkte
28
So, ich habe jetzt mal eine Nextcloud in einem LXC-Container auf Proxmox installiert. Als ReverseProxy nehme ich noch den von Synology.

Aber wie ums Verrecken bekomme ich mit dem Synology-RP folgende Fehlermeldung weg:

  • Ihr Webserver ist nicht richtig konfiguriert um "/.well-known/caldav" aufzulösen. Weitere Informationen hierzu finden Sie in unserer Dokumentation ↗.
  • Ihr Webserver ist nicht richtig konfiguriert um "/.well-known/carddav" aufzulösen. Weitere Informationen hierzu finden Sie in unserer Dokumentation ↗.
Man kann zwar die Datei /etc/nginx/sites-enables/server.ReverseProxy.conf bearbeiten und im Bereich für die Nextcloud folgendes hinzufügen:

Code:
location /.well-known/carddav {
    return 301 $scheme://$host/remote.php/dav;
}

location /.well-known/caldav {
    return 301 $scheme://$host/remote.php/dav;
}

aber das fliegt scheinbar gleich wieder raus. Aber eine andere Möglichkeit, diese Optionen einzupflegen, gibt es ja mit dem Synology-RP nicht. Deshalb der Versuch mit dem nginx Proxy Manager, da man den etwas feiner konfigurieren kann.
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.475
Punkte für Reaktionen
1.087
Punkte
194

MattCB

Benutzer
Mitglied seit
31. Jan 2012
Beiträge
382
Punkte für Reaktionen
71
Punkte
28
Ja, das acme.sh Script läuft ja hier auf der Syno mit ipv64 problemlos.
 

daschmidt94

Benutzer
Mitglied seit
17. Mai 2020
Beiträge
266
Punkte für Reaktionen
19
Punkte
24
@alexhell kannst du mir evtl. noch einmal kurz helfen?

Hab jetzt mal das Grundgerüst von dir bis ##Optional## zum laufen bekommen.

Aber irgendwie kapier ich das mit dem weiterleiten nicht.

Es soll z.B. vaultwarden.xxx.at dann intern auf 192.168.178.19:5151 zeigen. Leider komme ich mit den Beschreibungen nicht vorran.
Hättest du hierfür ein einfaches Beispiel?
 

MattCB

Benutzer
Mitglied seit
31. Jan 2012
Beiträge
382
Punkte für Reaktionen
71
Punkte
28
Und die Moral von der G'schicht:

Domain für 5€ im Jahr bei Netcup geholt. Die Nameserver auf die von Cloudflare gestellt, über den Docker-Container oznu/cloudflare-ddns lasse ich die dynamische IP bei Cloudflare aktualisieren. Jetzt klappt das auch mit dem Wildcard-Zertifikat über den nginx Proxy Manager. Also werde ich die Nameserver meiner Hauptdomain auch zu Cloudflare setzen, dann sollte das damit auch gehen.

Danke an @alexhell für die Anleitung bezüglich Cloudflare DNS. War ja letzten Endes doch ganz einfach. (y)

Im Nachhinein betrachtet hätte ich mir die Netcup Domain dann sparen können. Aber so habe ich eine Domain mehr. Jetzt habe ich ja nur drei: 2 bei Strato und eine bei Netcup. Andere sammeln Briefmarken, ich sammle Domains. :ROFLMAO:
 
Zuletzt bearbeitet von einem Moderator:

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
@daschmidt94 du legst in swag/nginx/proxy-confs/ eine Datei an die z.B. vaultwarden.subdomain.conf heißt. Es gibt im dem Ordner auch schon Sample Files die du nur kopieren kannst und deine Sachen einträgst. Wenn nicht, dann guck mal hier: https://github.com/linuxserver/reverse-proxy-confs
Da sind für viele Anwendungen schon fertige Configs drin. In deinem Beispiel wäre das https://github.com/linuxserver/reverse-proxy-confs/blob/master/vaultwarden.subdomain.conf.sample
Du erstellst also eine Datei die vaultwarden.subdomain.conf heißt. Was vor subdomain.conf steht ist sogar egal. Wichtig ist nur, dass es subdomain.conf oder subfolder.conf heißt.
Folgender Inhalt müsste dann rein (musst es aber noch bearbeiten)

Code:
## Version 2023/05/31
# make sure that your vaultwarden container is named vaultwarden
# make sure that your dns has a cname set for vaultwarden
# set the environment variable WEBSOCKET_ENABLED=true on your vaultwarden container

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name vaultwarden.xxx.at;

    include /config/nginx/ssl.conf;

    client_max_body_size 128M;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

    # enable for Authentik (requires authentik-location.conf in the location block)
    #include /config/nginx/authentik-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app vaultwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ ^(/vaultwarden)?/admin {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app vaultwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ (/vaultwarden)?/api {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app vaultwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ (/vaultwarden)?/notifications/hub {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app vaultwarden;
        set $upstream_port 3012;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ (/vaultwarden)?/notifications/hub/negotiate {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app vaultwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}
server_name: Ist das worauf der Server hören soll. Also vaultwarden.xxx.at
set $upstream_app: Da kannst du deine IP eintragen, wo der Container läuft
set $upstream_port: Den Port eintragen auf dem die Anwendung lauscht
set $upstream_proto: https oder http. Je nachdem auf welchem Protokoll die Anwendung lokal läuft

Mehr musst du nicht machen...

@MattCB freut mich, dass es bei dir jetzt funktioniert.:) Ich habe das inzwischen seit paar Jahren so laufen und noch nie Probleme gehabt. Der Container zum updaten der IP macht auch einfach was er soll und verbraucht sogut wie nix.
über den Docker-Container oznu/cloudflare-ddns lasse
Entferne mal lieber den Link. Der zeigt auf dein Portainer bzw. ist deine DDNS da mit drin. :)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: MattCB

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Danke für den Hinweis. Hab mein Zitat korrigiert
 

daschmidt94

Benutzer
Mitglied seit
17. Mai 2020
Beiträge
266
Punkte für Reaktionen
19
Punkte
24
Folgender Inhalt müsste dann rein (musst es aber noch bearbeiten)
danke, die examples habe ich gesehen. War vl. ein schlechtes Beispiel.

wenn es z.b. drive von synology wäre.
Also drive.xxxx.at auf 192.168.178.19:10003
und https erzwingen. Hierzu meinte ich ein Beispiel. Oder gibt es irgendwo online
eine Weboberfläche wo dann der formatierte code rauskommt?
Blöd gesagt der nginxproxymanager macht ja auch nichts als über die Weboberfläche im hintergrund die Dateien zu schreiben.
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Nein bei SWAG muss man configs schreiben. Gibt keine Oberfläche. Dadurch ist man aber auch sehr flexibel

Server_name ist die Domain. Das
Code:
listen 443 ssl http2;
    listen [::]:443 ssl http2;
heißt er soll nur auf https lauschen. Und das upstream Zeug ist drin Ziel. In deinem Fall upstream_app 192.168...., upstream_port 10003 und proto http. Das er immer auf http leitet kann man in einer anderen config für alle einstellen. Dann muss man das nicht über all einzelnen machen und kann es nicht vergessen.
 
  • Like
Reaktionen: daschmidt94

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.159
Punkte für Reaktionen
912
Punkte
424
Synology Drive ist halt eine Sonderlocke.
Desktop Sync lauscht auf 6690, auf 10003 lauscht nur das Webinterface für Zugriff via Browser oder Mobil-Apps.
 

MattCB

Benutzer
Mitglied seit
31. Jan 2012
Beiträge
382
Punkte für Reaktionen
71
Punkte
28
Danke für den Hinweis mit dem Link auf meinen Portainer. Der Link ist aber nur für mein internes Netzwerk gültig, da ich die DDNS-Domain in der Synology auf die interne IP zeigen lasse und somit trotzdem gültige Zertifikate im internen Netz habe. Da sollte man von außen also nicht rankommen. ;)

Aber ich schreibe mal einen Mod an, ob er das korrigieren kann. Ich hatte den Image-Namen faulerweise nur aus Portainer kopiert. :rolleyes:
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
@Fusion stimmt guter Hinweis. Ich denk da selten dran, weil ich nutze kein Drive.
 

daschmidt94

Benutzer
Mitglied seit
17. Mai 2020
Beiträge
266
Punkte für Reaktionen
19
Punkte
24
irgendwie bin ich glaube ich zu blöd...

hab eine eigene config versucht also hab vaultwarden.subdomain.conf.saml in vaultwarden.subdomain.conf umbenannt und wie folgt befüllt

Code:
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name bit.xxx.at;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

    # enable for Authentik (requires authentik-location.conf in the location block)
    #include /config/nginx/authentik-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.178.199
        set $upstream_port 5151;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

bekomme jedoch einen Errorcode 521?

dieser Errorcode steht im error.log

Code:
 crowdsec.lua:459: Allow(): [Crowdsec] bouncer error: Http error 403 while talking to LAPI (http://crowdsec:8080/v1/decisions?ip=172.68.51.40), client: 172.68.51.40, server: _, request: "GET /notifications/hub?access_token=e
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Das ist aber nicht das sample für Vaultwarden was du da nutzt oder? Also du kannst es extrem gekürzt. Die Einträge sind aber alle Notwendig. Aber seis drum. Der Fehler liegt an deinem Stack. Crowdsec scheint ja noch nicht richtig zu laufen. API_KEY richtig gesetzt?
 

daschmidt94

Benutzer
Mitglied seit
17. Mai 2020
Beiträge
266
Punkte für Reaktionen
19
Punkte
24
ja hab das mal komplett gekürtzt nur um die weboberfläche zu kommen und einmal etwas gefühl dafür.

die config sieht dazu so aus:

Code:
ENABLED=true
API_URL=http://crowdsec:8080
API_KEY=xxxxxxxxx
CACHE_EXPIRATION=1
# bounce for all type of remediation that the bouncer can receive from the local API
BOUNCING_ON_TYPE=all
FALLBACK_REMEDIATION=ban
REQUEST_TIMEOUT=3000
UPDATE_FREQUENCY=10
# live or stream
MODE=live
# exclude the bouncing on those location
EXCLUDE_LOCATION=
#those apply for "ban" action
# /!\ REDIRECT_LOCATION and RET_CODE can't be used together. REDIRECT_LOCATION take priority over RET_CODE
BAN_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/ban.html
REDIRECT_LOCATION=
RET_CODE=
#those apply for "captcha" action
#valid providers are recaptcha, hcaptcha, turnstile
CAPTCHA_PROVIDER=
# Captcha Secret Key
SECRET_KEY=
# Captcha Site key
SITE_KEY=
CAPTCHA_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/captcha.html
CAPTCHA_EXPIRATION=3600



wird der recaptcher unbedingt benötigt?

bzw. stimmt die api url mit http://crowdsec:8080 kommt mir etwas komisch vor
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Das kommt auf deinen Stack an.... Poste mal deine Compose.yml bzw. den Portainer Stack. Da muss ja auch ein API KEY für Swag gesetzt werden.
 


 

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