dackelblick
Goto Top

SQUID Lastverteilung mit AD

Dabei will ich Lastverteilung so verstanden wissen, dass ich einen squid (2.7 stable 3) zur Authentifizierung verwenden will und einen (oder mehrere) nur fürs Cashing.

Hallo Zusammen.

Das Szenario ist folgendes:

An einem Zentralpunkt im Netz sind die DomainController vom AD und ein Squid Server. Dieser soll nur die Userauthentifizierung gegen das AD machen. Sobald diese erfoglreich war soll dieser Proxy nun einem 2. Proxy etwa 500 Kilometer via WAN verbunden mitteilenAnmeldung OK übernehme das Cashing für den Client. XYZ. Nun muss man noch wissen, das der Client XYZ in einer Niederlassung (einam anderen Netzwerk) sitzt mit einer Verbindung in dieses WAN.

Ziel soll also sein. Den Internettraffic nicht über einen zentralen Proxy zu "routen", sondern nur den Internettraffic vom Internetausgang/-eingang direkt zur Niederlassung. Alles was übrig bleiben soll an zentralen Datenströmen ist die Authentifizierung.

Einzelne (was der leichte Weg wäre) Squid Proxyies in den Standorten aufzubauen ist nicht erwünscht.

Habt Ihr ein paar Tipps? Mir würde für den Anfang schon die richtige Terminologie reichen wie man ein solches Szenario nennt, um ab da selber zu suchen.

Content-ID: 119125

Url: https://administrator.de/contentid/119125

Ausgedruckt am: 25.11.2024 um 08:11 Uhr

Dani
Dani 26.06.2009 um 17:15:10 Uhr
Goto Top
Hi,
wo ist der Unterschied welcher Squid gegen das AD authentifziert? Denn ob er nun direkt die Query an den Zentralpunkt stellt oder an den regionalen Proxy spielt doch keine Rolle. Sind fast immer gleich viel Pakete.

Du widersprichtst dich:
diese erfoglreich war soll dieser Proxy nun einem 2. Proxy etwa 500 Kilometer via WAN verbunden mitteilenAnmeldung OK..

Einzelne (was der leichte Weg wäre) Squid Proxyies in den Standorten aufzubauen ist nicht erwünscht.
Was nun?
Dackelblick
Dackelblick 29.06.2009 um 09:56:11 Uhr
Goto Top
Da ist kein Widerspruch.

Es sind um die 20 Standorte. Sollzustand: Jeder von ihnen authentifiziert sich zentral an Proxy Eins und der gibt danach ab an Proxy 2 (500 km weit weg im WAN/Internetausgang) der zentral das reale cashing übernimmt unter Umgehung von Proxy 1 (und der damit verbundnen Netzwerkstrecke über Proxy 1).

Also zwei Proxies. Einer zentrale Autenthifizierung und einer zentrales Cashing only. Daziwschen 500 km WAN-Strecke und x Ausgänge in die Strandorte ohne Proxy.

Wo ist da der der Widerspruch? Im jeweiligen Niederlassungs-LAN gibt es keinen Proxy. Wo steht, dass es einen regionalen Proxy gibt?

Die Frage ist. Geht das und falls ja welche Stichworte passen dazu?
Dackelblick
Dackelblick 01.07.2009 um 11:42:13 Uhr
Goto Top
Ich probiere es noch einmal mit fachlichem Echo hier....

Derzeitiger Stand der Dinge ist:
9b95e184871b0690d4c02bf013ea8c64-image2

Proxy Eins (P1) hat als cach_peer Proxy 2 (P2) Die Beziehung ist silbing (P1) und parent (P2). PS arbeitet als origin Server. Die Anmeldung erfolgt gegen P1 und scheint auch dort zu funktionieren (Inhalt der Logs). Danach soll P2 das cashing übernehmen, scheitert aber an "falschen" Headern?!?

Folgende Optionen und ihre Werte, die mir wichtig erschienen: P1 und P2 HTTP11 off und via off
P2 liefert stets 
2009/07/01 11:27:11| clientTryParseRequest: FD 15 (192.168.1.180:56236) Invalid Request
2009/07/01 11:27:11| clientTryParseRequest: FD 15 (192.168.1.180:36948) Invalid Request
2009/07/01 11:27:14| clientTryParseRequest: FD 15 (192.168.1.180:40114) Invalid Request
Entferne ich im cache_peer Eintrag von P1 die Option für P2 originserver, so wird P2 nicht angesprochen, sondern P1 versucht die Seite selber im Internet zu finden.

Im Log gefunden...
01 2009/07/01 11:53:07| parseHttpRequest: Method is 'GET'  
02 2009/07/01 11:53:07| parseHttpRequest: URI is '/'  
03 2009/07/01 11:53:07| parseHttpRequest: req_hdr = {Host: de.selfhtml.org^M
04 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)^M
05 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^M
06 Accept-Language: de^M
07 Accept-Encoding: gzip,deflate^M
08 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7^M
09 X-Forwarded-For: 192.168.1.133^M
10 Cache-Control: max-age=259200^M
11 Connection: keep-alive^M
12 ^M
13 }
14 2009/07/01 11:53:07| parseHttpRequest: prefix_sz = 423, req_line_sz = 16
15 2009/07/01 11:53:07| parseHttpRequest: Request Header is

16 Host: de.selfhtml.org^M
17 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)^M
18 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^M
19 Accept-Language: de^M
20 Accept-Encoding: gzip,deflate^M
21 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7^M
22 X-Forwarded-For: 192.168.1.133^M
23 Cache-Control: max-age=259200^M
24 Connection: keep-alive^M
25 ^M
Die Zeilen Nummen dienen nur der Kommunikation, so eine passiert. Verdächtig sind die Zeilen 02, 03 und 16.

Was in 03 und 16 stehen müsste, weiss ich nicht, aber in 02 müsste m.E. "http://de.selfhtml.org" stehen und nicht "/"


Ein Gegencheck liefert nun Klarheit:

01 2009/07/01 12:15:50| parseHttpRequest: Method is 'GET'
02 2009/07/01 12:15:50| parseHttpRequest: URI is 'http://www.mx5-technik.de/'
03 2009/07/01 12:15:50| parseHttpRequest: req_hdr = {Host: www.mx5-technik.de^M

Das Problem ist die URI. Warum geht sie verloren, woe bekomme ich sie dorthin?
Jemand Ideen?
Dani
Dani 01.07.2009 um 18:49:38 Uhr
Goto Top
Hi,
die Squid-Konfigurationen wären hilfreich...


Grüße,
Dani
Dackelblick
Dackelblick 02.07.2009 um 09:20:32 Uhr
Goto Top
Nach einem Feedback der Squid-Cache Community geht es nicht.