IIS als Reverse Proxy für mehrere Tomcat Applikationen

[Deichgraf17 0]

hm...

 

Guten Tag.

 

Ich versuche seit 3 Tagen IIS als Reserve Proxy zu konfigurieren. Ich habe bereits mehrere Lösungen aus diversen Blogs und Foren probiert, kann mein Problem aber nicht lösen.

 

Das Setup:

Win Server 2012 (gleichzeitig Domänencontroller)

Mehrere Apache Server (meist 8, teilweise 6/7)

Mehrere Applikationen die über eigene Ports laufen:

Xwiki 8060

Nexus 8090

Teamcity 8111

YouTrack 8080

ARR für IIS (8) ist installiert

 

Probierte Lösungen u.a.:

Per Apache Tomcat Connector

ARR mit Rewrite Rules

Eine Lösung für Lync

 

Die Aufgabe:

Bisher ruft man die Applikationen zB mit http://localhost:8060/xwiki auf. 

Sollzustand ist das die Applikationen alle mit https://localhost:443/Applikation aufgerufen werden (Die :443 Portangabe kann ruhig wegfallen).

 

Ich hab auch hier im Forum schon gesucht, finde aber nur Verweise auf Blogposts die ich schon durchgesehen habe oder der Thread ist einfach so ohne Lösung gestorben.

 

Falls ich noch Angaben vergessen haben sollte werde ich diese selbstverständlich nachreichen.

 

Bin für jede Hilfe dankbar, auch wenn es nur ein Denkanstoß in die richtige Richtung wäre: Sehe den Wald vor lauter Bäumen nicht mehr.

 

Viele Grüße,

Jack

[Deichgraf17 0]

hm...

 

Ok, erste Fehlerquellen sind beseitigt.

Habe nun eine Umschreibe-Regel die auf Xwiki verweist und es funktioniert auch.

Serverfarm Xwiki erstellt, mit der IP des Servers, dem Port des Apache und https 443.

 

Nun kann ich aber keine meiner anderen Anwendungen ähnlich erreichbar machen.

Ich vermute das Problem ist das ich nur 1 IP für den Server an sich habe.

 

Habe bisher je 1 weitere Serverfarm für Youtrack und TeamCity erstellt. Dies ist notwendig, da wie gesagt nur 1 IP, aber verschiedene Ports.

Innerhalb einer Serverfarm kann eine IP nur 1 mal vorkommen. 

 

Rufe ich nun die entsprechende Regel ab, erhalte ich ein 404. 

Ich habe bei einer der Serverfarmen den https Port auf 443 gelassen, bei der anderen auf 442. 

Beides macht keinen Unterschied.

 

Ich brauche Denkanstöße!

 

Edit: Erprobt: Es liegt zu 99% daran, dass alle Serverfarmen die gleiche IP verwenden. Schalte ich die Xwiki Farm ab, erhalte ich einen bad gateway error

statt 404.

 

Viele Grüße,

Jack

bearbeitet 21. Januar 2014 von Deichgraf17

[zahni 525]

Vielleich hilft das:

 

http://blog.kloud.com.au/2013/04/18/an-overview-of-server-name-indication-sni-and-creating-an-iis-sni-web-ssl-binding-using-powershell-in-windows-server-2012/

 

Generell solltest Du aber die Regel befolgen: 1x SSL Site = 1x IP-Adresse.  Unser Provider wollte jedenfalls beim Apache das nur so einrichten. SNI klappt da wohl nicht richtig.

[Deichgraf17 0]

hm...

 

Danke, ich schätze das ist tatsächlich unser Hauptproblem. Dann müssen wohl die Parameter der Aufgabenstellung geändert werden...

[Deichgraf17 0]

hm...

 

Ok, nachdem ich nun 2 Wochen an dem Thema hänge habe ich den Fehler im System entdeckt.

 

Reguläre Ausdrücke.

 

Während wir vorher die gesamte URL geprüft haben für unsere Regel, haben wir heute getestet nur den Namen/Pfad der Applikation zu prüfen.

 

Das heißt statt ^http\:\/\/hostname\applikation$ nun (applikation)(.*)

 

Damit brauchen wir weder mehrere IPs, noch Sites oder Serverfarmen.

 

Jetzt müssen wir nur noch irgendwie dazu kommen das alle Anfragen über https laufen und dann ist dieses Kapitel geschafft.

[Dukel 439]

Redirekt von http nach https.

[Deichgraf17 0]

hm...

 

Bevor ich das in Angriff nehmen kann, muss ich erstmal rausfinden, was das Problem mit Anmeldedaten ist.

 

Die Regeln leiten ja jetzt zuverlässig auf hostname\app um. Logge ich mich dann zum Beispiel in Xwiki ein, zieht er auch zuverlässig die Daten aus dem AD.

 

Leider bleibe ich nicht eingeloggt und kann keine Änderungen am Wiki vornehmen. 

Gehe ich über localhost:port\app rein habe ich das Problem nicht.

 

Auf ein neues also...

 

 

Was den redirect angeht: Ich habe es bisher nur über eine url rewrite Regel versucht. Dann gibt er mir auf der Seite aus, dass die Seite über eine Weiterleitung verfügt.

Das ist ja schön und gut, aber er soll mich dann auch bitte weiterleiten.

In anderen Fällen warnt  er mich, dass die Seite eventuell eine phishing site ist, obwohl ich meine selbstzertifizierten Zertifikate habe und Client Zertifikate ignoriere.

[zahni 525]

Von "Anmeldedaten" hast DU aber nicht  geschrieben.

Hier müssen natürlich etwaige Cookies, z.b. die HTTP-Session, mit nach draußen gehen...

 

Zum Debuggen kannst Du Dir mal fiddler2  runterladen

[Deichgraf17 0]

hm...

 

Das Problem ist gelöst: Die URL Rewrite Regeln waren als Umschreibung angelegt. Ein einfaches ändern auf Umleitung war die Lösung.

 

Danke dir trotzdem.

 

Nun werde ich mich wieder dme Port Forwarding zuwenden. Wenn alles durch ist, werde ich meine Arbeitsschritte zusammenfassen, dann ist hier

eine einfache Referenz für User die mit ähnlichen Problemen kämpfen.

[zahni 525]

Eine Umleitung ? Leitet eine Umleitung nicht per HTTP 301  auf  eine  andere  URL  um ? Dann ist das kein Proxy mehr.

Sind die internen Sever etwas extern erreichbar ?

 

Sorry, aber  DU stocherst ziemlich im  Nebel...

[Deichgraf17 0]

hm...

 

Aus irgendeinem Grund bekomme ich keine Benachrichtigungen wenn hier jemand antwortet...

 

Mir ist bewusst, dass ich im Nebel stochere. Daran kann ich aber auch leider nur schrittweise etwas ändern.

 

Die internen Server sind ja lediglich Tomcats auf der Maschine, die der externe Server sein soll. 

 

Die Umleitung in diesem Fall sucht nach den regulären Ausdrücken z.B. (xwiki)(.*) per URL rewrite wird dann umgeleitet auf

host:port/xwiki.

Was intern im Modul der Unterschied ist kann ich nicht sagen. Lediglich das ich mich per Umschreibung (die vorige Einstellung) nicht

im Xwiki anmelden konnte.

 

Würde ich eine Reverse Proxy Regel verwenden, könnte ich nicht einmal das Format http://host/xwiki nutzen, da diese nur xwiki.host zulassen würden.

Wir haben für diese "Lösung" schon 2 Wochen investiert.

 

Der Ausgangspunkt ist ja:

Ein Hardware Server mit einer IP. Darauf laufen 5 Tomcats mit je 1 Anwendung die jede ihren eigenen Port nutzt. 

Der Nutzer soll einfach https://hostname/anwendung eintippen um auf die entsprechende Applikation zu kommen.

Bevorzugt sollen alle Anwendungen auf Port 443 horchen (wobei ich davon ausgehe, dass dieses unmöglich ist und jede 

Anwendung auch einen eigenen https Port braucht).

Bekannt ist dem Rechner des Nutzers der Host durch die hosts Datei.

 

Aber da hier keiner in der Materie steckt, ist es schon ein Problem die Applikationen an sich über https zu erreichen.

 

Es ist zum verzweifeln. Könnte ich das Problem weiter einengen oder besser beschreiben, ich würde es tun.

 

So bleibt momentan nur der Weg es über verschiedene Wege zu versuchen.

[Deichgraf17 0]

hm...

 

Ok, wir sind die Zielsetzung noch einmal durchgegangen.

 

Das Workaround über Umleitungen ist nicht gewünscht und würde später auch nicht mehr funktionieren.

 

Über IIS kann ich über den Wizard keinen reverse proxy einrichten wie er gewünscht ist, da / nicht erlaubt ist beim Erstellen einer Reverse Proxy Regel.

 

Wir werden nun versuchen jedem der Tomcats eine virtuelle IP zuzuweisen und die Host-IP nur noch für den Reverse Proxy zu verwenden.

 

Wenn ich richtig vermute, können wir dann eine Serverfarm einrichten in der die Tomcats sind und dann nach einem der oben gelisteten Tutorials weiterverfahren.

[zahni 525]

Es bleibt aber dabei, dass der SSL-Tunnel am IIS endet. Mit den  genannten Einschränkungen.

Wenn der interne Server auch SSL verwendet, muss der IIS  intern einen neuen "Tunnel graben"...

Beachte, dass der IIS  den Zertifikaten auch  vertrauen muss.

 

Schau mal http://weblogs.asp.net/owscott/archive/2013/10/24/creating-a-reverse-proxy-with-url-rewrite-for-iis.aspx

[Deichgraf17 0]

hm...

 

Die Zertifikate sind auch ein Problem. Ich erhalte ständig die Meldung: Die Identität dieser Website wurde nicht verifiziert. Das Serverzertifikat stimmt nicht mit der URL überein. Ich erstelle aber selbst signierte Zertifikate zum testen und benenne diese sogar nach den URLs. Egal ob ich dort persönlich oder webhosting angebe.

 

Für den Reverse Proxy hier meine Arbeitsschritte (vielleicht wird mein Denkfehler dann offensichtlicher):

Noch hat keiner der Tomcats eine eigene IP Adresse:

Ich erstelle auf der default website 2 reverse proxy Regeln:

Im oberen Feld trage ich IP, Port und Applikation ein: xxx.xxx.xxx.xxx:8060/xwiki

SSL lasse ich an, sollen ja nur SSL Anfragen akzeptiert werden.

Die ausgehende Regel lasse ich vorerst frei und drücke ok.

das gleiche mache ich für: xxx.xxx.xxx.xxx:8090/nexus

Die IP Adresse ist identisch.

 

Nun bearbeite ich beide Regeln:

Angeforderte URL entspricht dem Muster unter Verwendung von regulären Ausdrücken

jeweils (xwiki)(.*) und (nexus)(.*)

 

Rufe ich nun die Adresse https://hostname/xwiki auf lädt er die Seite mit oben genanntem Warnhinweis bzgl. des Zertifikats.

Das Schloss im Browser ist durchgestrichen, genauso wie https (in Google Chrome). Über http öffnet er die Site wie gewünscht nicht.

Leider sind alle Links auf der Seite nicht abrufbar, die images werden nicht geladen und ich kann keinen Nutzer einloggen.

 

Rufe ich https://hostname/nexus auf kommt ein simples 404 not found.

 

Da das schon nicht am server selbst funktioniert, muss ich ja erstmal hier die Fehler beheben, bevor ich mich dann dyndns und dem Zugriff von

ausserhalb widmen kann.

 

Edit: Ich danke dir für deine Geduld in dieser Sache :)

 

Edit 2: Nun habe ich einer Applikation schonmal eine eigene IP zugewiesen.

Auch hier erstelle ich die Reverse Proxy Regel, wie oben.

IP xxx.xxx.xxx.yyy:8080/youtrack

Rufe ich die Seite nun über https://hostname/youtrack auf erhalte ich die Meldung:

Diese Seite wurde nicht gefunden / Sie sind nicht angemeldet.

Keiner der Links (Zurück, Anmelden, Tickets) funktioniert.

In der server.xml des Tomcats sind eingetragen:

http port 8080, https port 8443 und die IP

Die Regel wurde auch wie oben beschrieben bearbeitet.

Rufe ich die Site über https://ip:8443/youtrack auf kommt die Meldung "Diese Webseite ist nicht verfügbar"

Rufe ich sie hingegen über http://ip:8080/youtrack auf komme ich ganz normal drauf.

 

Die Bindungen der default website sind http auf 80 und https auf 443.

bearbeitet 31. Januar 2014 von Deichgraf17

[Daniel -MSFT- 129]

Hi Deichgraf17,

 

schau Dir mal die Anleitung für Lync unter http://blogs.technet.com/b/dodeitte/archive/2013/10/29/how-to-publish-lync-server-2013-web-services-with-windows-server-2012-r2-web-application-proxy.aspx an. Dort findest Du eine Veröffentlichung via SSL einer SSL-geschützten Webseite auf einem anderen Port von intern nach extern. Vor allem das Zertifikatshandling musst Du Dir anschauen.

 

Have fun!

Daniel