IIS als Reverse Proxy für mehrere Tomcat Applikationen

[Deichgraf17 0]

H Daniel,

 

vielen Dank für den Link. Allerdings benutzen wir die Verbunddienste nicht und ich werde auch so nicht schlau aus dem Zertifikatshandling.

 

Ich denke schon darüber nach meinen Gesellenbrief einzureichen und auf Schlachter umzuschulen... Es ist zum Mäuse melken...

[zahni 566]

Wenn das was hilft: Du kannst keine Zertifikate "durchreichen". zwischen internen Servern und dem IIS und dem IIS und externen Zugriffen werden immer neue SSL-Tunnel  aufgebaut.

 

Intern solltest Du  eine Enterprise-CA benutzen.  Self-Signed Certs  wachsen Dir irgendwann über  den Kopf.  Extern kauft man die bei  einem Trustcenter des Vertrauens...

[Deichgraf17 0]

hm...

 

Ah danke, das bringt Licht ins Dunkel.

 

Die self-signed sind auch erstmal nur zum testen des Setups gedacht. Das kriege ich ja wie schon gesagt nicht hin.

[ara 10]

my 2 cents:

 

1) Apache als Reverse Proxy ist weitaus "gängiger" als IIS, daher hätte ich eher den genommen.

 

2) ich bin auch kein Apache Guru, aber soweit ich das sehe brauchst du für dein Szenario garkeinen Reverse Proxy, sondern einfach nur Virtual Hosts im Apache anlegen.

[Deichgraf17 0]

hm...

 

Leider geht es ja nicht danach was wir brauchen. Sonst hätte ich eventuell auch einfach eine Software genommen die das Einrichten eines Proxy vereinfacht.

 

Wir müssen den IIS als Reverse Proxy einrichten :(

[Dukel 460]

Kann man auf die Webapplikationen ohne SSL zugreifen (Xwiki, Nexus,...)?

Evtl. würde ich das ganze erst mit SSL Offloading testen. D.h. du gehst per HTTPS auf den IIS Reverse Proxy und daraufhin per HTTP auf die Applikationen.

Wenn das geht kannst du das ganze mit SSL testen.

[Deichgraf17 0]

hm...

 

Ohne SSL geht es. Allerdings auch nur mit Einschränkungen: Sind die Regeln als Umschreibung festgelegt, kann ich mich in den Applikationen nicht mit Benutzerdaten anmelden. Stelle ich die Regeln auf Umleitung klappt alles wunderbar.

 

Ich werde heute Nachmittag noch eine andere Lösung probieren, bei der ich erstmal ganz auf SSL verzichte. Ich werde dann ein Update posten.

 

hm...

 

 

So, hab es dieses mal mit folgenden Regeln versucht:

 

<rewrite>
          <rules>
<rule name="Reverse Proxy zu Nexus" stopProcessing="true">
<match url="^nexus/(.*)" />
<action type="Rewrite" url="http://localhost:8090/nexus/{R:1}" />
</rule>
<rule name="Reverse Proxy zu XWiki" stopProcessing="true">
<match url="^xwiki/(.*)" />
<action type="Rewrite" url="http://localhost:8060/xwiki/{R:1}" />
</rule>
          </rules>
            <outboundRules>
                <rule name="Applikationsprefix zufuegen" preCondition="IsHTML">
                    <match filterByTags="A" pattern="^/(.*)" />
                    <conditions>
                        <add input="{URL}" pattern="^/(nexus|xwiki)/" />
                    </conditions>
                    <action type="Rewrite" value="/{C:1}/{R:1}" />
                </rule>
                <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                    <preCondition name="IsHTML">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>

 

        

Auf die Seiten komme ich, solange ich nicht vergesse das / am Ende mitzutippen.

 

Leider funktionieren Links und Bilder ja nicht mehr, wie schon weiter oben erwähnt. SSL ist vorerst aus.

 

Die Links funktionieren noch wenn ich direkt auf die entsprechende Applikation gehe, zum Beispiel:

 

http://localhost:8060/xwiki/bin/view/Konfiguration+der+Entwicklungsumgebung/WebHome

 

Nutze ich nun die Reverse Proxy Regel um auf die Applikation zu gehen sieht das ganze so aus:

http://localhost/xwiki/xwiki/bin/view/Konfiguration+der+Entwicklungsumgebung/WebHome

 

Die ausgehende Regel, die Links etc. pp. umschreiben soll ist also die Fehlerquelle in diesem Fall. Schreibe ich den Port nun per Hand in die ausgehende Regel, kann ich die Links nicht einmal mehr anklicken, das ist also auch nicht die Lösung.

 

Ich denke wenn wir das Problem lösen ist es nur noch ein Klacks um dann zwischen Client und IIS SSL einzuschalten.

 

Ich vermute mal ganz stark, dass ich für jede Applikation dann eine eigene ausgehende Regel brauche. Nur habe ich keinen Schimmer, wie ich diese aufbauen muss.

 

Vielen Dank für eure Geduld,

Jack

bearbeitet 4. Februar 2014 von Deichgraf17

[Daniel -MSFT- 129]

Hi Jack,

 

da ich Dein Szenario hier nicht nachbauen kann, ist eine spezifische Hilfe schwierig. Ich empfehle Dir, Dir einmal folgende Tutorials anzusehen. Dort wird auch erklärt, wie man die relativen Links mit transformiert bekommt, damit Bilder und JavaScript auch funktionieren. Probier das als erstes, indem Du vom IIS zum Backend Server ohne SSL arbeitest (SSL Offloading). Neben dem URL Rewrite brauchst Du noch die Reverse Proxy-Funktion:

• Setting up a Reverse Proxy using IIS, URL Rewrite and ARR
• Creating a Reverse Proxy with URL Rewrite for IIS

Eventuell solltest Du weitere Fragen auch in dem IIS ARR-Forum stellen, da dort sicher mehr Experten zu dem Thema unterwegs sind. Wenn Du eine Lösung gefunden hast, wäre ein kurzes Feedback nett.

 

Have fun!
Daniel

bearbeitet 4. Februar 2014 von Daniel -MSFT-

[Dukel 460]

Ich habe das in einem IIS folgendermaßen laufen.

Im IIS eine website mit der URL und mehrere Ordner (z.B. owa). In diesen Ordnern jeweils eine Rewrite Regel.

 

 

<rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                    </conditions>
                    <action type="Rewrite" url="https://intern/owa/{R:1}" />
                </rule>
            </rules>
            <outboundRules>
                <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
                    <match filterByTags="A, Form, Img" pattern="^http(s)?://intern/(.*)" />
                    <action type="Rewrite" value="http{R:1}://extern.de/{R:2}" />
                </rule>
                <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>

bearbeitet 4. Februar 2014 von Dukel

[Deichgraf17 0]

hm...

 

Danke euch für eure Eingaben.

 

Das Hauptproblem lag wohl wirklich bei den Regulären Ausdrücken.

 

Haben wir im Muster vorher z.B. (xwiki)(*) eingetragen funktionierte es nur per Umleitung.

Als Umschreibung funktioniert es nur ohne die ersten Klammern, also xwiki(*).

So brauchen wir auch keine ausgehende Regel :)

 

Leider meldet sich der Xwiki User nach einem Klick auf einen Link immer noch ab, aber wir sind schonmal einen Riesenschritt weiter.

 

Sobald ich dieses Problem gelöst habe fasse ich das ganze in einem abschließenden Post zusammen.

 

Danke euch allen!

[zahni 566]

Denke an die "Kekse" Da steht auch u.a. Domänen drin, für sie jeweils gültig sind. Wen die  Domäne extern eine ande3re  ist  als intern, wird der Keks vom Browser verworfen.

Hier  solltest Du, wie schon geschrieben, extern mal den Fiddler2 zur Analyse benutzen

[Deichgraf17 0]

hm...

 

Ok Fiddler läuft. Welche Informationen brauchst du denn daraus? Ich werde von der Menge an Informationen doch etwas erschlagen.

 

Ich habe Lösungen via Serverfarm für das Problem gefunden (dort dann unter Serveraffinität geregelt), kommt für unser Setup leider nicht

in Frage.

[zahni 566]

Ich nicht. Sorry, das musst Du selber machen. Ich kann Dir nur  Ratschläge geben, wo Du suchen solltest.

Was alles  in den  HTTP-Headern steht, kannst  Du in den RFC's nachlesen.

[Deichgraf17 0]

hm...

 

Ok, ich wusel mich da durch.

 

Ich kann schonmal die Information ausfindig machen, das gar kein Cookie erstellt wird.

[zahni 566]

Wenn Du  Dich anmeldest,  musst Du irgendeine Session bekommen, entweder per Query-String (heute  eher  unüblich) oder per Session-Cookie.