Aktualisieren
Ich habe die gleichen Schritte wie unten beschrieben befolgt, allerdings auf einem bereitgestellten generischen VPS (nicht Google), und es hat wie erwartet funktioniert, einschließlich nicht aufgeführter Schritte wie dem Aktivieren von HTTPS mit Certbot ... Ich gehe also davon aus, dass es eine spezielle Konfiguration im GCE-Ding gibt, die ich falsch verstehe/falsch verwende/nicht mache und die das unten beschriebene Problem verursacht. Irgendwelche Ideen, was das in GCE sein könnte?
Aufstellen
Ich habe eine Google Cloud Compute Engine-Instanz, auf der Debian installiert ist. Während der Einrichtung dieser GCE-Instanz habe ich standardmäßig HTTP- und HTTPS-Verkehr über die bereitgestellten GCE-Firewall-Optionen zugelassen. Ich bin über SSH auf die GCE-Instanz zugegriffen und habe Folgendes getan:
Screenshot der GCE http/https-BerechtigungserteilungNachweis der Verkehrszulassung durch GCE
1.) Nginx und ufw installiert
sudo apt install nginx ufw
2.) Aktivierte UFW-Regeln, die HTTP-, HTTPS- und SSH-Verbindungen zulassen
sudo ufw allow (http/https/ssh)
sudo systemctl enable ufw
sudo systemctl start ufw
3.) Nginx aktiviert und die Standardkonfiguration beibehalten
sudo systemctl enable nginx
sudo nginx -t ( returned "ok" results )
sudo systemctl start nginx
4.) Sichergestellt, dass meine Domain auf die richtige IP verweist
Tests
Curling-Tests
Wenn ich die Domäne besuche, erhalte ich immer noch die Fehlermeldung „domain.com hat die Verbindung verweigert“.
curl localhost
Ich erhalte den erwarteten Standardinhalt. Wenn ich
Netstat-Prüfung
netstat -a
Ich kann sehen, dass ich über die richtigen Ports mit der Außenwelt spreche
tcp 0 0 0.0.0.0:http 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN
UFW-Prüfung
Wenn ich meine Firewall-Regeln überprüfe, sehe ich Folgendes
sudo ufw status
SSH ALLOW Anywhere
224.0.0.251 mDNS ALLOW Anywhere
22 ALLOW Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
3000 ALLOW Anywhere
SSH (v6) ALLOW Anywhere (v6)
ff02::fb mDNS ALLOW Anywhere (v6)
22 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
3000 (v6) ALLOW Anywhere (v6)
Das zeigt meiner Meinung nach, dass meine Ports korrekt geöffnet sind.
Ping-Prüfung
Ich kann meinen Server über die Domäne anpingen und er gibt die erwartete IP korrekt zurück.
Pinging FizzBuzz.app [cor.rec.t.IP] with 32 bytes of data:
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=34ms TTL=57
Ping statistics for cor.rec.t.IP:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 33ms, Maximum = 34ms, Average = 33ms
Protokollierungsprüfung
Wenn ich /var/log/nginx/error.log aufrufe, ist es leer (nach dem Besuch der Domäne mit einem fehlgeschlagenen Ergebnis)
Wenn ich /var/log/nginx/access.log aufrufe, gibt es einen einzigen Eintrag für den Zeitpunkt, als ich überprüft habe, ob „curl localhost“ funktioniert hat (was der Fall war).
Soweit ich das beurteilen kann, zeigt Nginx keine Fehler an.
Abschluss
Bis jetzt habe ich alle Möglichkeiten ausgeschöpft, um dieses Problem zu lösen, außer direkt den Google-Support zu kontaktieren. Ich versuche, den einfachsten Anwendungsfall zu verwenden, um die Variablen zu minimieren, und erhalte immer noch die Fehlermeldung „Verbindung verweigert“, wenn ich meine Site über die IP oder die Domain besuche, wenn sie von Google gehostet wird. Wenn ich sie von zwei anderen Anbietern hosten lasse, funktioniert sie einwandfrei. Fazit? Ich bin verwirrt …
Antwort1
Ich sehe drei Hauptpunkte in Ihrer Frage: NodeJS-App als Backend, Nginx lauscht nicht auf Port 443 und Reverse-Proxy-Konfiguration. Lassen Sie uns das Ganze aufschlüsseln und jeden Punkt isoliert betrachten.
- node.js-App: Versuchen Sie, vom lokalen Host darauf zuzugreifen, und bestätigen Sie, dass sie ordnungsgemäß antwortet.
- nginx lauscht nicht auf Port 443: Sie müssen dafür einen Serverblock auf nginx konfigurieren. Außerdem ist es eine gute Idee, von HTTP auf HTTPS umzuleiten:
server { listen 80 default_server; server_name fizzbuzz.app www.fizzbuzz.app; return 301 https://fizzbuzz.app$request_uri; } server { listen 8443 ssl; server_name fizzbuzz.app www.fizzbuzz.app; index index.html index.htm; access_log /var/log/nginx/fizzbuzz-access.log; error_log /var/log/nginx/fizzbuzz-error.log error; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } ssl_certificate /etc/ssl/certs/fizzbuzz.app-fullchain.pem; ssl_certificate_key /etc/ssl/private/fizzbuzz.app.key; }
Zum Ausstellen Ihres Zertifikats empfehle ich Ihnen, Certbot oder ein ACME-Skript zu verwenden.
Mit acme.sh können Sie beispielsweise mit dem folgenden Befehl ein Zertifikat ausstellen:
/root/.acme.sh/acme.sh --issue --nginx -d fuzzbuzz.app -d www.fuzzbuzz.ap /root/.acme.sh/acme.sh --install-cert -d fuzzbuzz.app -d www.fuzzbuzz.app \ --cert-file /etc/ssl/certs/fuzzbuzz.app.crt \ --key-file /etc/ssl/certs/fuzzbuzz.app.key \ --fullchain-file ${CERTS_DIR}/fuzzbuzz.app-fullchain.pem \ --log /var/log/acme_log \ --reloadcmd "systemctl restart nginx"
Nachdem Sie Ihr Zertifikat ausgestellt und installiert haben, starten Sie nginx neu und testen Sie es
- Der dritte Punkt ist die Konfiguration von nginx als Reverse-Proxy, um Ihre Anwendung über HTTPS verfügbar zu machen. Ich denke, die obige Konfiguration sollte funktionieren. Falls nicht, empfehle ich Ihnen, dieses Dokument von GoCD zu lesen, das genau diese Art von Konfiguration erklärt:
Antwort2
ICH HABE ES HERAUSGEFUNDEN!!!
.APP! Es war die ganze Zeit die .app-TLD!!!
Ich wollte gerade einen zufälligen Domänennamen kaufen, um einem Kommentator einen Namen und eine IP-Adresse zu geben, wählte aus Spaß einen .app-Namen (hatte mir für diesen Test einen albernen Namen ausgedacht) und las Folgendes: „.APP ist ein sicherer Namespace. Sie können Foobarington.app jetzt kaufen, aber für die Website-Verbindung ist ein SSL-Zertifikat erforderlich. Erfahren Sie mehr über sichere Namespaces und wie Sie ein SSL-Zertifikat erhalten
SO! Als ich versuchte, meine .app-Domäne auf den Server zu richten, wurde sie nicht geladen, da mein Server zu diesem Zeitpunkt kein SSL-Zertifikat hatte. Ich wollte CertBot verwenden, um das Zertifikat zu erhalten, aber sie benötigen zunächst HTTP-Zugriff, um die automatische Zertifikatserteilung durchzuführen.
Ich muss herausfinden, wie ich Certbot (oder eine gleichwertige Lösung) mit diesem TLD-Typ und Host zum Laufen bekomme, aber es ist definitiv der TLD-Typ, den ich habe, der dieses Problem verursacht hat!