Auf demselben Server hinter einer PfSense-Firewall kann keine Domäne über HTTPS erreicht werden

Question

Ich hoste eine Plattform auf einem Server mit mehreren Domänennamen, beispielsweise example.com und anotherexample.com. Auf diesem Server führe ich ein Spring Boot-Backend aus, das die Domäne example.com verwendet und versucht, mit anotherexample.com zu kommunizieren. Mein Problem ist, dass ich scheinbar keine Verbindung über HTTPS mit der anderen Domäne herstellen kann, es wird einfach nicht einmal eine Verbindung hergestellt. Ich habe die folgenden Tests versucht, die unterschiedliche Ergebnisse liefern:

1. Die Verwendung curlauf einem Rechner, der sich nicht hinter der Firewall befindet, umhttps://anotherexample.com, funktioniert perfekt
2. Auf dem Server verwenden curl, sondern stattdessenhttp://anotherexample.com, funktioniert perfekt
3. Verwenden Sie curlauf dem Server, umhttps://anotherexample.com, keine Antwort, irgendwann Zeitüberschreitung
4. Verwenden Sie curldie Firewall, umhttps://anotherexample.com, keine Antwort, irgendwann Zeitüberschreitung
5. Wird auf dem Server verwendet openssl s_client -connect anotherexample.com:443 -servername anotherexample.com, keine Antwort, eventuell Zeitüberschreitung
6. /etc/hostsWenn ich auf dem Server zu ändere und 127.0.0.1 anotherexample.comausführe openssl s_client -connect anotherexample.com:443 -servername anotherexample.com, erhalte ich eine Antwort.

Was könnte das Problem sein, das dazu führt, dass ich keine Verbindung zu Domänen herstellen kann, die auf Computern hinter der Firewall gehostet werden? Liegt es an einer falschen Konfiguration auf dem Server (Ubuntu 22.04) oder an der PfSense-Firewall (2.7.2)?

Mein Aufbau ist folgender:

• PfSense-Firewall, die NAT verwendet, um sicherzustellen, dass die öffentliche IP zur internen IP des Servers gelangt
• Server mit NGINX und offenen Ports 80 und 443. Zertifikate werden über LetsEncrypt erstellt und funktionieren perfekt im Browser

Answer 1

Das ist normal; DNAT („Portweiterleitung“) funktioniert nicht, wenn sich sowohl die Quelle als auch das eigentliche Ziel im selben Subnetz befinden (oder tatsächlich dasselbe System sind). Viele frühere Threads wurden zum gleichen Problem mit Home-Gateways gepostet (suchen Sie nach „NAT-Haarnadel“), aber es gilt gleichermaßen für jede NAT-Implementierung, einschließlich pfSense. Suchen Sie daher in den früheren Posts nach einer vollständigen Erklärung. Das grundlegende Problem besteht darin, dass die Firewall nur die Möglichkeit hat, Pakete in eine Richtung umzuschreiben, nicht aber in die andere.

Eine gängige Problemumgehung besteht darin, dass pfSense auch die Quell-IP-Adresse neu schreibt, sodass es für den Webserver so aussieht, als ob die Verbindung tatsächlich von der Firewall und nicht von ihm selbst kommt. Aktivieren Sie dazuNAT-Reflexionin Ihrer Firewall. An anderen Stellen würde es „NAT-Loopback“, „NAT-Haarnadel“ oder einfach eine benutzerdefinierte SNAT-Regel ohne spezifischen Namen heißen.

Beachten Sie, dass dies leichte Auswirkungen auf die Leistung hat, da jedes Paket notwendigerweise über Ethernet an pfSense gesendet wird.Undzurück, anstatt vollständig auf der Maschine bleiben zu können. Ihre Webanwendungen müssen auch die Firewall-IP erwarten, wenn Sie IP-basierten Zugriff verwenden.

Ich persönlich würde alsoempfehlendie 127.0.0.1/etc/hosts-Einträge für alle Domänen, anstatt sich auf NAT-Reflexion zu verlassen.