Ad-block und Data Compression Proxy für UMTS- oder langsame Verbindungen

Vorwort

Im Folgenden beschreibe ich, wie ein Ad-block und Data Compression Proxy aufgesetzt werden kann. Dieser Beitrag ist unserer kleinen Tochter gewidmet, die mich gewissermaßen erst auf diese Idee gebracht hat. Ich liebe dich!

Einleitung

Wer wie ich beruflich häufiger unterwegs ist, übernachtet nicht selten in Hotels, deren Internetzugänge Modem-Verbindungen gleichen oder im ungünstigsten Falle schlicht nicht vorhanden sind. Seitdem es bezahlbare UMTS-Tarife und Smartphones gibt, liegt die Lösung auf der Hand: Tethering – das Smartphone wird mit dem PC verbunden, der dann dessen Internetverbindung nutzt. Allerdings hat diese Sache einen kleinen Haken, da die Datentarife beschränkt sind, oft auf magere 250 oder 500 MB Traffic pro Monat. Um diesem Umstand entgegen zu wirken, möchte ich eine Kombination aus Data Compression Proxy und Ad-Blocker bauen. Zum Einsatz kommen SQUID als Caching Proxy, ziproxy zur Kompression der Daten und privoxy zum Filtern von unerwünschter Werbung.

Hilfreich ist dies natürlich auch bei langsamen Netzwerkverbindungen, so z.B. in mobilen Netzgebieten, die nicht per UMTS abgedeckt sind oder schlichtweg bei dünnen DSL-Leitungen.

Voraussetzung ist, dass man irgendwo Zugriff auf einen Server mit passabler Bandbreite hat, der die Daten bereitstellen kann.

Pakete

Zunächst benötigen wir ein paar Pakete.

Die Konfiguration der einzelnen Komponenten werden im Folgenden beschrieben.

Konfiguration SQUID

Da bei mir bereits ein SQUID läuft und es neben der großartigen Dokumentation zahlreiche gute Tutorials zur Konfiguration gibt, verzichte ich auf detaillierte Erläuterungen und setze eine Grundkonfiguration voraus.  Sofern diese nicht bereits erfolgt ist sei in erster Linie auf die Dokumentation verwiesen, die keine Fragen offen lassen dürfte. Anpassungen für den Betrieb mit privoxy und ziproxy sind weiter unten beschrieben.

Zugriff auf den Proxy

Auch hier möchte ich nicht näher ins Detail gehen. Voraussetzung ist natürlich, dass der Proxy auch erreichbar ist. Viele Wege führen nach Rom. Meine beiden favorisierten Wege sind SSH-Tunnel mit Putty oder gleich eine VPN-Lösung. Falls Bedarf besteht, kann ich hier gern mal einen Beitrag erstellen, dann einfach einen entsprechenden Kommentar hinterlassen.

Privoxy

Privoxy läuft standardmäßig unter Port 8118. SQUID müssen wir nun so anpassen, dass der Proxy alle Anfragen an privoxy weiterleitet, wir passen in /etc/squid/squid.conf folgendes an:

Nach einem Neustart von SQUID kann hier schonmal rudimentär geprüft werden, ob SQUID mit privoxy arbeitet.

Optional kann noch die Action set-image-blocker auf „blank“ gestellt werden, damit werden Werbebilder „ausgeblendet“ (1x1px großes Bild) anstatt sie durch eine 4x4px großes sichtbares Bild zu ersetzen.  Hierzu ist /etc/privoxy/default.action anzupassen. Zu suchen sind die Zeilen:

Sie werden ersetzt durch:

Danach ist privoxy neuzustarten.

 Ziproxy

Im nächsten Schritt wird die Konfiguration so erweitert, dass neben dem Filtern der Werbung nun auch noch eine Komprimierung der Daten durchgeführt wird. Ziproxy kommt ins Spiel. Die Idee ist, dass wir nun SQUID anweisen, zunächst an ziproxy weiterzuleiten. Die Anpassung von vorher ändern wir daher auf Port 8080 ab, die ist der Standard-Port, auf dem ziproxy lauscht. Wir ändern also

um in

und starten SQUID wieder neu (/etc/init.d/squid restart). Ziproxy soll nun seine Anfragen künftig an privoxy weiterleiten. Wir passen folgende Zeilen in /etc/ziproxy/ziproxy.conf an:

Jetzt muss ziproxy neugestartet werden, anschließend kann ein Test beginnen.

Fehleranalyse

Ich empfehle, Schritt für jede Komponente zunächst einzurichten und dann auch einzeln zu testen. Angefangen bei SQUID. Sofern es zu Fehlern kommt, ist dann schon einzugrenzen, wo diese Fehler auftreten. Funktioniert eine Komponente, kann mit der Einbindung der nächsten begonnen werden.

Grundsätzlich sollte in allen Konfigurationsdateien entweder mit localhost oder 127.0.0.1 gearbeitet werden. Je nach DNS-Konfiguration muss localhost nicht zwingen nach 127.0.0.1 auflösen.

Noch eine Anmerkung zu SQUID: Eigentlich ist es klar, gerne vergisst man es aber im Eifer des Gefechts. Wer SQUID als Caching Proxy konfiguriert hat, darf sich nicht wundern, dass die Änderungen scheinbar keinen Effekt haben. Grund könnte hier sein, dass SQUID nicht ohne Werbung und mit komprimierten Bildern ausliefert, weil er direkt aus dem Cache bedient. Dann entweder den Cache neu aufbauen oder beim Aktualisieren <STRG>+<F5> (abhängig vom Browser) ganz neu anfordern.

Raspberry Pi

Noch ein paar Gedanken, da ich in letzter Zeit auch gerne mal mit dem Pi spielen… Vom Grundsatz her läuft solche ein Proxy auch auf dem Raspberry Pi. Einzig die Performance bei der Komprimierung der Bilder könnte ein wenig die User Experience in Mitleidenschaft ziehen. Wer Zeit und Lust hat, kanns ja mal ausprobieren und mir hier sein Feedback geben. Have fun!

3 Gedanken zu „Ad-block und Data Compression Proxy für UMTS- oder langsame Verbindungen“

  1. Hallo,

    die Idee finde ich ganz gut und habe sie etwas schlanker umgesetzt in dem ich auf den SQUID verzichtet habe.

    Aber auch ohne dessen caching habe ich eine erhebliche Beschleunigung beim Browsen festgestellt 🙂

    Was mich jedoch nun noch interessieren würde, da ich weder tiefergehende Proxy und Linux erfahrungen habe, geht das ganze auch als transparenter Proxy? Wenn wie?
    Und wie sieht das ganze Konstrukt bezüglich https aus? Den immer mehr Seiten sind standardmässig https bzw. werden auch bei der Suchmachinen als Ergebnis bevorzogt!

    1. Hallo und danke für das Feedback!

      SQUID: Je nachdem in welcher Reihenfolge das Ganze betrieben wird, sollte SQUID den bereits komprimierten Inhalt cachen können und damit die CPU schonen (keine erneute Kompression erforderlich), zumindest theoretisch, das müsste man mal ausprobieren.

      Transparenter Proxy: Eine Möglichkeit, besteht darin, den Verkehr per Firewall-Redirect der Ports 80, 443 und was auch immer sonst noch über den Proxy laufen soll, auf den Proxy umzuleiten. Entsprechende Tutorials findest du im Internet.

      Zu HTTPS: ein gängiges Verfahren besteht darin, eine Art „MITM-Attacke“ simulieren. Die HTTPS-Anfrage wird dabei auch über einen Proxy geleitet. Dort wird zur Laufzeit ein zur aufgerufenen URL passendes Zertifikat generiert, und zwar mit der eigenen CA (damit der Browser nicht meckert, wird diese CA in die Liste der vertrauenswürdigen Stammzertifizierungsstellen aufgenommen). Der Proxy seinerseits ist damit in der Lage, den Verkehr zwischen Client und Proxy zu entschlüsseln. Er baut seinerseits dann eine separate Verbindung per HTTPS an das eigentliche Ziel auf. Da der Proxy den Aufruf selbst aufgebaut hat, kann er das Ergebnis selbstverständlich ebenfalls entschlüsseln, den Inhalt verarbeiten (zwischenspeichern, AV- / Contentprüfung, Kompression, etc.) und an den Client weitergeben. Bessere Firewalls und Security-Appliances können das in der Regel leisten. mitmproxy ist hier ein Kandidat, den man sich näher ansehen kann, allerdings sind hier ein paar Grundkenntnisse in Sachen Linux sicher nicht schädlich.

  2. Die Performance reicht bei einem nicht übertakteten Raspberry Pi für einen einzigen Nutzer gerade noch so aus, bei mehreren simultanen Verbindungen ist sie jedoch deutlich limitiert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.