pixel24
Goto Top

NGINX soll Domainname nicht IP zurückgeben

Hallo zusammen,

ich versuche mich gerade an NGINX als Reverse-Proxy um verschiedene Server per HTTP (später HTTPS) im LAN von extern über eine Subdomain der externen Domain welche gehostet ist zu erreichen.

Die Ausgangssituation:

Gateway/Firewall im LAN ist ein aktueller IPFire, dort habe ich eine feste WAN-IP z.B. 10.20.30.40.
[IPFire]
WAN: 10.20.30.40
LAN: 192.168.xx.254

Auf dem externen Webserver (bei All-Inkl) habe ich enstprechende Subdomains eingerichtet und weitergeleitet:

gw.mydomain.com -> http://10.20.30.40
cloud.mydomain.com -> http://10.20.30.40

der Einfachheit halber teste ich es gerade nur mit einer. (gw.mydomain.com). Diese soll an:

[Server1]
LAN: 192.168.xx.5

im LAN weiter gegeben werden. Hierzu habe ich auf dem IPFire das AddOn "NGINX" installiert. Die Konfiguration ist derzeit:
worker_processes  1;

events {
    worker_connections  1024;
}


http {
    server_names_hash_bucket_size 64;
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        server_name gw.mydomain.com;
        location / {
                proxy_pass http://192.168.xx.5;
        }
    }
}

Wenn ich nun von extern im Browser "http://gw.mydomain.com" aufrufe lande ich auch auf dem Webserver der auf 192.168.xx.5 läuft. Jedoch steht in der Adresszeile im Browser nicht "gw.mydomain.com" sondern die WAN-IP vom IFirre (10.20.30.40).

Ist das normal bzw. lässt sich das ändern?

Viele Grüße
pixel24

Content-Key: 524734

Url: https://administrator.de/contentid/524734

Ausgedruckt am: 29.03.2024 um 02:03 Uhr

Mitglied: 142232
Lösung 142232 13.12.2019 aktualisiert um 07:51:16 Uhr
Goto Top
Auf dem externen Webserver (bei All-Inkl) habe ich enstprechende Subdomains eingerichtet und weitergeleitet:

gw.mydomain.com -> http://10.20.30.40
cloud.mydomain.com -> http://10.20.30.40
Nicht "weiterleiten", sondern entsprechenden A-Record im DNS anlegen.
Mitglied: pixel24
pixel24 13.12.2019 um 08:36:01 Uhr
Goto Top
Prima. Funktioniert. Herzlichen Dank! Jetzt möchte ich das ganze mit SSL (LetsEncrypt) machen und habe noch ein paar Grundlegende Fragen zu LetsEncrypt. Kann ich die einfach hier stellen oder besser einen neuen Beitrag?
Mitglied: 142232
142232 13.12.2019 aktualisiert um 08:55:49 Uhr
Goto Top
Vielleicht erst mal grundlegend selbst Informieren, Lets encrypt ist sehr gut dokumentiert
https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-wit ...
Mitglied: pixel24
pixel24 13.12.2019 um 09:13:34 Uhr
Goto Top
Ja, die Doku kenne ich bereits. Wo ich noch ein Verständnis-Problem habe ob ich es auf allen beteiligten System installieren muss. Beispiel:

Auf der Firewall/Router der über eine fixe WAN-IP verfügt läuft wie o.g. NGINX als Reverse-Proxy. Der soll selbst keine Webseiten anbieten sondrn nur durchleiten und anhand der aufgerufenen Subdomain entscheiden auf welchen internen Server es geht. Auf diesen muss natürlich LetsEncrypt installiert und eingerichtet sein.

Auf dem IPFire auch? Der lauscht ja gerade (ich habe es wieder deaktiviert) auf Port 80 was natürlich Unsinn ist. Sobald ich in der NGINX-Config jedoch HTTPS (443) einrichte (so verstehe ich zumindest die Doku) braucht der auf diesem Host auch Zertifikate. das würde darauf hindeuten dass ich hier auch LetsEncrypt einrichten muss, oder?
Mitglied: 142232
142232 13.12.2019 aktualisiert um 10:30:34 Uhr
Goto Top
Zitat von @pixel24:

Ja, die Doku kenne ich bereits. Wo ich noch ein Verständnis-Problem habe ob ich es auf allen beteiligten System installieren muss. Beispiel:
Nein, ist nicht zwingend nötig.
Auf der Firewall/Router der über eine fixe WAN-IP verfügt läuft wie o.g. NGINX als Reverse-Proxy.
Der bekommt das Zertifikat.
Der soll selbst keine Webseiten anbieten sondrn nur durchleiten
Richtig aber er ist die erste Instanz mit der der Client Kontakt aufnimmt und die Kommunikation muss schon verschlüsselt sein, deswegen kommt auf ihn das Zertifikat.
und anhand der aufgerufenen Subdomain entscheiden auf welchen internen Server es geht. Auf diesen muss natürlich LetsEncrypt installiert und eingerichtet sein.
Falsch, intern kann der Nginx problemlos auch über http mit dem internen Server kommunizieren, SSL ist hier keine Pflicht (würde es aber trotzdem per Skript rüberkopieren und einrichten), trotzdem kommuniziert der Client über SSL da ja der NGINX der Übergabepunkt ist.


Auf dem IPFire auch?
Nein.
Der lauscht ja gerade (ich habe es wieder deaktiviert) auf Port 80 was natürlich Unsinn ist.
Die Firewall macht nur das Portforwarding und ist nicht an höheren TCP Layern beteiligt.
Port 80 benötigst du damit Letsencrypt die Verifizierung von deinem Server abrufen kann (kannst du gleich mit auf dem Nginx abfackeln.
Mitglied: pixel24
pixel24 16.12.2019 um 13:02:44 Uhr
Goto Top
Eine prinzipielle Frage zur Zertifikat-Aufstellung habe ich noch. Ich richte LetsEncrypt auf der Firewall ein bzw. erstelle dort ja die Zertifikate da hier ja auch NGINX läuft. Dieser Host ist intern unter gateway01.localdomain.lan / IP: 192.168.xx.254 lokal erreichbar.

Muss ich für diesen auch einen A-Record beim Provider anlegen der auf die feste WAN-IP zeigt damit er von extern unter gateway01.mydomain.com zeigt?

gateway01.mydomain.com -> 10.20.30.40

Ich habe Gestern - als ich nach einem Problem mit dem ACME-Package unter PFSense recherchiert habe - irgendwo einen solchen Hinweis gelesen
Mitglied: pixel24
pixel24 16.12.2019 um 13:17:13 Uhr
Goto Top
und was sich mir aus der Doku auch nicht erschließt da ich ja nicht auf dem externen Webserver installiere sondern auf dem lokalen Gateway:

Für die Zertifikate arbeite ich ja mit meiner externen Domain "mydomain.com". Und es werden ja für diverse Hosts:

- gw.mydomain.com
- cloud.mydomain.com

Zertifikate ausgestellt. Später kommt ja ggf. auf dem externen Webserver eine Webseite dazu was ja dann:

www.mydomain.com

ist und auch ein Zertifikat braucht. Ich installiere ja jetzt auf meinem lokalen Gateway und gebe hier an:

 Domain SAN list
List all domain names that should be included in the certificate here, and how to validate ownership by use of a webroot or dns challenge
Examples:
Domainname: www.example.com
Method: Webroot, Rootfolder: /usr/local/www/.well-known/acme-challenge/
Method: Webroot, Rootfolder: /tmp/haproxy_chroot/haproxywebroot/.well-known/acme-challenge/ 

also die externe Domain "mydomain.com"

Kann ich dann später trotzdem noch auf dem Webserver LetsEncrypt einrichten und auch hier angeben dass es die "mydomain.com" ist.

Oder habe ich da einen Denkfehler?
Mitglied: 142232
142232 16.12.2019 um 13:46:14 Uhr
Goto Top
Zitat von @pixel24:

Eine prinzipielle Frage zur Zertifikat-Aufstellung habe ich noch. Ich richte LetsEncrypt auf der Firewall ein bzw. erstelle dort ja die Zertifikate da hier ja auch NGINX läuft. Dieser Host ist intern unter gateway01.localdomain.lan / IP: 192.168.xx.254 lokal erreichbar.

Muss ich für diesen auch einen A-Record beim Provider anlegen der auf die feste WAN-IP zeigt damit er von extern unter gateway01.mydomain.com zeigt?
Die Domain für die du Zertifikate ausstellen willst muss auf deine WAN IP zeigen. Denn die Domain prüft Let's Encrypt ja bei der Verifizierung indem es auf Port 80 im Root des Webservers der dort lauscht eine Datei im Verzeichnis .well-known/acme-challenge abruft.
Mitglied: 142232
Lösung 142232 16.12.2019 aktualisiert um 13:50:44 Uhr
Goto Top
Zitat von @pixel24:

 Domain SAN list
> List all domain names that should be included in the certificate here, and how to validate ownership by use of a webroot or dns challenge
> Examples:
> Domainname: www.example.com
> Method: Webroot, Rootfolder: /usr/local/www/.well-known/acme-challenge/
> Method: Webroot, Rootfolder: /tmp/haproxy_chroot/haproxywebroot/.well-known/acme-challenge/ 

also die externe Domain "mydomain.com"

Kann ich dann später trotzdem noch auf dem Webserver LetsEncrypt einrichten und auch hier angeben dass es die "mydomain.com" ist.

Oder habe ich da einen Denkfehler?
Alle Domains für die du ein Zertifikat ausstellen willst musst du entweder per A-Record oder CNAME auf deinen WAN leiten wo er dann auf deine Let's Encrypt -Instanz geleitet wird wenn du zur Verifizierung die Web-Methode nutzt und z.B. nicht mit DNS TXT Records arbeitest, denn Let's Encrypt verifiziert alle Domains auf Vorhandensein des Challenges im o.g. well-known Folder.
Mitglied: pixel24
pixel24 16.12.2019 um 14:48:46 Uhr
Goto Top
Ok, denke verstanden. Was mich im o.g. Beispiel verwirrt ist:
Examples:
Domainname: www.example.com
Für mich war www immer ein Host und example.com die Domain und hier wird als Beispiel für einen Domainnamen der FQHN verwendet
Mitglied: 142232
Lösung 142232 16.12.2019 aktualisiert um 14:52:55 Uhr
Goto Top
Zitat von @pixel24:

Ok, denke verstanden. Was mich im o.g. Beispiel verwirrt ist:
Examples:
> Domainname: www.example.com
> 
Für mich war www immer ein Host und example.com die Domain und hier wird als Beispiel für einen Domainnamen der FQHN verwendet
Im FQDN für URLs gibt es keinen Host-Teil, www ist hier nur eine Subdomain von example.com. Bei URLs gilt das DNS-System
Mitglied: pixel24
pixel24 16.12.2019 um 15:41:53 Uhr
Goto Top
und die hoffentlich abschließende Frage. Im Handbuch zu PFSense/ steht:

Validation Methods

Let’s Encrypt can validate by checking the contents of a TXT record in DNS, or by fetching a file in a known location from a web server running on the hostname it is validating.

nsupdate

The nsupdate method uses RFC2136 style DNS updates to populate a TXT record in DNS to validate ownership of the domain.

We recommend using this method as it does not require external inbound access, so it can be used for internal systems that do not allow or cannot receive Internet traffic.

Before starting, an appropriate DNS key and settings must be in place in the DNS infrastructure for the domain to allow the host to update a TXT DNS record for _acme-challenge.<domain name>.


Hier wird die Validierung per nsupdate empfohlen. Das bedeutet dann für meine Konstellation:

- Auf dem externen Webserver auf welchem die Domain ja gehostet ist und der somit auch die Kontrolle über die DNS-Domain hat füge ich einen TXT-Record mit:
 _acme-challenge.mydomain.com
hinzu der auf die öffentliche IP-Adresse des Webserver beim ISB zeigt und nicht auf die WAN-IP des Gateways, oder?
Mitglied: 142232
142232 16.12.2019 aktualisiert um 16:00:26 Uhr
Goto Top
Zitat von @pixel24:
Hier wird die Validierung per nsupdate empfohlen. Das bedeutet dann für meine Konstellation:

- Auf dem externen Webserver auf welchem die Domain ja gehostet ist
und der somit auch die Kontrolle über die DNS-Domain hat
Bist du sicher das der Webserver/GW auch der Nameserver deiner Domain ist???? Da du ja vorher einen A-Record bei deinem Provider gesetzt hast gehe ich nämlich nicht davon aus, denn in dem Fall steht der Nameserver ja natürlich bei deinem Domain-Hoster...!!!


füge ich einen TXT-Record mit:
 _acme-challenge.mydomain.com
hinzu der auf die öffentliche IP-Adresse des Webserver beim ISB zeigt und nicht auf die WAN-IP des Gateways, oder?
Völlig falsch, du solltest dir dringend nochmal die DNS Grundlagen verinnerlichen.

Der TXT-Record der im DNS des für die Domain zuständigen Nameservers hinterlegt wird enthält keine IP Adresse sondern den Challenge den Let's Encrypt beim validieren erzeugt und diesen dann vom Nameserver abruft um zu überprüfen das du tatsächlich der Inhaber der Domain bist. Dieser Record wird nicht einmalig angelegt sondern muss per Skript/API dynamisch am Nameserver angelegt werden, da der Challenge ja jedes mal anders ist!

Wenn du also deinen Nameserver nicht selbst betreibst wovon ich bei deinem Wissensstand nicht ausgehe brauchst du für die Validierung per DNS einen API-Zugang deines DNS-Providers, sofern dieser das überhaupt anbietet. Hast du das nicht, bleibt dir nur die Web-Methode über den Abruf des Challenges aus dem .well-known Verzeichnis wenn du es automatisiert haben willst.

Dringend erst mal lesen wie das System überhaupt funktioniert
https://www.digitalocean.com/community/tutorials/an-introduction-to-let- ...