Redirect mit iptables

[stonebreaker62]

Hallo

ich betreibe einen Rootserver auf UBUNTU Basis auf dem zwei Java Applikationen auf einem Glassfish AppServer laufen. Zur Zeit nutze ich einen IPTABLES Redirect um die Requests auf den Port 8181 umzuleiten:

iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A OUTPUT -o lo -p tcp --dport 443 -j REDIRECT --to-port 8181
 
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
 
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8181

Das funktioniert, weil grundsätzliche alle SSL Requests auf 8181 landen, wo beide Applikationen wie folgt erreichbar sind:
www.erstedomain.com/application1
www.zweitedomain.com/application2

Leider geht es auch umgekehrt, was nicht so elegant ist:
www.erstedomain.com/application2
www.zweitedomain.com/application1

Deshalb würde ich gerne folgendes Szenario implementieren und könnte damit auch eine bessere Performance bekommen, wenn ich jede Applikation in eine eigene Glassfish Domain bringe:

https://www.erstedomain.com > Redirect auf Port 8181
https://www.zweitedomain.com > Redirect auf Port 8282

Die Performance wäre deshalb besser, weil dann jede Applikationen ihre eigene JVM hat.

Kann man das mit IPTABLES implementieren?

[ddm3ve]

Dazu müsstest Du die Regeln auf IPs basierend ausweiten.
Alternativ, das hatte ich Dir glaube ich schon in einem anderen Post vorgeschlagen, wäre ein "vorgelagerter" Apache mit mod_proxy.
Dann kannst Du mit nur einer
IP auf vhosts basierend, die Anfragen entsprechend weiter leiten. (nginx geht natürlich auch). Wenn es um Performance geht, kannst du mit geziehltem Cachen von statischem Content Deinen Applicationserver entlasten, das bringt durchaus etwas.

[stonebreaker62]

danke für Deinen Tip. Mit mod_proxy habe ich auf meinem alten Server (SUSE mit PLESK) schon Tage verbraten und hab es nicht hinbekommen. Aber das lag vermutlich auch an PLESK und der Art und Weise, wie die VHOSTs dort angelegt waren und dass man in bestimmten Dateien, die unter PLESK Verwaltung waren, keine Änderungen machen konnte. Das müsste ich jetzt mal mit meinem neuen UBUNTU Server mal probieren.

Noch ne Frage zu Deinem Hinweis. Ich habe nur eine IP Adresse, d. h.
www.erstedomain.com und www.zweitedomain.com teilen sich diese IP Adresse. Brauche ich grundsätzlich eine zweite IP-Adresse, wenn ich mein Wunsch-Szenario

www.erstedomain.com/application1
www.zweitedomain.com/application2

umsetzen will?

[ddm3ve]

Nein mit der Proxy Lösung brauchst Du es eben nicht.
Mit IPTables könnte man dies zwar auch hin biegen, dann müsstest Du aber eine der beiden Domains über einen anderen Port z.B. 8080 etc. an nehmen.
Das ist aber vermutlich auch nicht was Du willst.

Du musst die Weiterleitungsregeln innerhalb Deiner vhost Konfiguration z.B. des Apachen anpassen.

Ein Beispiel aus meiner Umgebung:

Code: Select all

<VirtualHost example1.de:80>

<Proxy *>
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/x-httpd-eruby
AddOutputFilterByType DEFLATE text/html
Order allow,deny
Deny from 127.0.0.1 localhost 
Allow from all
</Proxy>

ProxyPreserveHost On
ProxyRequests Off
ProxyVia Off
SetEnv force-proxy-request-1.0 1.0
ProxyPass /balancer-manager !
ProxyPass /server-status !
ProxyPassReverse / /
ProxyPass / balancer://mycluster/ lbmethod=byrequests stickysession=ROUTEID
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy balancer://mycluster>
  BalancerMember http://10.10.10.50  route=web1 loadfactor=100
  BalancerMember http://10.10.10.60  route=web2
  ProxySet lbmethod=byrequests
</Proxy>
</VirtualHost>

Du brauchst aber in Deinem Fall keinen "Balancer ausser Du willst wirklich ein Failover Lösung aufbauen.
Dazu kommt noch der Cache und der Zugriff auf den balancer-manager
Diesen habe ich global im default-server konfiguriert.

Code: Select all

<IfModule mod_disk_cache.c>
CacheDefaultExpire 360
CacheEnable disk /
CacheRoot "/cacheroot/"
CacheDirLevels 5
CacheDirLength 4
CacheMaxFileSize 100000000
CacheMinFileSize 1
CacheIgnoreCacheControl On
CacheIgnoreNoLastMod On
CacheIgnoreQueryString Off
CacheIgnoreHeaders None
CacheLastModifiedFactor 0.1
CacheMaxExpire 640
CacheStoreNoStore On
CacheStorePrivate On
CacheDisable http://*.example3.org/
</IfModule>

<Location /balancer-manager>
SetHandler balancer-manager

Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

Ich hoffe die reine Konfiguration ist verständlich genug.

[daemotron]

Den Praxis-Teil hat ddm3ve ja bereits erklärt; ich schiebe dann noch mal ein bisschen Theorie hinterher.

https://www.erstedomain.com > Redirect auf Port 8181
https://www.zweitedomain.com > Redirect auf Port 8282

[...]

Kann man das mit IPTABLES implementieren?

Das geht grundsätzlich nicht. Netfilter/iptables, pf & Co. arbeiten auf den Layern 2 - 4, kennen also nur Devices (MAC, eth0, ... => Layer 2), IP-Adressen (IPv4, IPv6 => Layer 3) sowie Transportprotokolle und Ports (TCP, UDP, ICMP, ... + Port => Layer 4).

Der Hostname wird aber erst als Bestandteil des HTTP-Requests übertragen; also in Layer 7. Auf diese Information hat iptables keinen Zugriff, kann anhand dieser Information also auch keine Filterung, Weiterleitung, etc. vornehmen. Ausnahme: wenn bei Dir Hostnamen und IP-Adressen in einer 1:1 Beziehung stehen, kannst Du natürlich anhand der IP-Adressen eine Weiterleitung bereits auf Layer 3+4 veranlassen (bei Netfilter/iptables würde ich dafür mal auf die NAT- bzw. MASQ-Module tippen).

Abseits dieses Ausnahmefalls kannst Du den Hostnamen nur auf Layer 7 verarbeiten, benötigst also einen Filtermechanismus, der auf Ebene des HTTP-Protokolls arbeitet. Das wäre dann eben ein Proxy. Neben Apache mod_proxy gäbe es auch noch die Möglichkeit, Nginx oder Varnish dafür einzusetzen. Das bietet sich immer dann an, wenn man entweder gar keinen Apache benötigt, oder selbiger durch Kontrollware à la Plesk nur schwer individuell zu konfigurieren ist (bzw. dieses dann mit entsprechenden Risiken verbunden wäre).

[stonebreaker62]

danke für Eure Tips - genial, ich entwickle langsam Verständnis für die Materie. Da ich den Apachen nicht brauche, hätte VARNISH meine Bedürfnisse am besten erfüllt (weil einfach). Aber leider geht SSL damit nicht. nginx scheint mir ähnlich einfach zu konfigurieren, also probier ich es damit.

Kann ich my-iptables.rules einfach editieren, die redirects alle löschen und rebooten oder gibt es einen anderen Weg den Urzustand dieser Datei wieder herzustellen?

[ddm3ve]

Kommt darauf an, was in der my-iptales.rules steht.

Generell ist ein neustart nicht zwingend notwendig Du kannst iptables auch reloaden oder "manuell" mit iptables -I etc. etc. manuell bestücken. Vorher natürlich mit iptables -F leeren.

[stonebreaker62]

danke nochmal. Eine Frage noch zu SSL mit nginx. Wie man das aufsetzt ist mir klar:
server {
listen 443;
ssl on;
ssl_certificate /usr/local/nginx/conf/cert.pem;
ssl_certificate_key /usr/local/nginx/conf/cert.key;
keepalive_timeout 70;
}
}
Wie stelle ich aber jetzt sicher, dass man meinen Backend Server mit http://meine-domain.com aufrufen kann, die weitere Kommunikation aber sofort auf https wechselt?

Es ist doch vermutlich so, dass ssl nur zwischen nginx und dem Enduser genutzt wird, die Kommunikation zwischen nginx und meinem Backend Server aber unverschlüsselt läuft?. Ich muss also sicherstellen, dass mein Backend Server ausschließlich über diese interne Schiene aufgerufen werden kann und nicht direkt durch Eingabe des Ports.

[ddm3ve]

Wie schon gesagt, Du musst Deinen Backendserver auf 127.0.0.1 lauschen lassen.

Der Proxy, ob nun nginx oder apache oder was auch immer, leitet die Anfrage nach localhost weiter.

Beim Apachen habe ich das ganze wie folgt über mod_rewrite gelöst.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Du kannst aber auch 2 unterschiedliche vhosts einrichten.
Einen für / inkl. ssl verschlüsselung, der andere ohne.
Jener, der auf 80 und ohne Verschlüsselung erreichbar ist, macht nichts anderes als eine default html Seite aus zu liefern un dem Benutzer dazu auffordern, https:// zu nutzen.

Alternativ, wie schon gsagt, ein redirect der sowohl Serverweitig als auch Clientseitig gelöst werden kann.

Da ich mich mit nginx nicht beschäftige kann Ich dir hierzeu keine weitere hilfe leisten.
Hier solltest Du aber mit rewrite weiter kommen.

http://nginx.org/en/docs/http/convertin ... rules.html