Datenreduzierung am Aux-Exit

[f.schimmer at posteo.de]

Am 02.01.2016 11:03 schrieb 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.

Bin hier noch zufällig drüber gestolpert: 
https://wiki.freifunk.net/P2pblock
Sollte dann also auch nicht so "böse" sein, den p2p traffic zu 
unterbinden.

> 
> 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-----