Proxy-Array Squid

[ben_fd]

Hallo,

wir benutzen bei uns ein Array aus mehreren Proxies, die über cache_peer (parent) verbunden sind. Die Sache funktioniert einwandfrei.
Es gibt allerdings manchmal Probleme bei der Authentifizierung auf Webseiten. (Zum Beispiel auf diesem Forum) Gibt es eine Möglichkeit eine Session dauerhaft über eine Kette zu führen, oder ist das überhaupt die gesuchte Lösung???

Vielen Dank für Eure Hilfe.

Ben:confused:

[mbo]

was heißt problem bei der authentifizierung?
sollte es problem geben ala keine cookies aktiviert?

[ben_fd]

Hallo,

nein, ich denke, dass das nichts mit cookies zu tun hat. Ich habe ein round-robin über die parent Proxies eingerichtet. Das heißt es kann sein, dass der Anmeldungvorgang und der weitere Surfvorgang über unterschiedliche Parent-Proxies abläuft.

Ben

[mbo]

- unwahrscheinlich,
- kaum möglich

sollte ein rechner ein verbindung zu einem host über einen proxy aufbauen, wird diese verbindung mit sicherheit nicht vom zufallsprinzip beeinflußt, es sein denn, deine proxy schließe sämtlich connections in5 sek takt ;)
die authentifizierung in diesem forum läuft über den cookie, da werden die daten nach der anmeldung gespeichert.

das hieße, die anmeldung
client -> server "hallo"
server -> client "wer bist du"
client -> Server "ich bin ich"
server -> client "oki, hier hast cookie"
müßte durch deine parents unterbrochen werden. das hielte ich für sehr unwahrscheinlich, wobei ich anmerken muß, dieses nicht für unmöglich zu halten.

die frge ist: WIE stellt sich dieser fehler genau dar?

[ben_fd]

Hallo,

der Fehler ist wie folgt:

-Anmeldung: <username> <passwort>
-Rückmeldung: Vielen Dank für deine Anmeldung! (erfolgreich)
-erneut Login-Screen --> erneute Anmeldung
-erst jetzt ist arbeiten möglich

Es sind zwei Parent-Proxies vorhanden, einer über Standleitung und einer über DSL. Konfiguration: Alles RedHat 7.3 und Squid 2.4 Stable.
Das Phänomen habe ich übrigens auf diversen Seiten, nicht nur hier.

Ben

[mbo]

huch

das problem hatte ich auch schon ;)

- ohne proxy
- mit einem proxy
- mit parentproxy

also am proxy liegt es wohl eher nicht.
ehrlich gesagt kenne ich keine irretationen, auch nicht mit loadbalancer, die solche phänomene hervorrufen. nur dummerweise kann ich dir nicht sagen, woran es bei oben genannten fällen lag.

zumindest in diesem forum kannst du etwas testen.
1.) die cookieeinstellungen hinsichtlich der absendenden domaine
2.) in den boardeinstellungen den cookie deaktivieren und dann schauen, was passiert, wenn du dich hier einlogst (anm.: wenn du die seite wechselst, ist auch deine anmeldung weg)
3.) sofern du zugriff auf die parents bekommst, überprüfe doch mal die sessions, ob sie wirklich wechseln (das möcht ich nämlich bezweifeln)

[ben_fd]

Hallo,

ich hatte die Cokies bereits deaktiviert. Das heißt meine Daten wurden mit dem Link mit übertragen. Wo könnte der Fehler noch liegen.
Ist es nicht richtig, dass der zentrale Proxy auch einen Seitenaufruf (z.B. www.test.de) in mehrer Aufrufe (Bild1 --> ProxyA, Bild2 --> ProxyB) an seine übergeordneten round-robin Proxies weitergibt?

Ben:confused:

[ben_fd]

Hallo,

hat sonst niemand mehr eine Idee???

Ben:(

[mbo]

Original geschrieben von ben_fd

Ist es nicht richtig, dass der zentrale Proxy auch einen Seitenaufruf (z.B. www.test.de) in mehrer Aufrufe (Bild1 --> ProxyA, Bild2 --> ProxyB) an seine übergeordneten round-robin Proxies weitergibt?


das würde nicht mal ein "richtiger" loadbalancer machen ;)

ein aufstand - ein ranger! ;)

mich würden die logs dazu höchstens noch reizen weiter zu denken. im moment bin ich blank an ideen.
es fällt mir auch nicht mehr ein, woran es bei mir lag. ich hätte eher anfangen sollen all die kleinigkeiten aufzuschreiben.

[ben_fd]

Hallo,

hier ist mal meine cache_peer - config des "zentralen Proxy" und ein Beispiel-Log:
Man sieht im Log, dass beim Aufruf einer einzelnen Seite mehrere übergeordnete Proxies dazugenommen werden. Warum???

cache_peer 10.3.10.1 parent 8080 3130 round-robin
cache_peer 10.4.10.1 parent 8080 3130 round-robin
cache_peer 10.5.10.1 parent 8080 3130 round-robin
cache_peer 10.10.10.1 parent 8080 3130 round-robin
cache_peer 10.12.100.6 parent 8080 3130 round-robin

1049451562.838 2305 10.100.1.111 TCP_MISS/200 32490 GET http://www.test.de/html/style/format.css - TIMEOUT_FIRST_PARENT_MISS/10.4.10.1 text/css
1049451563.076 223 10.100.1.111 TCP_MISS/200 500 GET http://www.test.de/img/profisuche/suche.gif - TIMEOUT_FIRST_PARENT_MISS/10.5.10.1 image/gif
1049451563.265 188 10.100.1.111 TCP_MISS/200 497 GET http://www.test.de/img/navebene1/nave_off.gif - FIRST_PARENT_MISS/10.4.10.1 image/gif
1049451563.515 250 10.100.1.111 TCP_MISS/200 497 GET http://www.test.de/img/navebene2/nave_off.gif - TIMEOUT_FIRST_PARENT_MISS/10.4.10.1 image/gif
1049451564.396 3211 10.100.1.111 TCP_MISS/200 453 GET http://www.test.de/img/dot.gif - TIMEOUT_FIRST_PARENT_MISS/10.4.10.1 image/gif
1049451564.590 194 10.100.1.111 TCP_MISS/200 521 GET http://www.test.de/img/navebene3/b_aus.gif - FIRST_PARENT_MISS/10.4.10.1 image/gif
1049451565.062 470 10.100.1.111 TCP_MISS/200 455 GET http://www.test.de/img/navebene3/dot.gif - FIRST_PARENT_MISS/10.12.100.6 image/gif
1049451565.287 224 10.100.1.111 TCP_MISS/200 529 GET http://www.test.de/img/navebene3/navebene3_0/b2_an.gif - FIRST_PARENT_MISS/10.4.10.1 image/gif
1049451565.497 209 10.100.1.111 TCP_MISS/200 453 GET http://www.test.de/img/tempmitte/dot.gif - TIMEOUT_FIRST_PARENT_MISS/10.4.10.1 image/gif