FritzBox mehrere Domains über eigenen NGINX Webserver

[Azshania]

Ja wird wohl ein paar zusätzliche Ressourcen verbrauchen, ob das relevant ist für einen Pi kann ich dir aber nicht sagen. Mit meinem NAS/Homeserver mit Ryzen 2600, 64GB ECC Ram und Debian 10 werde ich das wohl eher nicht merken.

Mit der Domain fallen mir nur noch folgende Optionen ein:

• Rootdomain umleiten auf www.meinedomain.de und da drauf dann dyndns (zwar wieder Subdomain, aber ist ja gängige Schreibweise)
• Internetvertrag auf Feste IP umstellen falls möglich, würde dann wohl auf einen Businessvertrag hinauslaufen
• Mal probieren ob man bei dyndns in der Fritzbox das Feld für die Subdomain einfach leer lässt, vielleicht updated er dann die Rootdomain
• Da es ja das certbot-ovh Plugin gibt und dieses scheinbar in der Lage ist den TXT-Record deiner Rootdomain zu modifizieren, gibt es eventuell ja eine API mit der das auch mit dem A-Record geht.

Und die beiden Zertifikate die du für jede einzeln Domain hast, kannst du durch ein einziges Wildcardzertifikat ersetzen. Das kann aber ausschliesslich über DNS verifiziert werden (TXT-Record auf der Rootdomain), dafür ist ja dann das ovh certbot Plugin um das nicht immer manuell machen zu müssen.

 

[sasbro97]

@Azshania keine Sorge ist auch kein Pi, sondern ein ODROID N2. Natürlich keine Leistungsbestie, aber deutlich stärker als ein Pi.
Was ich gerade absolut gar nicht verstehe: meine Cloud sendet mich immer auf die rootdomain. Die Wordpress Seite kann ich hingegen variabel anpassen.

So wie das jetzt hier steht, will ich das natürlich nicht haben, aber es dient als Test. Ist einer der Parameter der Cloud dafür verantwortlich, dass ich immer auf die Rootdomain geschoben werde? Und als ich einfach dann mal Wordpress auf meinedomain.de gesetzt habe, dann war zwar die Wordpress Seite da, aber ohne Theme und buggy.

worker_processes auto;

include /etc/nginx/modules-enabled/*.conf;

events {
  worker_connections 1024;
}

http {
  gzip            on;
  gzip_min_length 1000;
  gzip_proxied    expired no-cache no-store private auth;
  gzip_types      text/plain text/css text/xml
                  application/javascript application/json application/xml application/rss+xml image/svg+xml;

  server_names_hash_bucket_size 64;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  more_clear_headers 'server';

  ssl_certificate     /etc/letsencrypt/live/meinedomain.de/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/meinedomain.de/privkey.pem;
  ssl_dhparam         /etc/ssl/dhparam.pem;
  ssl_protocols       TLSv1.2 TLSv1.3;
  ssl_session_cache      shared:SSL:10m;
  ssl_session_timeout 10m;
  ssl_ciphers         "EECDH-AESGCM:EDH+ESGCM:AES256+EECDH:AES256+EDH";
  ssl_prefer_server_ciphers on;
  add_header          Strict-Transport-Security "max-age=31557600; includeSubdomains" always;

  server {
    listen 80 default_server;
    listen [::]:80 default_server;
    return 301 https://$host$request_uri;
  }

  # NextCloudPi
    
  server {
    server_name blog.meinedomain.de;
    
    listen 443 ssl http2;
    listen [::]:433 ssl http2;
 
    client_max_body_size 100G;
    
    location / {
      more_clear_headers 'upgrade';
      more_clear_headers 'Strict-Transport-Security';

      proxy_ssl_verify off;
      proxy_pass https://nextcloudpi;
      proxy_set_header 'X-Forwarded-Host' blog.meinedomain.de;
      proxy_set_header 'X-Forwarded-Proto' https;
      proxy_set_header 'X-Forwarded-For' $remote_addr;
      proxy_set_header 'X-Forwarded-IP' $remote_addr;

      proxy_pass_header x-requested-by;
      proxy_pass_header requesttoken;
    }
  }
    
  # NextCloudPi Konfiguration Web-Interface
    
  server {
    server_name blog.meinedomain.de;
    
    listen 4443 ssl http2;
    listen [::]:4433 ssl http2;

    location / {
      more_clear_headers 'upgrade';
      more_clear_headers 'Strict-Transport-Security';

      proxy_ssl_verify off;
      proxy_pass https://nextcloudpi:4443;

      proxy_pass_header Authorization;
      
      proxy_set_header 'X-Forwarded-Host' blog.meinedomain.de;
      proxy_set_header 'X-Forwarded-Proto' https;
      proxy_set_header 'X-Forwarded-For' $remote_addr;
      proxy_set_header 'X-Forwarded-IP' $remote_addr;
    }
  }
 
  # WordPress
 
   server {
    listen 443 ssl http2;
    listen [::]:432 ssl http2;
    server_name cloud.meinedomain.de;
    
    client_max_body_size 200m;
    underscores_in_headers on;

    location / {
    
      more_clear_headers 'upgrade';
      more_clear_headers 'Strict-Transport-Security';

      proxy_ssl_verify off;
      proxy_pass http://wordpress;
      proxy_set_header X-Forwarded-Host $host;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
    }
    
   }
}

 

[Azshania]

server_name blog.meinedomain.de;
Sollte natürlich cloud.meinedomain.de; heissen
Ebenso das hier anpassen: proxy_set_header 'X-Forwarded-Host' blog.meinedomain.de;

 

[sasbro97]

@Azshania was meinst du? Bzw. sagen wir mal ich hab das jetzt geändert. Hätte dir vielleicht nicht die extra verbuggte Version senden sollen. Ändert aber leider nichts. Ich gebe bspw. cloud.meinedomain.de in den Browser ein, aber werde automatisch auf meinedomain.de weitergeleitet. Das will ich aber gar nicht. Wenn dann soll das eben für Wordpress mit blog.meinedomain.de passieren, aber doch nicht für die Cloud. Ich weiß halt nicht warum das passiert.

 

[Azshania]

Tja wüsste jetzt auch nicht direkt was das noch sein kann, vielleicht weil du keinen server_name hier gesetzt hast eventuell. Muss man halt mal ausprobieren:

  server {
    listen 80;
    listen [::]:80;
    server_name blog.meinedomain.de cloud.meinedomain.de;
    return 301 https://$host$request_uri;
  }

 

[sasbro97]

@Azshania leider 1 zu 1 dasselbe Verhalten. Hmmmmmmmmmmmmmm absolut fragwürdig. Kann das auch an einer DynDNS Config liegen oder so? Also keine Ahnung was das gerade ist.

Ehhh interessante Beobachtung. Habe WordPress Config über Nextcloud verschoben. Was passiert:
Jetzt führt die Rootdomain auf die Webseite. Drück ich auf meiner Webseite auf Login dann komm ich auf blog.meinedomain.de. Wenn ich cloud.meinedomain.de aufrufe werde ich automatisch auf meinedomain.de/login weitergeleitet. Das /login zeigt mir, dass er zur Cloud will, aber unter der Rootdomain ja jetzt natürlich die Webseite ist.

 

[Azshania]

An DNS kann es nicht liegen, mehr als weche domain in den brower eingegeben wurde sieht dein Webserver nicht mal.
Irgendwo in der config muss das Problem liegen, aber das Verhalten was du da beschreibst ist schon echt verdammt seltsam.

Update @sasbro97 Habe mal alle meine configs hochgeladen, vielleicht hilft es dir ja weiter.

 

[sasbro97]

@Azshania verhält sich gleich. Hab einfach mal die Serverconfigs von dir genommen.

Aber jetzt viel es mir ein. In der NextCloud Config gibt es etwas das nennt sich overwritehost und overwrite.cli.url. Die haben alles überschrieben die ganze Zeit... aber darauf muss man erstmal kommen.

Trotzdem passiert noch folgendes: die Subdomain blog.meinedomain.de existiert noch aber ist nicht mehr in der Config. Dann öffnet sich automatisch die Cloud also wird redirected zu cloud.meinedomain.de. Habe wie du www.meinedomain.de für WordPress formuliert. Rufe ich also nur meinedomain.de ein kommt wieder cloud.meinedomain.de, aber wenn ich www.meinedomain.de mache gibts wieder das Zertifikatsproblem.

Jetzt wird es nochmal dumm. In Firefox (nur in Firefox) werde ich bei Eingabe von meinedomain.de/login nicht weitergeleitet sondern bleibe da. Mach ich das bei Chrome lande ich bei cloud.meinedomain/login

Nochmal Update:

Hab jetzt ein Wildcard Zertfikat erstellt. Automatisiert ist es nicht, aber egal für den Moment. Beide Domains sind nun aufrufbar. Dafür geht meinedomain.de jetzt nicht. Ich dachte immer Wildcard Zertifikate mit *.meinedomain.de würden dann auch für die Rootdomain gelten. Ist wohl nicht der Fall oder.

 

[Azshania]

Aber jetzt viel es mir ein. In der NextCloud Config gibt es etwas das nennt sich overwritehost und overwrite.cli.url. Die haben alles überschrieben die ganze Zeit... aber darauf muss man erstmal kommen.

Ok das ist bei mir nicht der Fall, nutze aber nicht das offizielle Dockerimage von nextcloud sondern linuxserver/nextcloud

In Firefox (nur in Firefox) werde ich bei Eingabe von meinedomain.de/login nicht weitergeleitet

Schon mal den Cache gelöscht?

Ich dachte immer Wildcard Zertifikate mit *.meinedomain.de würden dann auch für die Rootdomain gelten.

Tun sie auch, hast du im Browser mal überprüft ob auch das richtige Zertifikat vom Webserver ausgeliefert wird?

Zu den Domains: Deine Rootdomain zeigt immer noch mit A-Record auf deine IP oder? Deine Umleitung kommt vielleicht ja daher, das es keine Config explizit für die Rootdomain gibt.
Stelle die Rootdomain im OVH Kontrollpanel mal um auf feste Umleitung zu www.meinedomain.de

 

[sasbro97]

Tun sie auch, hast du im Browser mal überprüft ob auch das richtige Zertifikat vom Webserver ausgeliefert wird?

Ausgestellt für *.meine-domain.de.

Ja die Rootdomain zeigt immernoch mit A-Record auf meine IP, richtig. Was meinst du mit der expliziten Config? In NGINX jetzt? Ich weiß nicht wieso die Cloud sich immer automatisch in den Vordergrund drängt und auch unter der rootdomain automatisch weiterleitet.

Was meinst du mit einer festen Umleitung? Hab halt so viele Einträge in der OVH Config. Die meisten waren automatisch da:

Vielleicht ist so einfacher lesbar:
IN NS ns111.ovh.net.
IN NS dns111.ovh.net.
IN MX 1 mx1.mail.ovh.net.
IN MX 100 mx3.mail.ovh.net.
IN MX 5 mx2.mail.ovh.net.
IN A $MEINEIP
600 IN TXT "v=spf1 include:mx.ovh.com ~all"
IN TXT "1|www.meinedomain.de"
_acme-challenge IN TXT "$KEY"
_autodiscover._tcp IN SRV 0 0 443 mailconfig.ovh.net.
_imaps._tcp IN SRV 0 0 993 ssl0.ovh.net.
_submission._tcp IN SRV 0 0 465 ssl0.ovh.net.
autoconfig IN CNAME mailconfig.ovh.net.
autodiscover IN CNAME mailconfig.ovh.net.
blog 60 IN A $MEINEIP
cloud 60 IN A $MEINEIP
ftp IN CNAME meinedomain.de.
imap IN CNAME ssl0.ovh.net.
mail IN CNAME ssl0.ovh.net.
pop3 IN CNAME ssl0.ovh.net.
smtp IN CNAME ssl0.ovh.net.
www IN MX 1 mx1.mail.ovh.net.
www IN MX 100 mx3.mail.ovh.net.
www IN MX 5 mx2.mail.ovh.net.
www IN A $MEINEIP
www IN TXT "3|welcome"
www IN TXT "l|de"

 

[Azshania]

Wildcardcert auf sowohl *.meinedomain.de als auch auf meinedomain.de ausstellen.
Wird in diesem Guide hier gezeigt: https://developerinsider.co/how-to-create-and-auto-renew-lets-encrypt-wildcard-certificate/ inkl. wie man mit certbot-auto das DNS-Plugin seines Domainproviders installiert und seine Zertifikate automatisiert erstellt und erneuert.
Bin jetzt auch bei OVH und hat bestens geklappt.

Dazu wie man bei OVH eine Umleitung einstellt habe ich in diesem Thread schonmal einen Link gepostet: https://docs.ovh.com/de/domains/domainweiterleitung/

Mit der expliziten config meine ich dass du nirgendwo festegelegt hast was nginx machen soll wenn ein Request über deine Rootdomain kommt, sprich du hast keine config für server_name meinedomain.de

 

[sasbro97]

@Azshania sorry hatte mal einen Tag kaum Zeit. Ich hab mir einen abgequält und auch certbot-auto mit dem Plugin zum Laufen gebracht. Aber bei mir war das auch etwas zu Overkill am Ende mit docker-compose Datei und dem Container von dem DNS-Plugin, was wiederum mit einem Cronjob läuft. Hatte so etwas in der Art auch noch nie zuvor gemacht.

Das mit der Weiterleitung ist muss ich mir nochmals angucken. Hab aber gerade meinen Spaß, dass ich keine Docker Images mehr pullen kann so out of nowhere:
Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Steht ja viel im Internet zu und vor allem in Verbindung mit Proxy, aber ich versteh nicht wie das jetzt auf einmal gekommen sein soll und dann müsste es ja gehen, wenn ich nginx herunterfahre, aber ist dasselbe in grün.

 

[Azshania]

certbot kannste ja auch einfach direkt im OS ausführen, so habe ich es auch gemacht 1:1 wie im Guide halt. Einmal etwas Aufwand gehabt, aber dafür ab jetzt keinen Gedanken mehr daran verschwenden müssen.

Was simple Weiterleitungen angeht gibt es eigentlich nichts groß zu verstehen: Einfach domain a auf domain b, bzw. vollständige URL und fertig. Wenn du deine rootdomain umleitest auf https://www.rootdomain.de und du rufst im Browser deine rootdomain + parameter auf, z.B. https://rootdomain.de/beispiel/index.php?xyz=123 alles 1:1 übernommen auf https://www.rootdomain.de/beispiel/index.php?xyz=123

Was dein "docker pull" Problem angeht, kann ich dir zumindest versichern dass dein nginc Container sicher nichts damin zu tun hat. Den docker dienst einfach mal neugestartet?

 

[sasbro97]

Das mit den Weiterleitungen versteh ich vom Sinn nicht. Ist ja alles glaub ich schon richtig, oder? FTP liegt halt auch auf der Rootdomain, aber das hab ich nicht erstellt.

Zu dem plötzlichem Docker pull Problem: Es raubt mir alle Nerven. Ich hab das schonmal so ähnlich gehabt, aber nicht jetzt so speziell auf Docker und konnte dann gar nicht mehr per Internet zugreifen, ergo gar nicht auf den Server und durfte das Image neu flashen und all sowas...

Das Komische ist ja, dass nur Docker meckert, die Internetverbindung ja wohl da ist, weil alles ja erreichbar ist und noch ein Eintrag:

Bei systemd-resolve --status kommt das raus (und ich glaub da sollte nicht die FritzBox stehen oder):

Link 2 (eth0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.178.1
                      $MAC-Adresse
          DNS Domain: ~.
                      fritz.box

Das sieht echt nicht gut aus mit dem Fehler und alles neumachen wäre echt nicht cool also Image von neu aufziehen... der Fehler steht überall im Internet aber es gibt keine richtige Lösung. Nur so Fehler, dass es daran liegt, dass Leute hinter Proxy sind usw. Aber hab ja nichts geändert. Arghhhh

Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Edit: hab das gefixt, aber vermutlich nicht auf Dauer... mit einem HTTP Proxy Server mit irgendeinem Proxy aus einer Liste: https://forums.docker.com/t/docker-...meout-exceeded-while-awaiting-headers/73064/7

 

[Azshania]

Die Weiterleitung wird nicht in der DNS-Zone eingerichtet sondern unter "Weiterleitung":

In dem von dir verlinkten Thread schreibt einer, ein anderer DNS war die Lösung für ihn.
Aktuell scheinst du ja deine Fritzbox als Upstream-DNS zu verwenden, also probier doch mal in der Fritzbox den DNS zu wechseln, am besten Testweise google oder cloudflare:

 

[sasbro97]

@Azshania keinen Bock mehr langsam. Es ging wieder durch den Fix von mir mit dem Proxy für Docker und schön. Und dann waren die Downloads mega langsam und haben mit EOF Fehler geendet. Hab gedacht ok ändere mal den Proxy bzw. halt die IP. Jetzt wieder 1 zu 1 derselbe Fehler und nichts geht. Ich versuche alle möglichen IP'S / Proxys und den DNS von Google hab ich auch schon drin. Das macht keinen Spaß mit solchen plotzlichen Fehlern aus dem Nichts.

Also keine Ahnung zufällig ging dann ein Proxy wieder und ich konnte die Images downloaden, die ich wollte, aber nach einem Tag gehts wieder nicht. Verzweiflung pur. Dafür alles neumachen will ich nicht... Aber so gibts halt keine Containerupdates nichts.

Dann mal zurück zum eigentlichen Problem: das Updaten der IP zu meinem Router für die Rootdomain. Nach wie vor keine Ahnung Hab nur gesehen, dass ich auch für die Rootdomain angeblich einen CNAME setzen kann. Nur wie bringt mich das jetzt weiter?