Hallo Liste! Ich möchte folgendes Problem lösen: In einem verteilen WAN existiert ein zentraler Squid, der den gesamten Internetverkehr abdeckt. Daneben exisieren im WAN (10.0.0.0/255) mehrere lokale Webserver, die direkt, also ohne den Umweg über diesen Proxy, erreicht werden sollen. Dazu soll es in den LANs eigene Squids geben, die jede Internetanfrage an den zentralen Proxy weiterleiten (parent_proxy), alle internen Anfragen an 10.0.0.0/255 aber direkt weiterleiten. Passende ACLs habe ich nicht gefunden und die Option always_direct hilft mir auch nicht weiter. Ideen, Dokumentationen (außer der Squid-Doku)? TIA hebi -- Dirk Hebenstreit Tel : +49-170-2461522 Eschenweg 3 +49-33200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.org
Dirk Hebenstreit, Dienstag, 13. April 2004 16:12:
Hallo Liste!
Ich möchte folgendes Problem lösen:
In einem verteilen WAN existiert ein zentraler Squid, der den gesamten Internetverkehr abdeckt. Daneben exisieren im WAN (10.0.0.0/255) mehrere lokale Webserver, die direkt, also ohne den Umweg über diesen Proxy, erreicht werden sollen. Dazu soll es in den LANs eigene Squids geben, die jede Internetanfrage an den zentralen Proxy weiterleiten (parent_proxy), alle internen Anfragen an 10.0.0.0/255 aber direkt weiterleiten.
Passende ACLs habe ich nicht gefunden und die Option always_direct hilft mir auch nicht weiter.
Ideen, Dokumentationen (außer der Squid-Doku)?
Idee: Richte den lokalen Squid als transparenten Proxy (automatische Umleitung aller http[s]-Anfragen an den Squid mittels Packetfilter, z.B. iptables) ein - das macht sich auch einfacher in der Konfiguration der Clients und ist sicherer. In den iptables-Regeln kannst du dann festlegen, dass Anfragen an eine lokale Adresse an den Proxy weitergeleitet werden sollen. Ansonsten bliebe nur die clientseitige Einstellung, dass bestimmte Adressen nicht über den Proxy abgefragt werden sollen. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu
Am Dienstag, 13. April 2004 16:12 schrieb Dirk Hebenstreit:
Hallo Liste!
Hallo Dirk,
Ideen, Dokumentationen (außer der Squid-Doku)?
Leider nicht. Aber ich habe eine Frage:
[...] im WAN (10.0.0.0/255) [...]
Was ist das denn für eine Schreibweise? Dass das "weite" Netz die Netzwerkadresse 10.0.0.0 trägt, ist schon klar. [1] Aber was ist das für eine Subnetzmaske? Du kannst Subnetzmasken außer in Binärform (als 32-Bit-Schlangen) in drei verschiedenen üblichen Formaten schreiben. Bei einer 19-Bit-Maske 1111 1111.1111 1111.1110 0000.0000 0000 wären das z.B.: Dotted Quad: 255.255.224.0 Hexadezimal: FFFFE000 Bit-Count: /19 Was will uns jetzt aber "/255" sagen? Sich am Kopf kratzend, Marcus --- Anmerkung --- [1] Eine zweite Frage hätte ich auch noch, nur weil ich neugierig bin: wie groß und verzweigt ist denn dass Netzwerk, das Du da administrierst? Wenn tatsächlich große Distanzen überwunden werden müssen und dazu dann solche Dinge wie Standleitungen, packet-, cell- oder circuit-geswitchte Verbindungen, VPNs, Dial-on-Demand-Routing und ähnliches notwendig werden, dann ist das eine weit komplexere Aufgabe als die Administration eines kleinen, einfachen lokalen Netzwerks; -- und wenn an dem Netzwerk tatsächlich so viele Geräte (und noch mehr Menschen) hängen, dass eine Klasse-A-Netzwerkadresse nötig ist, um es zu verwalten (vielleicht mittels VLSM?), dann ist das ein wirklich verantwortungsvoller Job, und Du solltest mit den diffizilen Technologien, mit denen Du umgehst, auch tatsächlich vertraut sein.
Marcus Glöder schrieb:
Am Dienstag, 13. April 2004 16:12 schrieb Dirk Hebenstreit:
Hallo Liste!
Hallo Dirk,
Ideen, Dokumentationen (außer der Squid-Doku)?
Leider nicht. Aber ich habe eine Frage:
[...] im WAN (10.0.0.0/255) [...]
Was ist das denn für eine Schreibweise? Dass das "weite" Netz die
Das ist die "hebi"-Schreibweise *g* Sorry, sollte entweder /255.0.0.0 oder /8 werden, ist dann aber wohl eine Mischung daraus geworden (man sollte doch manchmal genauer lesen, was man so alles postet). [Lehbuchauszug gekürzt; schön dargestellt, hoffentlich lesen auch Anfänger den Thread :-)]
Sich am Kopf kratzend,
Schauma-Shampoo? *bg*
Marcus
--- Anmerkung ---
[1] Eine zweite Frage hätte ich auch noch, nur weil ich neugierig bin: wie groß und verzweigt ist denn dass Netzwerk, das Du da administrierst? Wenn tatsächlich große Distanzen überwunden werden müssen und dazu dann solche Dinge wie Standleitungen, packet-, cell- oder circuit-geswitchte Verbindungen, VPNs, Dial-on-Demand-Routing und ähnliches notwendig werden, dann ist das eine weit komplexere Aufgabe als die Administration eines kleinen, einfachen lokalen Netzwerks; -- und wenn an dem Netzwerk tatsächlich so viele Geräte (und noch mehr Menschen) hängen, dass eine Klasse-A-Netzwerkadresse nötig ist, um es zu verwalten (vielleicht mittels VLSM?), dann ist das ein wirklich verantwortungsvoller Job, und Du solltest mit den diffizilen Technologien, mit denen Du umgehst, auch tatsächlich vertraut sein.
Das Netz IST sehr groß, so etwa 30.000 Clients und hunderte Server bundesweit. Es basiert (derzeit noch) auch Frame Relay und wird zentral von unserem Rechenzentrum administriert. Und die Kollegen dort wissen, mit diesem Job umzugehen (auch wenn es, wie bei jedem größerem Netz, immer mal wieder klemmt und die Nutzer dann maulen, die Admins wären unfähig. Die wissen halt nicht, WAS alles dahinter hängt!) Wenn Du mal die "öffentliche" Seite unseres Netzes besuchen willst, dann gehe mal zu http://www.zoll.de oder http://www.bundesfinanzministerium.de :-) Gruß hebi -- Dirk Hebenstreit Tel : +49-170-2461522 Eschenweg 3 +49-33200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.org
Hallo Dirk, Am Donnerstag, 15. April 2004 09:53 schrieb Dirk Hebenstreit:
Marcus Glöder schrieb:
Was ist das denn für eine Schreibweise? Dass das "weite" Netz die
Das ist die "hebi"-Schreibweise *g* Sorry, sollte entweder /255.0.0.0 oder /8 werden, ist dann aber wohl eine Mischung daraus geworden (man sollte doch manchmal genauer lesen, was man so alles postet).
OK, das kann jedem mal passieren...
[Lehrbuchauszug gekürzt; schön dargestellt, hoffentlich lesen auch Anfänger den Thread :-)]
Danke. Bei mir ist der Lehrbuchinhalt noch ziemlich frisch im Kopf. Seit 17.11.03 bin ich CCNA, Cisco ID: CSCO10664435. (Ich weiß nicht so genau, ob ich beim Cisco Tracking System noch was freischalten muss, damit Du meine bestandene Prüfung "bestaunen" kannst.)
Sich am Kopf kratzend,
Schauma-Shampoo? *bg*
Nee, ich nehm' immer das Shampoo vom Friseur nebenan (der hat eine eigene Marke...). ;-)
Das Netz IST sehr groß, so etwa 30.000 Clients und hunderte Server bundesweit. Es basiert (derzeit noch) auf Frame Relay und wird zentral von unserem Rechenzentrum administriert. Und die Kollegen dort wissen, mit diesem Job umzugehen (auch wenn es, wie bei jedem größerem Netz, immer mal wieder klemmt und die Nutzer dann maulen, die Admins wären unfähig. Die wissen halt nicht, WAS alles dahinter hängt!)
Huch! Sollte ich irgendwelche Zweifel an Deiner Kompetenz gehabt haben, nehme ich sie hiermit umgehend zurück. Respekt! An ein derartiges Netz würde ich mich jedenfalls _nicht_ herantrauen. (Aber ich bin ja auch nur ein kleiner CCNA.) Zur Klammer ein kräftiges ACK.
Wenn Du mal die "öffentliche" Seite unseres Netzes besuchen willst, dann gehe mal zu http://www.zoll.de oder http://www.bundesfinanzministerium.de :-)
Das is' ja richtig offiziell...
Gruß hebi
Grüße, Marcus
Marcus Glöder schrieb: ...
Danke. Bei mir ist der Lehrbuchinhalt noch ziemlich frisch im Kopf. Seit 17.11.03 bin ich CCNA, Cisco ID: CSCO10664435. (Ich weiß nicht so genau, ob ich beim Cisco Tracking System noch was freischalten muss, damit Du meine bestandene Prüfung "bestaunen" kannst.)
Oh, Gratulation! Da kann ich leider nicht mithalten, ich habe nur einen "Certified Network Security Engineer" ;-)
Schauma-Shampoo? *bg*
Nee, ich nehm' immer das Shampoo vom Friseur nebenan (der hat eine eigene Marke...). ;-)
Ich auch - das Shampoo macht meine Frau nach einem Rezept der Hobbythek, sehr empfehlenswert!
Huch! Sollte ich irgendwelche Zweifel an Deiner Kompetenz gehabt haben, nehme ich sie hiermit umgehend zurück. Respekt! An ein derartiges Netz würde ich mich jedenfalls _nicht_ herantrauen. (Aber ich bin ja auch nur ein kleiner CCNA.) Zur Klammer ein kräftiges ACK.
*g* Ich bin ja nur der Ausbilder der Systemverwalter, die die Kisten in diesem Netz betreuen, das WAN geht zentral über unser RZ.
Wenn Du mal die "öffentliche" Seite unseres Netzes besuchen willst, dann gehe mal zu http://www.zoll.de oder http://www.bundesfinanzministerium.de :-)
Das is' ja richtig offiziell...
Ja, man muß ja auch mal ein bischen Werbung machen :-) Ja, auch manche Behörde ist recht modern *bg* Gruß hebi -- Dirk Hebenstreit Tel : +49-170-2461522 Eschenweg 3 +49-33200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.org
On Tuesday 13 April 2004 16:12, Dirk Hebenstreit wrote: Hallo,
In einem verteilen WAN existiert ein zentraler Squid, der den gesamten Internetverkehr abdeckt. Daneben exisieren im WAN (10.0.0.0/255) mehrere lokale Webserver, die direkt, also ohne den Umweg über diesen Proxy, erreicht werden sollen. Dazu soll es in den LANs eigene Squids geben, die jede Internetanfrage an den zentralen Proxy weiterleiten (parent_proxy), alle internen Anfragen an 10.0.0.0/255 aber direkt weiterleiten.
Passende ACLs habe ich nicht gefunden und die Option always_direct hilft mir auch nicht weiter.
wenn ich das jetzt richtig verstanden habe, sollen alle clients auf jeden Fall mit dem ersten squid arbeiten (d.h. wir brauchen keine transparent proxies und passende filter). Dieser soll dann entscheiden ob von ihm aus eine direkte Verbindung zu nutzen ist oder besser der zentrale Squid (z.B. für externes Internet) zu nutzen ist. Wenn dem so ist dann funktionierte bei mir mal eine Installation die im Prinzip auf der ersten Stufe (Squid Version 2.5) so Konfiguiert war: # Definition der Masterproxies cache_peer master_proxy1.mynet.internal parent 3128 3130 cache_peer master_proxy2.mynet.internal parent 3128 3130 # ACL für unsere internen Webserver acl internal_web dstdomain webint1.mynet.internal webint2.mynet.internal # Interne Webserver niemals über parent caches always_direct allow internal_web Was fehlt Dir hier bzw. warum sollte das für Deinen Bedarf nicht funktionieren? Gruß Thomas -- IRC: TomseDive Jabber: tomse@jabber.org ICQ: 4843585
Thomas Vollmer schrieb: ...
wenn ich das jetzt richtig verstanden habe, sollen alle clients auf jeden Fall mit dem ersten squid arbeiten (d.h. wir brauchen keine transparent proxies und passende filter). Dieser soll dann entscheiden ob von ihm aus eine direkte Verbindung zu nutzen ist oder besser der zentrale Squid (z.B. für externes Internet) zu nutzen ist.
Genau
Wenn dem so ist dann funktionierte bei mir mal eine Installation die im Prinzip auf der ersten Stufe (Squid Version 2.5) so Konfiguiert war:
# Definition der Masterproxies cache_peer master_proxy1.mynet.internal parent 3128 3130 cache_peer master_proxy2.mynet.internal parent 3128 3130
# ACL für unsere internen Webserver acl internal_web dstdomain webint1.mynet.internal webint2.mynet.internal
# Interne Webserver niemals über parent caches always_direct allow internal_web
Was fehlt Dir hier bzw. warum sollte das für Deinen Bedarf nicht funktionieren?
Der folgende Versuch war nicht erfolgreich, scheint mir aber Deinem Vorschlag zu entsprechen: cache_peer 10.x.y.z parent 3128 7 no-query default acl all src 0.0.0.0/0.0.0.0 acl intranet dst 10.0.0.0/255.0.0.0 never_direct allow all http_access allow all always_direct allow intranet Es klappt immer nur der Zugriff auf einen Teil, intern oder Internet. Unterscheidet Squid zwischen FQDN und IPs? Oder verstehe ich da eine der anderen Optionen falsch? Gruß hebi -- Dirk Hebenstreit Tel : +49-170-2461522 Eschenweg 3 +49-33200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.org
On Monday 19 April 2004 08:19, Dirk Hebenstreit wrote:
Thomas Vollmer schrieb:
Was fehlt Dir hier bzw. warum sollte das für Deinen Bedarf nicht funktionieren?
Der folgende Versuch war nicht erfolgreich, scheint mir aber Deinem Vorschlag zu entsprechen:
cache_peer 10.x.y.z parent 3128 7 no-query default
acl all src 0.0.0.0/0.0.0.0 acl intranet dst 10.0.0.0/255.0.0.0
never_direct allow all http_access allow all always_direct allow intranet
Ich verstehe die ganzen Einstellungen nicht die Du dort gemacht hast. Erst verbietest Du /allen/ clients über den proxy direkte Anfragen an die Server zu stellen und dann versuchst Du Anfragen ins 10.0.0.0/8 Netz (Ich hasse den Begriff 'Intranet'; reines Marketinggewäsch) doch wieder auf direktem Weg zu schicken. Da sich never_direct und always_direct etwas beißen und die negativen Filter immer Vorrang haben sollten, würde ich die never_direct Direktive mal rauswerfen.
Es klappt immer nur der Zugriff auf einen Teil, intern oder Internet. Unterscheidet Squid zwischen FQDN und IPs? Oder verstehe ich da eine der anderen Optionen falsch?
Also für ACLs mit IP-Adressen (bzw. Netzen) verwendet squid dst und src und für FQDN, oder genauer DN, wird dstdomain und srcdomain genommen. Gruß Thomas -- IRC: TomseDive Jabber: tomse@jabber.org ICQ: 4843585
Thomas Vollmer schrieb: ...
never_direct allow all http_access allow all always_direct allow intranet
Ich verstehe die ganzen Einstellungen nicht die Du dort gemacht hast. Erst verbietest Du /allen/ clients über den proxy direkte Anfragen an die Server zu stellen und dann versuchst Du Anfragen ins 10.0.0.0/8 Netz (Ich hasse den Begriff 'Intranet'; reines Marketinggewäsch) doch wieder auf direktem Weg zu schicken.
Da sich never_direct und always_direct etwas beißen und die negativen Filter immer Vorrang haben sollten, würde ich die never_direct Direktive mal rauswerfen.
Gut, werde ich ausprobieren (lassen). Da ich die Konfiguration nicht selber erstellt habe, sondern von einem Kollegen gebeten worden bin, sie zu überprüfen, war ich wohl etwas unkonzentriert, Deine Hinweise hätten mir eigentlich auch auffallen sollen. Mal sehen, ob es daran lag, vielen Dank!
Es klappt immer nur der Zugriff auf einen Teil, intern oder Internet. Unterscheidet Squid zwischen FQDN und IPs? Oder verstehe ich da eine der anderen Optionen falsch?
Also für ACLs mit IP-Adressen (bzw. Netzen) verwendet squid dst und src und für FQDN, oder genauer DN, wird dstdomain und srcdomain genommen.
So hatte ich es auch interpretiert, war mir aber nicht mehr sicher. Danke für die Tips! Gruß hebi -- Dirk Hebenstreit Tel : +49-170-2461522 Eschenweg 3 +49-33200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.org
participants (4)
-
Dirk Hebenstreit -
Marcus Glöder -
Matthias Houdek -
Thomas Vollmer