☰

Lighttpd kehrt von Curl statt von Nginx zurück

tag-icon • tag-icon linux networking iptables nginx lighttpd
Lighttpd kehrt von Curl statt von Nginx zurück

Ich habe Probleme, meine auf meinem Raspberry Pi gehosteten Websites in meinem Heimnetzwerk zu erreichen. Bis vor kurzem hat alles funktioniert und ich kann nicht herausfinden, was ich getan habe, um es kaputt zu machen :( Wenn ich es curl -I sarahcorballis.comvom Pi aus ausführe (also von derselben Maschine, auf der der Server gehostet wird) oder von einem anderen Ort aus, erhalte ich:

HTTP/1.1 301 Moved Permanently
Location: https://sarahcorballis.com/
Date: Fri, 08 Jan 2021 07:45:43 GMT
Server: lighttpd

Wenn ich jedoch curl -I localhost(oder localhost:80) ausführe, erhalte ich vom Pi Folgendes:

HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Fri, 08 Jan 2021 07:57:05 GMT
Content-Type: text/html
Content-Length: 3801
Last-Modified: Mon, 22 Apr 2019 18:39:21 GMT
Connection: keep-alive
ETag: "5cbe0a59-ed9"
Accept-Ranges: bytes

Die Site wird tatsächlich auf nginx gehostet, daher würde ich erwarten, dass Server: nginx/1.14.2bei allen Anfragen etwas angezeigt wird. Ich frage mich, ob Server: lighttpddas nur eine falsche Fährte ist oder ob es tatsächlich etwas impliziert?

Das Netzwerk-Setup, das ich habe, ist Internet -> ISP bereitgestellter Router -> ASUS RX88U -> Raspberry Pi

Sowohl der ISP-Router als auch der ASUS-Router verfügen über die Portweiterleitung 80-80 und 443-443 und die Protokolle auf beiden zeigen keine Probleme.

Bis gestern hat sogar der curl -I-Localhost die Lighttpd-Antwort ausgegeben, daher denke ich, dass es irgendwo am Raspberry Pi liegt, aber ich bin ratlos.

Hier ist die Ausgabe von ufw status:

ERROR: Couldn't determine iptables version

Hier ist iptables-savedie Ausgabe:

iptables-save/1.8.2 Failed to initialize nft: Protocol not supported

Das ist also eine weitere Änderung seit gestern. Was hat sich also geändert? Nun, ich habe von Stretch auf Buster aufgerüstet.

Antwort1

Das ist jetzt also gelöst. Falls jemand eine ähnliche Konfiguration hat und in Zukunft auf dasselbe Problem stößt, lag das Problem darin, dass ich eine dritte Site gelöscht hatte (ich brauchte sie nicht mehr); diese Site hatte jedoch die SSL-Zertifikate, die alle drei Sites abdeckten und jetzt weg waren. Schlimmer noch, ich verwende nicht Letsencrypt, sondern Cloudflare-Ursprungszertifikate mit HSTS, um eine robustere Sicherheit zu gewährleisten. Cloudflare verursachte die Umleitung, die dann fehlschlug, weil kein Zertifikat vorhanden war. Ich habe jetzt ein System mit einem Zertifikat pro Site eingeführt (da habe ich etwas gelernt).

Lösung:

  1. Generieren Sie ein neues Zertifikat – eines für jede Site
  2. Speichern Sie die Zertifikate (sowohl PEM als auch Schlüssel) in Verzeichnissen auf dem Server
  3. Ändern Sie die Serverblöcke in nginx (/etc/nginx/sites-enabled), damit sie auf die richtigen Verzeichnisse verweisen und stellen Sie sicher, dass http2 aktiviert ist.
  4. Stellen Sie sicher, dass in Cloudflare die Option „SSL Strict“ ausgewählt ist.

Hier ist der Nginx-Konfigurationsblock für eine der Sites:

# configuration file /etc/nginx/sites-enabled/<website>.com:
server {
    listen 80;
    listen [::]:80;

    server_name sarahcorballis.com www.<website>.com;
    return 302 http://$server_name$request_uri;
}
server {

    # SSL Configuration for Cloudflare 

    listen 443 ssl http2; 
    listen [::]:443 ssl http2;
    ssl on;
    ssl_certificate /etc/ssl/certs/<website>.com.pem;
    ssl_certificate_key /etc/ssl/private/<website>.com.key;

    server_name <website>.com www.<website>.com; 

    root /var/www/sarahcorballis.com/;

    index index.html;

    try_files $uri $uri/ /index.html ;


    client_max_body_size 50m;
}

Sie müssen zu Ihrer aktuellen Website wechseln und sicherstellen, dass das Suffix mit Ihrem übereinstimmt, falls Sie den obigen Block kopiert haben.

verwandte Informationen