Datenreduzierung am Aux-Exit

Sa Jan 2 18:59:35 CET 2016

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

Am 02.01.2016 um 16:10 schrieb Tom Green:
> Hi,
> 
> wir können _versuchsweise_ kleev2 mit in die Aux als GW in die Aux 
> nehmen. Selbstabwurf über Mullvad. @Christian, Tim: Seit ihr so
> nett?

so nebenbei als Info, ich hab keinen Zugang zum keyxchange für diese
Sachen brauch ich also nicht erwähnt werden. Nur im Netmon kann ich
tun und walten... falls mal wieder was mesht was nicht meshen soll.

Ansonsten hoff ich das klee einiges an Traffic weg bringt, so richtig
schnell kam er mir in Fürth leider nie vor (oft nur um die 2-3Mbit) :(
Meiner ist mit Hetzneranbindung von Telekom (man google mal nur
Telekom Hetzner peering...) aber auch nicht besser (bestensfalls
15Mbit durch die starke Last aus nueland aber oft auch nur 2-5Mbit
drinnen weil dann irgendwann der Mullvad-VPN dicht macht so ab
30-40Mbit/sec im Mullvad wirds dünn und die erreich ich doch öfters
mal) und nue1 wirft teilweise über has2 weg welcher wiederrum auch nur
VPN hat und schon eigene Clients bedient.... Also Fürth ist zur Zeit
irgendwie etwas schief ich hab das seit ein paar Tagen schon im Auge
und mir gefällt die Entwicklung nicht so wirklich :/

mfg

Christian

> 
> Mal schauen was der abfischt, freie Kapazitäten wären da.
> 
> Im 2ten Schritt dann entweder * wieder aus der Aux raus (weil er
> zuwenig mithilft) * kleev2 aus Wü oder Fü raus * kleev2 bleibt in
> allen 3 Hoods
> 
> Ich denke das ist auch ein Problem, dass: * Flüchtlinge den ganzen
> Tag nichts anderes zu tun haben * Das GW einfach schnell ist
> 
> Man könnte jetzt auch Drosselkom spielen .... sprich ein QoS
> entweder global für fra1 auf 1 TByte pro Tag oder pro
> VPN-Verbindung (falls möglich). Auch keine populäre Maßnahme.
> 
> Gruß Torben
> 
> 
> On 02.01.2016 13:46, f.schimmer at posteo.de wrote:
>>> Ich persönlich glaube nicht, dass wir das Problem mittelfristig
>>> mit
> Umleiten oder Sperren von bestimmten Traffic oder Hinweisen lösen 
> können. Wir sollten schon reduzieren, wo es nur geht. Aber wenn ich
> mich vor Ort umschaue, ist das gefühlt ganz normaler Traffic auf
> youtube etc. Gegen p2p sprechen eigentlich auch die nächtlichen
> "Einbrüche". Um so mehr Personen wach sind, um so mehr wird
> übertragen. Mal raus-messen wäre trotzdem nicht schlecht. Sollte
> mit wireshark o.ä. ja recht schnell auf dem Gw gemacht sein. dito.
>>> Meiner Meinung nach haben wir aber ein anderes Problem: >  Wir
> schauen zwar vor Ort, wer die Router bezahlt, wer die Leitung
> stellt aber achten nicht auf die Betriebskosten im ff-netz.
> Außerdem ist das Erweitern der Kapazität mit Handarbeit verbunden
> und meist noch eine Individual-Installation. Beides führt dazu,
> dass wir in der aux genau von einem GW versorgt werden und wenn das
> down, oder der Traffic verbraucht ist, hunderte (wahrscheinlich
> langsam über 1000) Leute kein Internet mehr haben. Die Aux ist
> momentan n+1 sicher über bbg und fra1. Ansonsten Zustimmung bei den
> Betriebskosten.
> 
> 
>> Was wir meiner Meinung nach bräuchten, wär ein Projekt pro
>> Installation, bei dem auch sicher gestellt wird, dass die
>> Kapazitäten zur Verfügung stehen und diese auch über einen
>> bestimmten Zeitraum finanziert werden. Das würde dann aber auch
>> bedeuten, dass sich nicht jeder einfach ne aux - fw installieren
>> kann, ohne diese zu registrieren.
> 
>> Ich weiß, dass geht recht weit vom uneingeschränkt offenen Netz
>> weg, von selbst-organisation etc., und wird hier nicht bei allen
>> auf Begeisterung stoßen, ich sehe aber sonst keine wirkliche
>> alternative. > > Offenes Feedback willkommen :) > > Liebe Grüße,
>> > Flo > > > 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.
>> 
>> 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: christian 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

iQIcBAEBCAAGBQJWiBAHAAoJEOID5jPgWNLie1kP/iOvfmohbPBWjTrorD13JLv/
nA00Oao/E6y69WYYyJtvzV3nuQMMdAuPR+fD167Vn99sAcuSbrwpMTuYta734i3B
HFzxcWZ0mau78CaWrgMlb3qZHcuZh8DCwriGMkAPHW8LBigBtTsyBg0J/+KxQsCO
og9k+ttxpwIipzmeNvWvH9D8Y0bfqUxGYxyOjd9BE/zHKDKbTNS7Z1S6d68UPrKr
T/hDPQ39UV1hurg24QVwQ9lUiL12iKRod5UHzwErEV7TrjqjopdplvMelatJkgZU
N/WugKlrQLV+gy1G7QIA7aI9E+7tqwLgTxyrcevU40Id+MAm2e9F6TV8tABVrjV8
p1iWJnTLBeHSOnoWsd+fcyuAGI7dwKBHkBQr1NNuxffe+hNDzFNUg4MI106ofI7o
VQS2CfKo3t9Hl+2ubwmzXsM6vmmyc+224H+hLMkTg2QMgpR4EoJc4yXEm7WjHEwe
prqN/pGNV9i96oNfPXeK1WArRN1BcMLoCcUx1sRZEn49hQPYusEqHRKa4OUJGL81
IomT0UM4QiDSpAt7aSRiPXkusHhR+Dwj6GGdBguwLLgJVBBMY9Vauk8OTYZeLuwQ
yWrcQ/E22nAv+peI0YWDOS61MMmn6eiCUK2Tx5q5W5BmlMk781eaUxKkAWxS2xpy
6q1okMAzxckdOiyubjvu
=vBNy
-----END PGP SIGNATURE-----