<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    wir können <u>versuchsweise</u> kleev2 mit in die Aux als GW in die
    Aux nehmen. Selbstabwurf über Mullvad.<br>
    @Christian, Tim: Seit ihr so nett?<br>
    <br>
    Mal schauen was der abfischt, freie Kapazitäten wären da. <br>
    <br>
    Im 2ten Schritt dann entweder <br>
    * wieder aus der Aux raus (weil er zuwenig mithilft)<br>
    * kleev2 aus Wü oder Fü raus<br>
    * kleev2 bleibt in allen 3 Hoods<br>
    <br>
    Ich denke das ist auch ein Problem, dass:<br>
    * Flüchtlinge den ganzen Tag nichts anderes zu tun haben<br>
    * Das GW einfach schnell ist<br>
    <br>
    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.<br>
    <br>
    Gruß<br>
    Torben<br>
     <br>
    <br>
    On 02.01.2016 13:46, <a class="moz-txt-link-abbreviated" href="mailto:f.schimmer@posteo.de">f.schimmer@posteo.de</a> wrote:<br>
    <span style="white-space: pre;">
>
> 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.
</span><br>
    dito.<br>
    <span style="white-space: pre;">>
> 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.
<font color="#000000">Die Aux ist momentan n+1 sicher über bbg und fra1. </font>Ansonsten Zustimmung bei den Betriebskosten.
</span><br>
    <br>
    <br>
    <span style="white-space: pre;">> 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.

</span><br>
    <br>
    <span style="white-space: pre;">> 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:</span><br>
    <blockquote type="cite">Schönes neues Jahr euch Allen!<br>
      <br>
      Wir haben an unserem, momentan einzigen Aux-Exit mitlerweile ein
      nicht<br>
      unwesentliches Traffik-Aufkommen. Im Dezember haben wir das vom<br>
      Provider genannte "Soft-Limit" von 20 TB/Monat bereits erreicht
      und<br>
      werden es im Januar voraussichtlich deutlich überschreiten. Wenn
      1000<br>
      neue Flüchtlinge in Fürth dazukommen wirds spannend.<br>
      <br>
      Ich habe den Provider kontaktiert und gefragt ob er mit dem
      wachsenden<br>
      Datenaufkommen klar kommt und ob das klar geht. Ich geh davon aus,
      das<br>
      wir hier noch etwas Luft haben.<br>
      <br>
      Trotzdem sollten wir uns mal über Möglichkeiten unterhalten das<br>
      Datenaufkommen an dem Exit zu reduzieren. Ich sehe hier folgende<br>
      Möglichkeiten zur Diskussion:<br>
      <br>
      1. P2P-Traffic verhindern<br>
      Es gibt das so genannte Zapp-Skript, das in der Lage ist typischen<br>
      P2P-Traffik zu erkennen und den entsprechenden Client für eine
      gewisse<br>
      zeit zu sperren. Ich bin ein erklärter Gegner von Torrent-Sperren
      da<br>
      damit auch legale Torrents (z.B. 32C3 Vorträge) gesperrt werden.<br>
      Trozdem finde ich man könnte sowas in diesem speziellen Fall von<br>
      Flüchtlingshilfe zumindest mal diskutieren. Die Abuse-Meldungen
      würden<br>
      wir zwar trotzdem noch bekommen aber der Traffik wäre weg.<br>
      <br>
      2. P2P-Traffik umleiten<br>
      Wir könnten bereits an den Layer-2 Gateways ein
      policy-based-routing<br>
      installieren und zum Beispiel nur noch Daten von bekannten Ports
      (80,<br>
      443, 110, 143, 25 usw.)  über den dotManaged Gateway schicken.
      Alles<br>
      Andere könnten wir dann über einen normalen Schweden-VPN abwerfen.<br>
      Damit würde zwar Torrent und alle anderen seltsamen/unbekannten<br>
      Protokolle sehr langsam werden aber wir würden den Exit entlasten
      und<br>
      wären zusätzlich die Abuse-Meldungen los. Die fränkischen Gluon<br>
      Kollegen haben so ein Policy based Routing schon lange und damit
      wohl<br>
      auch sehr gute Erfahrungen gemacht.<br>
      <br>
      3. Traffik-Control auf Client Ebene<br>
      Es wäre wahrscheinlich auch möglich eine Beschränkung der
      Datenrate<br>
      für die einzelnen Clients zu bauen. Wenn jeder Client nur noch
      eine<br>
      reduziere Datenrate zu Verfügung hat würde das das Gesamtaufkommen<br>
      wohl erstmal verringern. Das wäre technisch aber wohl ziemlich<br>
      kompliziert und ich finde wir sollten Nutzen was wir haben. Die<br>
      DSL-Anschlüsse sind doch sowieso schon Beschränkung genug.<br>
      <br>
      4. Reverse cacheing<br>
      Da haben wir ja schon diskutiert. Es ist durchaus üblich
      Web-Traffic<br>
      in großem Stil (bei Beachtung von Regeln) zu cachen. Wir könnten
      uns<br>
      damit wahrscheinlich etwas an Port-80- und evtl. Port-23-Traffik<br>
      sparen. Da mittlerweile alle großen Anbieter aber SSL verwenden
      finde<br>
      ich das können wir uns sparen!<br>
      <br>
      5. Neue Exit-Server<br>
      Wie schauts bei wavecon aus?<br>
      1und1 scheint tatsächlich unbeschränkten Traffik anzubieten und
      auch<br>
      Dinge wir Tor-Relays und sogar Exit-Nodes durchaus zuzulassen<br>
      (Zumindest bis es zu rechtlichen Problemen kommt). Bei denen
      scheint<br>
      der Engpass der Speicher und die CPU zu sein. Wenn man da im
      Rahmen<br>
      bleibt lassen die einem wohl auch großen Traffic durchgehen. Wir<br>
      könnten so einen Server evtl. auf den Namen des Fördervereins
      laufen<br>
      lassen und z.B. die Kosten selbst übernehmen. Hat das fra1 Team<br>
      nochmal Lust so ein Ding aufzusetzen? Die Kosten könnten wir uns
      ja<br>
      z.B. teilen oder aus dem Caritas-Topf bezahlen. Auch haben wir
      noch<br>
      viele viele Spenden.<br>
      <br>
      Wie seht Ihr das?<br>
      <br>
      Gruß,<br>
      delphiN<br>
      <br>
    </blockquote>
    <br>
  </body>
</html>