Datenreduzierung am Aux-Exit

Christian Dresel fff at chrisi01.de
Sa Jan 9 09:50:21 CET 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Am 08.01.2016 um 23:04 schrieb f.schimmer at posteo.de:
> 
> Am 02.01.2016 11:03 schrieb delphiN: 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.

1. Freier Transit

* Der Eigentümer bestätigt, freien Transit über seine freie
Netzwerkinfrastruktur anzubieten.
* Der Eigentümer bestätigt, die Daten, die seine freie
Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen,
noch zu verändern.

Quelle: https://wiki.freifunk-franken.de/w/PicoPeeringAgreement

In meinen Augen werden beide Punkte damit missachtet

mfg

Christian

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

- -- 
Kontaktmöglichkeiten ChristianD (Christian Dresel):
Jabber: ChristianD at jabber.community
E-Mail: fff at chrisi01.de
Facebook: https://www.facebook.com/christian.chili
Handy/Whatsapp & Festnetz: auf Nachfrage
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWkMnNAAoJEOID5jPgWNLiok0P/A1JakLXn68NFNjxzvG1I+8/
iGCMkJCB01d0x4Hvt+o0xo2gOXm2A5C5J37zZpN7KjH0WWcgbCbFZnnWqoHHxl4k
tqFFRfen3Qw3IcUBbfGxfuozciGk9oYYvVIagtwh7pX0ZeGKFvgIX7ilhinTXXFg
QY4BxJ8kFgc68q9JY3wL2suK5L2pRKY5TJJ8BwZl6qMPk5kSPA0rYw2Yf0Nw3C2M
UArpWEdsqxvJsiKZP1UKmZEyG2Z7LEpy8g+OLm64zr/epxlayixnBNM0ykXtV5+y
6X8s9jZJC1ix9PturPjd4ejBk927LcX472fyyTUyxubYHl3YA2ZS5AvUj6I+hD1Q
oS9cEiPD/JYrbMxZJtZrB8DIkFL2dCtiG3K33SW71BPtAtKCk//JOIN7JzokorgZ
2zk2gq7D+cWr+BrZR/Ami2R1iG2xNWs0BFzZ2u/7n1MchlLuqYysRylqdNOopT4r
Ec952OwkZTAmaFvxhOmYTwTpBHA0lDQ6Pc0rD2K3i08ZN2a0LvrB6x0ClGX0lUFi
IpqnlHlKeyf5O849N2Aop0rNCwOjj6mP7x1/8IZanMhJcQJkzObo3xqaWV1DgFw6
JlUz8bQXwpCHDo/zb1lT8e4voG7I8bcI8r8idjE2jZirb72VSIumUlC1ecw0bdTw
/Q1jW29GHcuoQp69B1Zs
=xFd6
-----END PGP SIGNATURE-----



Mehr Informationen über die Mailingliste franken-dev