Deichgraf17

hm... Waren Vorgaben vom Chef. Das Problem lag am Cookie von Xwiki. useip=false war hier die Lösung. Damit lief unser System dann auch genau so, wie wir es haben wollten. Habe die Ports dann noch dicht gemacht und wollte alles schön dokumentieren. Leider hat sich dann unser .NET framework zerschossen und nix ging mehr. Dann hat Chef uns das Projekt entzogen :( 20 Arbeitstage seien zu viel für nur einen Desktop PC.

hm... Am Session Timeout von Tomcat liegt es definitiv nicht. Das ist auf 30 Minuten eingestellt. Wenn ich mit Wireshark versuche nachzuvollziehen was passiert kann ich folgendes feststellen: Verbinde ich mich mit Nexus und logge ein, kann ich deutlich den Handshake nachvollziehen. Dieser kommt von einer Source IP und geht an eine Destination IP (beide nicht die, die ich hier vergeben habe). Im Trace mit Xwiki kann ich den Handshake nirgends finden. Source und Destination sind keine IP Adressen sondern wilde folgen von Zeichen und eine Menge Broadcasts dazwischen. Nr Time Source Destination Protocol 2748 72.921283000 Avm_95:f0:e1 AtherosC_00:00:01 HomePlug AV 60 MAC Management, Central Coordination Discovery List Request <<< eine Zeile aus dem Trace für Xwiki

hm... Nach ein paar Tests stellt sich heraus, dass dieses Problem Xwiki spezifisch ist. Die anderen Applikationen behalten ihre Sessions. Heute Nachmittag werde ich mich da verstärkt reinknien und der Sache auf den Grund gehen. Die Session ID ist definitiv nich tim Query-String bei Xwiki

hm... Ok, ich wusel mich da durch. Ich kann schonmal die Information ausfindig machen, das gar kein Cookie erstellt wird.

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.

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!

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

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 :(

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.

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...

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.

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.

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.

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.

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.