Datenreduzierung am Aux-Exit

[delphiN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Schönes neues Jahr euch Allen!

Wir haben an unserem, momentan einzigen Aux-Exit mitlerweile ein nicht
unwesentliches Traffik-Aufkommen. Im Dezember haben wir das vom
Provider genannte "Soft-Limit" von 20 TB/Monat bereits erreicht und
werden es im Januar voraussichtlich deutlich überschreiten. Wenn 1000
neue Flüchtlinge in Fürth dazukommen wirds spannend.

Ich habe den Provider kontaktiert und gefragt ob er mit dem wachsenden
Datenaufkommen klar kommt und ob das klar geht. Ich geh davon aus, das
wir hier noch etwas Luft haben.

Trotzdem sollten wir uns mal über Möglichkeiten unterhalten das
Datenaufkommen an dem Exit zu reduzieren. Ich sehe hier folgende
Möglichkeiten zur Diskussion:

1. P2P-Traffic verhindern
Es gibt das so genannte Zapp-Skript, das in der Lage ist typischen
P2P-Traffik zu erkennen und den entsprechenden Client für eine gewisse
zeit zu sperren. Ich bin ein erklärter Gegner von Torrent-Sperren da
damit auch legale Torrents (z.B. 32C3 Vorträge) gesperrt werden.
Trozdem finde ich man könnte sowas in diesem speziellen Fall von
Flüchtlingshilfe zumindest mal diskutieren. Die Abuse-Meldungen würden
wir zwar trotzdem noch bekommen aber der Traffik wäre weg.

2. P2P-Traffik umleiten
Wir könnten bereits an den Layer-2 Gateways ein policy-based-routing
installieren und zum Beispiel nur noch Daten von bekannten Ports (80,
443, 110, 143, 25 usw.)  über den dotManaged Gateway schicken. Alles
Andere könnten wir dann über einen normalen Schweden-VPN abwerfen.
Damit würde zwar Torrent und alle anderen seltsamen/unbekannten
Protokolle sehr langsam werden aber wir würden den Exit entlasten und
wären zusätzlich die Abuse-Meldungen los. Die fränkischen Gluon
Kollegen haben so ein Policy based Routing schon lange und damit wohl
auch sehr gute Erfahrungen gemacht.

3. Traffik-Control auf Client Ebene
Es wäre wahrscheinlich auch möglich eine Beschränkung der Datenrate
für die einzelnen Clients zu bauen. Wenn jeder Client nur noch eine
reduziere Datenrate zu Verfügung hat würde das das Gesamtaufkommen
wohl erstmal verringern. Das wäre technisch aber wohl ziemlich
kompliziert und ich finde wir sollten Nutzen was wir haben. Die
DSL-Anschlüsse sind doch sowieso schon Beschränkung genug.

4. Reverse cacheing
Da haben wir ja schon diskutiert. Es ist durchaus üblich Web-Traffic
in großem Stil (bei Beachtung von Regeln) zu cachen. Wir könnten uns
damit wahrscheinlich etwas an Port-80- und evtl. Port-23-Traffik
sparen. Da mittlerweile alle großen Anbieter aber SSL verwenden finde
ich das können wir uns sparen!

5. Neue Exit-Server
Wie schauts bei wavecon aus?
1und1 scheint tatsächlich unbeschränkten Traffik anzubieten und auch
Dinge wir Tor-Relays und sogar Exit-Nodes durchaus zuzulassen
(Zumindest bis es zu rechtlichen Problemen kommt). Bei denen scheint
der Engpass der Speicher und die CPU zu sein. Wenn man da im Rahmen
bleibt lassen die einem wohl auch großen Traffic durchgehen. Wir
könnten so einen Server evtl. auf den Namen des Fördervereins laufen
lassen und z.B. die Kosten selbst übernehmen. Hat das fra1 Team
nochmal Lust so ein Ding aufzusetzen? Die Kosten könnten wir uns ja
z.B. teilen oder aus dem Caritas-Topf bezahlen. Auch haben wir noch
viele viele Spenden.

Wie seht Ihr das?

Gruß,
delphiN

- -- 
Freifunk-Franken, Förderverein Freie Netzwerke e.V.
eMail: freifunk at wunschik.net
XMPP : delphiN at jabber.ccc.de

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJWh6ByAAoJEGuH2dOBPapC6Y4P/29nXrwlxx1jt5ktAcTJbjZz
RT/sjastLlyOExyz07b1smXcviCt5TIHSPSLaAnOZ8AS1lPVxXPSXTbesmtX4fcr
XAdPktDrRGw19rAbzJUrOOETvaKQV/jK7ykBFagCcLZom/brgU5Pj0WgLFAC2UOF
z4gqZAUCzd598XHbTFbOLbXRPPj0SqQT7KVEFpj0nE195CKL6/5/IM9va1OrRgBU
FYbJl6/CDu4GEGb6jDDu4tsnuw/xBfiCMB874xZkvFDNsjpUBs/VPSpzaD2ppWnV
RramsOiiZT642Ans45ifPrxEhatt+NSc+HH4Lcv252Vlvblyc3Z4ogo9bQ4BOPyq
nqhH6N5gQgFtqYRXQjlyGSTF/uaRD1qrmVuXSobXJqQbb/yAhY2gf3V0go2CzChV
CQE+h0BwpadKl8k14GJiGwH7XdjGd5NAAqBHBv/hSsPYgf4vq9DF6ba+f2yR0eF2
1DpHymOHxDSpUtDzEpyZNpTyPbLZSUOldp9icAjN+KTuF237S2XCu4Nk4Y/WWi2w
KIaKxc3XZTBeAgnE+O79E/NMi62yuD1MClum+1aba9xAWSlXfhJ51pmilRu0WpgW
AH/CAOITf2snFiqSNoMoe9YFdfnaru0rM/NPXR42oexW5V+KW53JJd+oiNU89Hyr
/TYBqWH7A+uKkR8t33sB
=4BgM
-----END PGP SIGNATURE-----