7
Apache TomCat URL von Servername-8080-Projektname in Wunschdomain ändern
Hallo zusammen,
aktuell setzen wir eine Oracle Apex Anwendung mit 4 Umgebungen auf (DEV, QA, Test & PROD). Die Webserver laufen auf Windows iV.m. Apache TomCat. Im Netzwerk haben wir die Maschinen unter "servername/8080/Projektname" erreichbar gemacht. Die Anwendung funktioniert auch.
Wir möchten, für die Verwendungen interner Mitarbeiter in einer anderen Niederlassung, diese Webseiten über Citrix veröffentlichen. Also neue Ressource in Citrix angelegt, Chrome gesagt mit welcher URL er starten soll und gut ist. Klappt auch.
Die Krux an der Sache ist nun... anstelle der aktuell angezeigten URL "Servername/8080/Projektname" soll der Zugriff über ein "intranet.meinProjektname.de" stattfinden. Das ganze abgesichert über ein Zertifikat (Zertifikat ist nicht das Problem sobald wir wissen welche URL wir absichern müssen).
Im Netz habe ich schon rausgefunden, dass man an der hosts.-Datei etwas ändern kann. Diese Änderungen gelten dann aber nur lokal. Bei Apache fehlt uns hierzu leider das Fachwissen, da baue ich auf euer Schwarmwissen.
Wenn mehr Infos benötigt werden, kann ich diese gerne providen!
Viele Grüße
aktuell setzen wir eine Oracle Apex Anwendung mit 4 Umgebungen auf (DEV, QA, Test & PROD). Die Webserver laufen auf Windows iV.m. Apache TomCat. Im Netzwerk haben wir die Maschinen unter "servername/8080/Projektname" erreichbar gemacht. Die Anwendung funktioniert auch.
Wir möchten, für die Verwendungen interner Mitarbeiter in einer anderen Niederlassung, diese Webseiten über Citrix veröffentlichen. Also neue Ressource in Citrix angelegt, Chrome gesagt mit welcher URL er starten soll und gut ist. Klappt auch.
Die Krux an der Sache ist nun... anstelle der aktuell angezeigten URL "Servername/8080/Projektname" soll der Zugriff über ein "intranet.meinProjektname.de" stattfinden. Das ganze abgesichert über ein Zertifikat (Zertifikat ist nicht das Problem sobald wir wissen welche URL wir absichern müssen).
Im Netz habe ich schon rausgefunden, dass man an der hosts.-Datei etwas ändern kann. Diese Änderungen gelten dann aber nur lokal. Bei Apache fehlt uns hierzu leider das Fachwissen, da baue ich auf euer Schwarmwissen.
Wenn mehr Infos benötigt werden, kann ich diese gerne providen!
Viele Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4653296245
Url: https://administrator.de/contentid/4653296245
Printed on: April 28, 2024 at 02:04 o'clock
7 Comments
Latest comment
Moin,
"Servername/8080/Projektname" ist sicher nicht richtig. Du meinst bestimmt "Servername:8080/Projektname"
Um den Aufruf über "intranet.meinProjektname.de" zu realisieren brauchst du mMn:
a) einen internen DNS (habt ihr sicher), der intranet.meinProjektname.de zu der IP des (Reverse-Proxy)-Servers auflöst
b) eine Reverse Proxy Server der zum einen TLS macht und zum anderen "intranet.meinProjektname.de" nach "Servername:8080/Projektname" umschreibt
lg,
Slainte
"Servername/8080/Projektname" ist sicher nicht richtig. Du meinst bestimmt "Servername:8080/Projektname"
Um den Aufruf über "intranet.meinProjektname.de" zu realisieren brauchst du mMn:
a) einen internen DNS (habt ihr sicher), der intranet.meinProjektname.de zu der IP des (Reverse-Proxy)-Servers auflöst
b) eine Reverse Proxy Server der zum einen TLS macht und zum anderen "intranet.meinProjektname.de" nach "Servername:8080/Projektname" umschreibt
lg,
Slainte
Hi,
danke, klar. :8080 meinte ich natürlich.
Der Weg über DNS wäre auch meine Wahl gewesen. Heißt das Zertifikat läge dann auf dem Proxy anstelle auf dem Apache?
danke, klar. :8080 meinte ich natürlich.
Der Weg über DNS wäre auch meine Wahl gewesen. Heißt das Zertifikat läge dann auf dem Proxy anstelle auf dem Apache?
Ich schwärme mal los... 
Vorab: von Citrix habe ich keine Ahnung.
Klar, dass "intranet.meinprojektname.de" am besten einen eigenen DNS benötigt. An "hosts" würde ich nicht basteln, weil man alle "hosts" auf allen Rechnern dann bei jeder Änderung aktualisieren müsste. Das "Mini-DNS für kleine Leute" lautet "PiHole".
Am sinnvollsten ist tatsächlich, wenn man je Serverapp eine Subdomain einrichtet, also z.B.
app1.server.blah
app2.server.blah
app3.server.blah
oder halt
app1.dev.server.blah
app2.dev.server.blah
usw.
Ich rate von der Nutzung von URL-Pfaden ab, also bitte NICHT
server.blah/dev/app1
server.blah/dev/app2
usw.
(Der Grund dafür ist, dass manche Apps Kuddelmuddel bei der Nutzung von Session-Cookies anrichten. Wenn man Subdomains nutzt, gibt es das Problem nicht)
Du brauchst dafür KEINE 8 extra Server einzurichten, sondern lässt alle Subdomains auf EINE einzige IP-Adresse laufen. Diese IP-Adresse ist dann einem Host zugeteilt.
Darauf richtest Du einen Reverse Proxy ein, z.B. HAproxy. Der ist so konfiguriert, dass er auf Port 443 ("HTTPS") lauscht und die Anfragen an die App-Server weitergibt. HAproxy unterstützt Regeln, wo man z.B. bestimmen kann, dass Anfragen, die auf Port 443 eingehen und auf "app1.dev.server.blah" als Hostnamen lauten, an eine bestimmte IP-Adresse und einen bestimmten Port weitergeleitet werden, z.B. dann an "servername:8080/projektname".
Du musst bei den Tomcat-Server nur UNBEDINGT darauf achten, dass Du den HAproxy bzw. Reverse Proxy in der Konfiguration einträgst. Außerdem muss man in vielen Apps noch einmal extra so etwas wie eine Basis-URL konfigurieren, die dann halt nicht "servername:8080/projektname" lautet, sondern "app1.dev.server.blah".
Statt HAproxy könnte auch der Webserver von Apache genommen werden, allerdings ist HAproxy meist etwas freundlicher in Bezug auf die Konfiguration von komplexen Weiterleitungen. Der Apache Webserver hat allerdings den Vorteil, dass er Anfragen auch über das AJP-Protokoll an Tomcat weiterleiten kann. AJP ist so etwas ähnliches wie HTTP nur komprimierter (bei HTTP wird viel "Zeugs" wie z.B. Zeilenende, Klartext, etc. übertragen. Bei AJP wird dagegen nur Binärcode übertragen, was natürlich Bandbreite spart und die Umrechnung von Text auf "Zahlen" in den Servern).
Je nach Server-App ist auch überhaupt keine weitere Konfiguration von Tomcat notwendig.
Vorab: von Citrix habe ich keine Ahnung.
Klar, dass "intranet.meinprojektname.de" am besten einen eigenen DNS benötigt. An "hosts" würde ich nicht basteln, weil man alle "hosts" auf allen Rechnern dann bei jeder Änderung aktualisieren müsste. Das "Mini-DNS für kleine Leute" lautet "PiHole".
Am sinnvollsten ist tatsächlich, wenn man je Serverapp eine Subdomain einrichtet, also z.B.
app1.server.blah
app2.server.blah
app3.server.blah
oder halt
app1.dev.server.blah
app2.dev.server.blah
usw.
Ich rate von der Nutzung von URL-Pfaden ab, also bitte NICHT
server.blah/dev/app1
server.blah/dev/app2
usw.
(Der Grund dafür ist, dass manche Apps Kuddelmuddel bei der Nutzung von Session-Cookies anrichten. Wenn man Subdomains nutzt, gibt es das Problem nicht)
Du brauchst dafür KEINE 8 extra Server einzurichten, sondern lässt alle Subdomains auf EINE einzige IP-Adresse laufen. Diese IP-Adresse ist dann einem Host zugeteilt.
Darauf richtest Du einen Reverse Proxy ein, z.B. HAproxy. Der ist so konfiguriert, dass er auf Port 443 ("HTTPS") lauscht und die Anfragen an die App-Server weitergibt. HAproxy unterstützt Regeln, wo man z.B. bestimmen kann, dass Anfragen, die auf Port 443 eingehen und auf "app1.dev.server.blah" als Hostnamen lauten, an eine bestimmte IP-Adresse und einen bestimmten Port weitergeleitet werden, z.B. dann an "servername:8080/projektname".
Du musst bei den Tomcat-Server nur UNBEDINGT darauf achten, dass Du den HAproxy bzw. Reverse Proxy in der Konfiguration einträgst. Außerdem muss man in vielen Apps noch einmal extra so etwas wie eine Basis-URL konfigurieren, die dann halt nicht "servername:8080/projektname" lautet, sondern "app1.dev.server.blah".
Statt HAproxy könnte auch der Webserver von Apache genommen werden, allerdings ist HAproxy meist etwas freundlicher in Bezug auf die Konfiguration von komplexen Weiterleitungen. Der Apache Webserver hat allerdings den Vorteil, dass er Anfragen auch über das AJP-Protokoll an Tomcat weiterleiten kann. AJP ist so etwas ähnliches wie HTTP nur komprimierter (bei HTTP wird viel "Zeugs" wie z.B. Zeilenende, Klartext, etc. übertragen. Bei AJP wird dagegen nur Binärcode übertragen, was natürlich Bandbreite spart und die Umrechnung von Text auf "Zahlen" in den Servern).
Je nach Server-App ist auch überhaupt keine weitere Konfiguration von Tomcat notwendig.
Danke dir! Leuchtet ein. Und an welcher Stelle würde ich da nun das Zertifikat ablegen um das ganze zu verschlüsseln?
Danke dir! Leuchtet ein. Und an welcher Stelle würde ich da nun das Zertifikat ablegen um das ganze zu verschlüsseln?
-->
... HAproxy. Der ist so konfiguriert, dass er auf Port 443 ("HTTPS") lauscht ...
Das geht über eine Zeile in der Konfigurationsdatei von HAproxy für ein sog. "frontend", z.B.
[..]
bind :443 ssl crt /pfad/zur/zertifikats_datei.pem
[..]
Du kannst zu Testzwecken in HAproxy auch parallel eine unverschlüsselte Verbindung einrichten.
Eine HAproxy-Konfigurationsdatei benötigt in der Voreinstellung nicht viele Optionen bzw. Zeilen. Man definiert ein "frontend", wo z.B. der Port angegeben wird, auf dem HAproxy lauschen soll. Und dort gibt man an, zu welchem "backend" das gehen soll. In dem "backend" findet sich dann das Ziel der Weiterleitung.
Die "PEM"-Datei kann z.B. eine von Let's Encrypt sein. Da gibt's PEM-Dateien mit der kompletten Zertifikatskette. Wenn nicht, dann muss die PEM-Datei den Inhalt von "*.crt" und "*.key" enthalten (sind beides Textdateien).
Zu dem Thema haproxy und Let's Encrypt gibt's aber im Internet eine Reihe von Beiträgen. Man muss HAproxy nur so im frontend konfigurieren, dass bei einem Aufruf einer bestimmten URL, die vom Let's Encrypt-Server kommt, die Anfrage auf ein kleines Script weitergeleitet wird. Damit kann man dann die Zertifikate automatisiert jedes mal verlängern.
[..]
bind :443 ssl crt /pfad/zur/zertifikats_datei.pem
[..]
Du kannst zu Testzwecken in HAproxy auch parallel eine unverschlüsselte Verbindung einrichten.
Eine HAproxy-Konfigurationsdatei benötigt in der Voreinstellung nicht viele Optionen bzw. Zeilen. Man definiert ein "frontend", wo z.B. der Port angegeben wird, auf dem HAproxy lauschen soll. Und dort gibt man an, zu welchem "backend" das gehen soll. In dem "backend" findet sich dann das Ziel der Weiterleitung.
Die "PEM"-Datei kann z.B. eine von Let's Encrypt sein. Da gibt's PEM-Dateien mit der kompletten Zertifikatskette. Wenn nicht, dann muss die PEM-Datei den Inhalt von "*.crt" und "*.key" enthalten (sind beides Textdateien).
Zu dem Thema haproxy und Let's Encrypt gibt's aber im Internet eine Reihe von Beiträgen. Man muss HAproxy nur so im frontend konfigurieren, dass bei einem Aufruf einer bestimmten URL, die vom Let's Encrypt-Server kommt, die Anfrage auf ein kleines Script weitergeleitet wird. Damit kann man dann die Zertifikate automatisiert jedes mal verlängern.
Moin,
Einzig der Teil mit LE ist noch nicht direkt enhalten. Das wird unter Secure HAProxy with SSL beschrieben.
Gruß,
Dani
Danke dir! Leuchtet ein. Und an welcher Stelle würde ich da nun das Zertifikat ablegen um das ganze zu verschlüsseln?
hier einfaches Beispiel für eine HAproxy Konfiguration.global
...
#
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
ssl-dh-param-file /etc/haproxy/dhparams4096.pem
...
defaults
log global
mode http
option httplog
option dontlognull
...
frontend haproxy-main
bind *:80
bind *:443 ssl crt /etc/letsencrypt/live/.../haproxy.pem alpn h2,http/1.1 curves secp521r1:secp384r1
option forwardfor
default_backend apache_webservers
http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;"
...
backend apache_tomcat
balance roundrobin
server websvr1 w.x.y.z:8080 check
...
...Gruß,
Dani
