13
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:
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 524734
Url: https://administrator.de/contentid/524734
Ausgedruckt am: 25.11.2024 um 05:11 Uhr
13 Kommentare
Neuester Kommentar
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.gw.mydomain.com -> http://10.20.30.40
cloud.mydomain.com -> http://10.20.30.40
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?
Vielleicht erst mal grundlegend selbst Informieren, Lets encrypt ist sehr gut dokumentiert
https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-wit ...
https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-wit ...
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?
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?
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.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 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?
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.
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
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
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:
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?
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?
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.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?
Zitat von @pixel24:
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. 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?
Ok, denke verstanden. Was mich im o.g. Beispiel verwirrt ist:
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
Examples:
Domainname: www.example.comZitat von @pixel24:
Ok, denke verstanden. Was mich im o.g. Beispiel verwirrt ist:
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-SystemOk, denke verstanden. Was mich im o.g. Beispiel verwirrt ist:
Examples:
> Domainname: www.example.com
>
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:
hinzu der auf die öffentliche IP-Adresse des Webserver beim ISB zeigt und nicht auf die WAN-IP des Gateways, oder?
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.comZitat 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...!!!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:
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. _acme-challenge.mydomain.comDer 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- ...
