Hi, ich möchte Nginx dazu bringen je nach subdomain die https Anfrage an eine andere Seite/Webapp https://ap1.beispiel.de -> https://192.168.0.10 https://ap2.beispiel.de -> https://192.168.0.11 ... die Seiten https://192.168.0.10, https://192.168.0.11 haben bereits ihre eigene https certifikate und funktionieren, wenn man die direkt zugreift. Ich habe versucht nginx dazu zu bringen, diese Aufgabe zu erfüllen, jedoch ohne Erfolg. Das Problem ist, dass nginx einen ssl certifikat erwartet und das möchte ich nicht tun. Ich möchte nur, dass nginx je nach dns die Anfrage transparent an die bestimmte IP Addresse weiterleitet und die Antwort zurücksendet. Ist es dafür überhaupt geeignet? Oder soll ich lieber mit einem reinen TCP proxy versuchen? Oder NAT?
Früher hatte ich mir dafür mal dashier geschrieben: https://github.com/Daniel-Abrecht/DPA-SSL-SNI-Forwarder Aber ich glaube seit der letzten TLS Version ist sowas garnichtmehr möglich.
Proxy schrieb: > ich möchte Nginx dazu bringen je nach subdomain die https Anfrage an > eine andere Seite/Webapp > > https://ap1.beispiel.de -> https://192.168.0.10 bitte was möchtest du? irgendwas fehlt da. Proxy schrieb: > die Seiten https://192.168.0.10, https://192.168.0.11 > haben bereits ihre eigene https certifikate und funktionieren das kann nur schlangenöl sein, weil (meines wissens) für lokale ip adressen kein (gscheides) zertifikat erstellt werden kann Proxy schrieb: > Das Problem ist, dass nginx einen ssl certifikat erwartet und das möchte ich nicht tun. und warum nicht? wenn du eine (öffentlich erreichbare) Seite mit einem SSL-Zertifikat versehen möchtest, dann sollte das schon eines sein das von einer CA unterschrieben ist. Selbst signierte und Snakeoil Zertifikate machen einfach zu viele Probleme. Wenn es nur zur internen verwendung ist, dann mach dir doch einfach noch mehr Schlangenöl. --- Ich habe zwar immer noch nicht verstanden was du eigentlich machen willst, aber ich schätze einfach mal: du hast zwei Server auf zwei Rechnern/Instanzen/Containern/... laufen und möchtest einfach anhand der Subdomain das Ziel unterscheiden. das kann nginx "out of the box" (nur so schnell hergerotzt, keine Garantie für Tippfehler o.ä.):
1 | server { |
2 | server_name irgendwas; |
3 | location /some/path/ { |
4 | proxy_pass https://192.168.0.123; |
5 | } |
6 | } |
7 | server { |
8 | server_name wasanderes; |
9 | location /some/path/ { |
10 | proxy_pass https://192.168.0.124; |
11 | } |
12 | } |
was dabei aber immer noch passieren kann ist, dass nginx die Verwendung von https im proxy_pass verweigert, wenn das Zertifikat nicht verifiziert werden kann (also sind wir wieder beim Schlangenöl Problem).
:
Bearbeitet durch User
Daniel F. schrieb: > was dabei aber immer noch passieren kann ist, dass nginx die Verwendung > von https im proxy_pass verweigert, wenn das Zertifikat nicht > verifiziert werden kann (also sind wir wieder beim Schlangenöl Problem).
1 | proxy_ssl_verify off; |
2 | # Damit ist's dann nicht besser als reines http hinter dem Proxy, OK wenn man seinem internen 192.168er Netz vertraut. |
3 | |
4 | #Ansonsten kann man sein Schlangenöl auch anpinnen: |
5 | |
6 | proxy_ssl_trusted_certificate schlangenöl_ca.pem ; |
alles hier nachzulesen http://nginx.org/en/docs/http/ngx_http_proxy_module.html
Proxy schrieb: > Ich möchte nur, dass nginx je nach dns die Anfrage transparent an die > bestimmte IP Addresse weiterleitet und die Antwort zurücksendet. Ist es > dafür überhaupt geeignet? Oder soll ich lieber mit einem reinen TCP > proxy versuchen? nginx kann TCP proxy: https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/ Wenn ap1.beispiel.de und ap2.beispiel.de die selbe IP-Adresse haben, dann muss man den Hostnamen aus dem Verbindungsaufbau abfangen: http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html Die erste Beispielconfig sollte deinen use case genau abdecken.
Daniel F. schrieb: > das kann nur schlangenöl sein, weil (meines wissens) für lokale ip > adressen kein (gscheides) zertifikat erstellt werden kann Ist im Firmenumfeld nicht nur üblich, sondern auch sinnvoll. Es muß nicht jeder im Netzwerk mitlesen können, was die HR über die interne Webanwendung in die Datenbank eingibt.
Nop schrieb: > Ist im Firmenumfeld nicht nur üblich, sondern auch sinnvoll. Es muß > nicht jeder im Netzwerk mitlesen können, was die HR über die interne > Webanwendung in die Datenbank eingibt. Wobei es ein angenehmer und einfacher ist, Server per interner Domain (mail.intern.firma.de) anzusprechen und dafür intern ausgestellte Wildcard-Domain Zertifikate (*.intern.firma.de) zu verwenden. Jeden Server per IP-Adresse anzusprechen und jeweils einzeln Zertifikate zu vergeben, ist deutlich umständlicher und obendrein einschränkend.
:
Bearbeitet durch User
Daniel F. schrieb: >> Das Problem ist, dass nginx einen ssl certifikat erwartet und das möchte ich > nicht tun. > > und warum nicht? wenn du eine (öffentlich erreichbare) Seite mit einem > SSL-Zertifikat versehen möchtest, dann sollte das schon eines sein das > von einer CA unterschrieben ist. Weil ich ohne neue Zertifikate zu erstellen, der Stream auf TCP ebene je nach dns name auf verschiedene Nodes weiterleiten wollte. Ich habe aber noch einmal den OSI model angeschaut und jetzt weiß ich, dass es auf dem OSI 4 (Transport) gar nicht möglich ist nach DNS die TCP Pakete weiterzuleiten, da dns die DNS Info nicht enthaltet. Bei nginx geht die Weiterleitung, weil es auf OSI (Anwendung) läuft, HTTP/S request enthaltet DNS Name. Mit nginx Lösung ist man aber quasi "man in the middle", man erstellt einen eigenen Server mit SSL Zertifikat und leitet entschlüsselte http Pakete an interne Server weiter. Das wollte ich aber ursprünglich nicht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.