expertenaustausch > comm.software.* > comm.software.webserver

Andreas M. Kirchwitz (27.05.2016, 13:16)
Hallo Apache-Freunde!

Einen aktuellen Apache HTTP-Daemon 2.4 würde ich gern gelegentlich
als schlichten Forwarding Proxy einsetzen. Der Dienst läuft sowieso,
wodurch ich mir extra Software wie Squid sparen könnte.

Laut gibt
es wenig zu konfigurieren. Passende Module sind geladen. So sieht's
testweise aus:

ProxyRequests On
ProxyVia Block
ProxyAddHeaders Off

Ausprobiert mit Firefox und funktioniert grundsätzlich prima, *aber*
natürlich würde ich hier nicht schreiben, wenn es nicht doch ein
Problem gäbe. :-)

Gelegentlich scheinen einzelne Requests vom Client verloren zu
gehen oder nicht korrekt beantwortet zu werden. Man sieht dann
im Browser, dass irgendwas "fehlt". Es tritt sporadisch (selten)
auf und macht Debugging kaum möglich (stundenlang Wireshark
mitlaufen lassen ist keine echte Option, ist sowieso alles https).
Logfiles geben auf den ersten Blick keinen Aufschluss.

Meine Vermutung ist, dass Apache HTTPD kein perfektes Handling
der Verbindungen zum Zielserver macht bzw. Probleme nicht korrekt
an den Client weitergibt.

Mit Squid gibt es keine solchen Probleme.

Hat jemand vielleicht ähnliches erlebt und kann Tipps geben?
mod_proxy sieht kaum Konfiguration vor. Die wenigen Einstellungen
scheinen mir am besten auf den Defaults zu bleiben).

Im Web konnte ich für das Fehlerbild bisher nichts finden.

Grüße, Andreas
Sven Hartge (27.05.2016, 15:53)
Andreas M. Kirchwitz <amk> wrote:

> Einen aktuellen Apache HTTP-Daemon 2.4 würde ich gern gelegentlich
> als schlichten Forwarding Proxy einsetzen. Der Dienst läuft sowieso,
> wodurch ich mir extra Software wie Squid sparen könnte.


Suboptimal. mod_proxy ist eher als Frontend für Dinge wie Tomcat o.ä.
gedacht, weniger als allgemeiner Proxy wie Squid.

Daher wundert es mich nicht, dass du hier Probleme hast.

Ich würde daher dennoch einen Squid als extra Service laufen lassen,
aber einfach den Platten-Cache abstellen und den RAM-Cache auf ein
Minimum reduzieren. Caching für HTTP ist eh tot, da nahezu alles
dynamischer Content ist.

Andreas M. Kirchwitz (27.05.2016, 18:23)
Sven Hartge <sh-165> wrote:

> Suboptimal. mod_proxy ist eher als Frontend für Dinge wie Tomcat o.ä.
> gedacht, weniger als allgemeiner Proxy wie Squid.
> Daher wundert es mich nicht, dass du hier Probleme hast.


Die meisten verwenden mod_proxy wohl eher als Reverse Proxy,
und vielleicht ist der Forward Proxy nur ein "Abfallprodukt".
Die magere Funktionalität hätte mir aber völlig gereicht. :-)

> Ich würde daher dennoch einen Squid als extra Service laufen lassen,
> aber einfach den Platten-Cache abstellen und den RAM-Cache auf ein
> Minimum reduzieren. Caching für HTTP ist eh tot, da nahezu alles
> dynamischer Content ist.


Squid verwende ich derzeit bereits so, wie Du es beschreibst,
jedoch ist Squid ein Schwergewicht. Das meine ich nicht abwertend,
sondern Squid kann eben viel. Compilieren dauert aber lange. Support
für RedHat/CentOS 6 wurde aufgegeben. So geht's nicht ewig weiter...

Alternative Proxy-Software (auch wenn man SOCKS einbezieht)
gibt es zwar einige, doch die ist wahlweise vor Jahren von den
Autoren aufgegeben worden oder kennt keine oder höchstens
IP-basierte Zugriffskontrolle für Clients.

Habe auch schon an schlichten SOCKS-Proxy via SSH gedacht, doch
das ist nicht jeder Software bzw. jedem Gerät ohne weiteres
beizubringen. Die zusätzliche (unnötige) Verschlüsselung ist
zudem nicht sinnvoll. Hingegen einen HTTP(S)-Proxy zu setzen,
das geht praktisch überall problemlos.

Grüße, Andreas
Sven Hartge (27.05.2016, 18:40)
Andreas M. Kirchwitz <amk> wrote:
> Sven Hartge <sh-165> wrote:


>> Suboptimal. mod_proxy ist eher als Frontend für Dinge wie Tomcat o.ä.
>> gedacht, weniger als allgemeiner Proxy wie Squid.
>> Daher wundert es mich nicht, dass du hier Probleme hast.


> Die meisten verwenden mod_proxy wohl eher als Reverse Proxy,
> und vielleicht ist der Forward Proxy nur ein "Abfallprodukt".


Ich für meinen Teil (mit dem NetSec-Hut auf dem Kopf) wäre mehr als
froh, wenn die Funktion "ProxyRequests On" ersatzlos gestrichen würde.

Ich habe schon zu viele Systeme gehabt, bei denen der Admin dies
eingeschaltet hatte (weil irgendein verblendetes HOWTO das so schrobte)
und der komplette Webserver dann zum offenen HTTP-Proxy wurde.

> Squid verwende ich derzeit bereits so, wie Du es beschreibst, jedoch
> ist Squid ein Schwergewicht. Das meine ich nicht abwertend, sondern
> Squid kann eben viel. Compilieren dauert aber lange. Support für
> RedHat/CentOS 6 wurde aufgegeben. So geht's nicht ewig weiter...


Wie wäre es mit Tinyproxy?
Das wird noch aktuell gepflegt, ist via EPEL verfügbar oder schnell
selbst kompiliert.

Cachen kann das Ding nicht, aber das funktioniert im aktuellen Web eh
nicht mehr, ist also IMHO kein Verlust.

Andreas M. Kirchwitz (28.05.2016, 00:47)
Sven Hartge <sh-165> wrote:

> Wie wäre es mit Tinyproxy?
> Das wird noch aktuell gepflegt, ist via EPEL verfügbar oder schnell
> selbst kompiliert.


Wäre schick, wenn es auch Authentifizierung mit Username/Passwort
erlauben würde. Das ist der Knackpunkt, weshalb leider nur Squid
und mod_proxy übrig bleiben.

Grüße, Andreas
Sven Hartge (28.05.2016, 15:13)
Andreas M. Kirchwitz <amk> wrote:
> Sven Hartge <sh-165> wrote:



> Wäre schick, wenn es auch Authentifizierung mit Username/Passwort
> erlauben würde. Das ist der Knackpunkt, weshalb leider nur Squid und
> mod_proxy übrig bleiben.


Ah, die Anfordernung fehlte noch.

Ja, dann: Squid. Bleibt leider nichts anderes mehr übrig. Saurer Apfel
und so, wissen schon.

Ähnliche Themen