Squid Problem bei https über cache peer

Hallo Leute,

ich habe meinen Squid-Proxy so eingerichtet, dass er über einen übergeordneten Proxy ins Internet kommt.
Dies habe ich mit der cache_peer Option eingestellt und das läuft auch wunderbar, solange ich keine SSL verschlüsselten Seiten (https://) aufrufe!
Dann taucht nämlich folgender Fehler im access.log, des Squids auf:

192.168.2.1 TCP_MISS/000 729 CONNECT banking.postbank.de:443 - DEFAULT_PARENT/192.168.2.20 -

Wenn ich also eine https-Seite aufrufe, bekomme ich im Client einen Servererror 500!

So sieht mein cache_peer-Eintrag aus:

cache_peer 192.168.2.20       parent    8080  0     proxy-only default no-query no-digest

Ich habe mal ein bisschen im Internet recherchiert und herausgefunden, dass die "never_direct allow all" Option eine wichtige Rolle spielt und habe ich sie auskommentiert!

Das hat mich aber leider nicht weitergebracht.

Wisst ihr weiter?

Gruß
Chribu

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 91947

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

Ausgedruckt am: 22.11.2024 um 13:11 Uhr

4 Kommentare

Neuester Kommentar

Hi,

meine Güte ist das lange her

, doch wenn ich mich recht erinnere, ist die Fehlerzeile oben keine Fehlerzeile. Er sagt halt nur, dass er nix im Cache hat und das deshalb an den Parent weitergibt.

In der Default-Einstellung des Squid sind ein paar ACL's gesetzt, die unter Umständen das Problem verursachen könnten. Schalte die doch mal ab und schau, was dann geht ...

Grüße Mathias

Morgen Mathias,

es lag doch nciht an meiner Konfiguration, sondern am Parentproxy

Es hat nämlich auf Anhieb mit einem anderen Parentproxy funktioniert!
-->Meine Konfiguration war also in Ordnung!

Jetzt habe ich aber ein anderes Problem:
Beim Starten von Squid, bekomme ich folgende Fehlermeldung ausgegeben:

cache_cf.cc(346) squid.conf:2710 unrecognized: 'broken_vary_encoding'

Der Proxy funktioniert aber trotzdem!
habe leider noch keine Lösung für diesen Fehler gefunden.

Vielleicht weist du ja weiter

Gruß
Chribu

Morsche,

hatte ich auch noch nicht, wenn ich aber die Quellen im Internet recht deute, dann hat das keine Bedeutung. Es dreht sich vorzugsweise um komprimierte Seiten, die der Squid nicht so recht interpretieren mag, weil sie Zeichen enthalten, die nicht RFC-konform sind. Ursache sind aber die Webserver, die die Seiten nicht als mit mod_gzip oder mod_deflate komprimiert kennzeichnen - Squid "bemerkt" diesen Lapsus und mault.

Gefunden habe ich auch, dass es wohl ab Squid 2.6 eine Option gibt, mit der das Caching dieser Daten abgeschaltet wird - eingesteuert über eine ACL:

\# TAG: broken_vary_encoding
\# Many servers have broken support for on-the-fly Content-Encoding,
\# returning the same ETag on both plain and gzip:ed variants.
\# Vary replies matching this access list will have the cache split
\# on the Accept-Encoding header of the request and not trusting the
\# ETag to be unique.
\#
\# Apache mod_gzip and mod_deflate known to be broken so don't trust
\# Apache to signal ETag correctly on such responses
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache

Wenn ich nun Deine Fehlermeldung richtig interpretiere, dann hast Du die Option gesetzt, obwohl Dein Squid die nicht kann - "unrecognized" bedeutet wohl "unerkannt" ...

Grüße Mathias