Es gibt mittlerweile recht viele Möglichkeiten dem geneigten Endanwender einen Proxy aufzuzwängen. Der klassische Weg ist ihm die IP-Adresse und den Port mitzuteilen. Damit kann man niemanden mehr beeindrucken.
Man kann auch per WPAD versuchen einen Proxy zu verteilen. Funktioniert leider so gut wie nie.
Oder man erklärt den Proxy gleichzeitig zum Router und bastelt mittels iptables o. ä. Tools ein Portredirect und schleift sämtlichen Verkehr über diesen Server.
Oder eine .pac-Datei, oder, oder oder.
Was ich für kleinere Netze interessant finde ist Cisco’s Web Cache Communication Protocol, nerdig als WCCP bezeichnet. Wenn der Proxy das Protokoll unterstützt klemmt man diesen per WCCP an eine Cisco ASA (oder wahlweise an einen Cisco Router der ebenfalls WCCP versteht) und schon fließt der Verkehr ohne Endanwenderinteraktion über den Proxy. Das klingt so fantastisch und riecht nach Marketing, das kann nicht so einfach funktionieren. Natürlich nicht!
-
Das Netz für WCCP benötigt die “höchste” IP-Range. Geniale Definition. Was meint man damit nur? Das IP-Oktett mit der höchten Zahl gewinnt. Hat man 10.10.10.0/24 und führt plötzlich 192.168.0.0/24 ein, geht WCCP nur für das 192er Netz. Klar? Ein 192.168.2.0/24 gewinnt gegenüber 192.168.0.0. Sauber. Besonders weil es im Netz Kommentare wie “du musst allen Verkehr zum Netz mit der höchsten IP routen”. Leider fehlt überall die Erklärung wie man das macht.
-
Zwischen ASA und Proxy muss ein GRE-Tunnel aufgebaut sein. Macht Sinn, da die Pakete möglichst unverändert zum Proxy sollen. Keine Bange, auf der ASA muss nichts konfiguriert werden, die macht das alleine. Auf dem Proxy muss der Tunnel eingerichtet werden. GRE-Allergiker aufgepasst, ohne geht es nicht.
-
Der Proxy muss auf der ASA freigeschaltet sein, sonst wandern seine Pakete auch in den GRE-Tunnel und es passiert ein Hauch von… nichts.
Als Proxy kommt ein Squid zum Einsatz.
Konfiguration
Squid
Die /etc/squid3/squid.conf wird um die folgenden Einträge erweitert:
1
2
3
4
5
wccp2_router 192.168.0.254
wccp_version 4
wccp2_forwarding_method gre
wccp2_return_method gre
wccp2_service standard 0
Der Proxy kann mittels squid3 -k reconfigure dazu bewegt werden, seine Konfiguration neu einzulesen.
GRE-Tunnel
ASA und Squid kommunizieren über einen GRE Tunnel miteinander. Dieser kann folgendermaßen eingerichtet werden:
1
2
3
4
5
6
7
8
9
10
11
modprobe ip_gre
/sbin/ip tunnel add wccp0 mode gre remote 192.168.0.254 local 192.168.0.253 dev eth0
/sbin/ip addr add 192.168.0.253/32 dev wccp0
/sbin/ip link set wccp0 up
/bin/echo 0 >/proc/sys/net/ipv4/conf/wccp0/rp_filter
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A PREROUTING -i wccp0 -p tcp -j DNAT --to-destination 192.168.0.253:3128
ASA
Auf der ASA muss eine Regel für WCCP eingerichtet werden. Hier muss der Proxy ausgeschlossen werden, damit er in Richtung extern kommunizieren kann. Die Clients werden gezwungen über den Proxy zu surfen.
1
2
3
access-list proxy-servers extended permit ip host 192.168.0.253 any
access-list proxy-clients extended deny ip host 192.168.0.253 any
access-list proxy-clients extended permit ip 192.168.0.0 255.255.255.0 any
Jetzt wird WCCP aktivert.
1
2
wccp web-cache redirect-list proxy-clients group-list proxy-servers
wccp interface wlanadfree web-cache redirect in
Mittels sh wccp kann geprüft werden, ob alles funktioniert. Mehr ist es nicht. Kann jeder selber nachdenken, ob er dieses Feature benötigt oder nicht.