[Berlin-wireless] [FFRL] Rheinufer komplett down

[Sven-Ola Tuecke]

Hallo NRW,

auf die Gefahr hin, mich in Eure Sachen einzumischen schreibe ich hier
trotzdem mal die Situation in Berlin auf.

Wie ihr vllt wisst, hatten wir früher so bis 2012 einen VPN-Server in
Slovenien, angeleiert mit Hilfe unserer Slovenischen Freifunker. Dann,
so ab Ende 2012 sind wir in Berlin gehäuft auf Verwaltungsdienststellen
zugegangen auf der Suche nach guten (öffentlich) Standorten. Im Gespräch
mit diesen Leuten ist uns ein paar mal vorgehalten worden: "Abwurf über
VPN ins Ausland? Das ist Umgehung deutschen Rechts. So machen wir da
nicht mit". Nun kann man sicher darüber streiten, inwieweit EU-Recht
bzw. die Rechtslage in anderen EU-Ländern hierzulande anerkannt wird.
Nützt nur nix, wenn man von der Gegenseite etwas will. Fazit: wir haben
unseren Server nach Berlin verlagert. Läuft jetzt auf eigener Hardware,
diese läuft bei einem befreundeten Community-kompatiblen Provider
(IN-Berlin) im Rack. Zeitgleich hat der hiesige "Förderverein freie
Netze e.V" bei der Bundesnetzagentur den Access-Provider-Status
bekanntgegeben und bestätigt erhalten.

Soweit die Ausgangslage. In Diskussionen mit unseren Rechtskundigen
(Jochen bzw. Reto) wurde aber schnell klar: Access-Provider ist nichts
auf dem man sich ausruhen kann. Zwar müssen wir nicht loggen (< 10.000
Kunden). Aber wir sind ein Sonderfall, weil wir keinerlei Registrierung
von Einzelnutzern betreiben. Man kann also bei uns ohne Anmeldung und
damit Anonym connectivity erhalten. Es wurde klar, dass wir diesen
Status nicht bis zuletzt ausreizen sollten / können / dürfen. Aus diesem
Grunde ist auf unserem VPN-Server ein -mmh- heuristisches Abuse-Handling
installiert. Nennt sich "Zapp-Script", das zählt im Prinzip
Verbindungen-zu-verschiedenen-externen-IPs pro DHCP-Kunde und klemmt bei
Überschreitung der voreingestellten Schwellwerte schlicht UDPv4 ab.
Damit noch etwas funktioniert wird im Zapp-Fall Port 53 (DNS) immer von
einem internen Dnsmasq beantwortet. Das ganze mit einem Timeout von (im
Mom.) 4 Stunden.

*** Weitere Erfahrungen / Änderungen im Laufe der Zeit ***

* Früher hatten wir da zudem eine Nervseite drin, die sich in den Port
80 einschleift und den Fakt "UDP abgeklemmt" kundtut. Irgendwann war die
Nervseite kaputt bzw. der Button [Jaja, gelesen, lass mich surfen]
funktionierte nicht immer. Darum hab' ich vor ca. 9 Monaten die
Nervseite stillgelegt. Das Zapp sperrt also UDP ohne 'rumzunerven. TCP,
ICMP, IGMP, GRE usw. laufen auch im Zapp-Fall weiter. Bis dahin hatte
ich mind. einmal pro Woche jemand in der Leitung der irgendwas
'rumheulte. Das hörte schlagartig auf und ich hab' die Nervseite
deswegen nicht wieder aktiviert und ich hab's auch nicht vor.

* Es gab Anfangs Probleme mit Skype. Das ist Fasttrack, also hohe
Verbindungszahlen. Nach dem Verkauf an Microsoft haben sie das
Supernode-Feature deaktiviert bzw. Skype-Supernodes sind heutzutage die
Server in Redmond. Und die haben einen IP-Range, der ist in einer
Ausname-Liste gelandet.

* Ich hatte einmal das Vergügen mit einem Gamer. Es gibt so
P2P-Gaming-Netzwerke, wo ebenfalls viele Verbindungen gleichzeitig zu
vielen unterschiedlichen (Player-) Rechnern aufgebaut werden. Hab ich
anfangs mit einer Ausname für den Intensivspieler geregelt. Später war
nicht mehr nötig, denn:

* Wir haben nicht genug Filesharing-Adressabfragen. Wissenschon: als
Access-Provider bekommt man Post. Im Prinzip die Abfrage der
zustellfähigen Postadresse aus der Kombi Externe-IP/Datum/Uhrzeit. Davon
schlägt nicht genug auf, also habe ich den Schwellwert immer höher
eingestellt. So alle 1/4 Jahr bissi mehr. Damit erledigt sich das
Gamer-Problem (siehe eins höher) von allein.

* Dann gab's noch Abuse-Mails zu Port 25. Es war schade, wenn die
externen IPs des VPN-Servers (derzeit 64) alle gesammelt in
irgendwelchen RBL's auftauchen. Wird wahrscheinlich eine Webseite, auf
der $Freifunka eine "ich habe einen SMTP-Server, bitte aufmachen"
manuell eintragen kann oder so. Das ist noch Todo, wer eine gute Lösung
hat: immer her damit.

* Ein weiterer positiver Effekt: Leute konfigurieren gerne (internes)
NATv4 aus 2 Gründen: es braucht keine Rückroute und es braucht keine im
Gesamt-Mesh eindeutigen IPv4-Adressen für DHCP. Diese Zapp-Geschichte
-mmh- fördert aber die Motivation, diese "Faulheits-NAT-Konfigs" gegen
bessere Lösungen wegzumachen. Schließschlich stolpern alle über NAT
zusammengefassten Leute über die Sperre und diese wird auch schneller
ausgelöst, wenn das 50 Leute über eine IPv4-Adresse beim VPN-Server
ankommen. Damit können wir zudem beim VPN-Server besser IPv4-Adressen
"mischen", eine externe IPv4 wird intern zeitgleich in Hintertupfingen,
Berlin und Sonstwo irgend einem DHCP-Benutzer zugeordnet und ist somit
nur in Echtzeit (also bei einer laufenden Datenübertragung)
zurückzuverfolgen.

* Achja. Zahlen. Derzeit gibts 92 Tunnel. Da sind viele
Kleinfreifunknetze dabei weil wir gerne auch mal Schlüssel für neu
hinzukommende Freifunk-Gruppen herausrücken. Und es waren in der letzten
Stunde 1176 unterschiedliche interne IPv4 in Benutzung. Abends ist mehr
los. Das sind jedenfall derzeit 18 interne IPv4 auf eine externe IPv4 -
ist noch ein gesundes Verhältnis. Davon sind in den letzten 4h 5
IP-Adressen über die Zapp-Geschichte gestolpert, haben also derzeit kein
UDP. Zwei davon sind "Dauerstoperer", haben also irgendwas seit Wochen
zu laufen was aus irgend einem Grund versucht da was durchzuprügeln. Ich
hab' zwischenzeitlich schon mal Zapps mit über 20.000 Bogopoints
gesehen, das entspricht einem DHCP-Benutzer der 5.000 verschiedene!
externe IP-Adressen gleichzeitig kontaktet. Soviele Firefox-Tabs gehen
sicher nicht, aber normalerweise Resetten bei sowas alle Router auf dem
Datenweg weil sie keinen Speicher mehr für Conntrack haben. Kein
Speicher == Brutalo-Zapp, es gibt immer Grenzen...

*** Mein Fazit ***

Die Diskussion um Dinge wie "was ist Neutral" und "welche Kompromisse"
hatten wir natürlich hier auch. Ich tippe aber mal, dass die
überwiegende Mehrheit der VPN-Benutzer (sowohl die
Tunnel-Endpunkt-Betreiber als auch die DHCP-Gelegenheitsnutzer) mit dem
derzeitigen Status leben kann. Wir VPN-Admins sicher auch, weil die
dauernde Filesharerei macht letztlich Arbeit: dauernd sucht man neue
Provider im In- und Ausland oder darf sich mit Abuse-Meldungen
'rumschlagen. Ausserdem werden rein funktechnisch $Leute beiseite
gedrückt, die halt nur mal eine Mail abfragen oder eben was im Netz
recherchieren wollen. Alles für ein paar Kiddies, die zu faul sind sich
ihren $Lieblingskram auf irgendwelchen File-Hoster-Portalen
zusammenzuklicken. Wer unbedingt über mit externen Sharen will braucht
halt sensible Einstellungen, nimmt IPv6 oder kauft sich für 5,-- ein
Token von irgend einem externen VPN-Anbieter um es darüber abzuwickeln
(Note: das ist genau eine externe Verbindung die natürlich nicht gezappt
wird).

Früher gab's auch öfter mal Post Kleinanbietern. Wissenschon, 3 Leute:
ein Seeder, ein Leecher, ein Inkasso, vornehmlich rosa Zeugs. Dagegen
ist eh kein (technisches) Kraut gewachsen, das sind ja genau 3 externe
IPs und die fallen auf diese Weise eh nicht auf. Ich vermute mal, das
die Vereins-Abfrageadresse (also da wo das Inkasso die zustellfähige
Postadresse einfordern muss) entweder auffällt (grep -v 'Freie Netze'),
die Adresse auf irgendeiner Blacklist steht oder schlicht sowieso nur
die großen DSL-Provider angegangen werden.

Achja. Nochwas vergessen. Wir hatten da noch die Lübecker. Deren interne
Diskussion ergab: sie wollen kein derartiges technisches Abuse-Handling
und hätten trotzdem gerne einen VPN-Server in DE. Mit dieser
Access-Provider-Geschichte dran. Haben aber gerade keinen Verein fertig.
Es gibt daher einen Server bei $Provider irgendwo in DE, der auf unseren
Verein freie Netze umgeschrieben wurde. Soweit ich sehen kann ist das
Dings aber noch nicht wirklich in Betrieb (Openvpn-Pool-File hat eine
IPv4). Erfahrungen dazu stehen also noch aus und wegen des Aufwands
(Verwaltungsaufwand nicht Technikaufwand) ist das vllt sowieso keine
flächendeckende Lösung.

Hoffentlich hilfts // Sven-Ola

Am 24.05.2014 09:39, schrieb Peter Schmelzer:
> Hallo zusammn,
> ich habe meine Meinung als Privatperson kundgetan und nicht als
> (Noch-)Mitglied des FFRL Vorstandes.
>
> Ich finde es erschreckend wie engstirnig und ohne Weitblick so manch
> einer der hier schreibt.
>
> Gibt es eine Reglementierung innerhalb des Freifunk Netzes? Antwort: NEIN
> Also ist Freifunk bei FFRL auch frei.
>
> Der Internet Zugang ist ein Goodie und muss nicht zwingend zur
> Verfügung gestellt werden.
>
> Daher besteht aus MEINER Sicht der Dinge auch der Bedarf illegale
> Dinge zu unterbinden, da diese weder etwas mit Netzneutralität noch
> mit Anstand zu tun haben. Das dabei ehrliche P2P Sharer gekappt werden
> ist ein leider zu ertragendes übel.Sie können ja immer noch innerhalb
> des Netzes P2P betreiben.
>
> Und für alle die die sich Netzneutralität auf die Fahne geschrieben
> haben hier nochmal der Link zum Handbuch für Netzneutralität:
> https://digitalegesellschaft.de/wp-content/uploads/2012/12/DG_Handbuch_Netzneutralit%C3%A4t.pdf
>
>
> Tschö
>
>
> Am 24. Mai 2014 08:57 schrieb Torsten Schlabach (PCC)
> <torstens at panorama-computer-club.de
> <mailto:torstens at panorama-computer-club.de>>:
>
>     Hallo!
>
>     Eigentlich habe ich relativ wenig Lust mich an solchen Diskussionen zu
>     beteiligen, aber wenn ich lese:
>
>     > These: Der FFRL sieht die Notwendigkeit zu Nutzung von
>     P2P-Blockern ein.
>     > Dies impliziert deren Wirksamkeit. P2P-Traffic muss grundsätzlich
>     > gefiltert werden, da er illegal ist.
>
>     dann geht mir doch die Hutschnur hoch.
>
>     Illegal kann kaum eine bestimmte technische Form von Traffic sein,
>     sondern
>     wohl maximal die damit transportieren Inhalte.
>
>     Umgekehrt kann man auch prima Inhalte die gegen diverse Gesetzte
>     verstossen (Uhrheberrecht, Jugendschutz, usw.) über traditionelle
>     Protokolle übertragen.
>
>     Auch Überlast bekomme ich ganz prima ohne P2P hin, mit ganz
>     normalen FTP-
>     oder HTTP-Downloads.. Bzw. stellen bestimmte andere P2P-Dienste
>     (z.B. ein
>     Chat) kaum eine Belastung für den Backbone dar.
>
>     Gruß
>     Torsten
>
>     P.S.: Wofür steht nochmal das "frei" in Freifunk? Speech oder beer?
>
>
>
>     On Fri, 23 May 2014 23:21:24 +0200, Jan Lühr <ff at jluehr.de
>     <mailto:ff at jluehr.de>> wrote:
>     > Hallo,
>     >
>     >
>     > Am 05/23/2014 03:54 PM, schrieb Peter Schmelzer:
>     >> Das Problem geistert hier seit Wochen rum.
>     >> Solange man "Netzneutralität" mit der Billigung illegaler
>     Filesharing
>     >> Aktivitäten gleichsetzt braucht man auch nicht rumzuheulen das die
>     >> Server abgeschaltet wurden.
>     >
>     >> Da der Wunsch des Vorstandes nach der Installation
>     entsprechender P2P
>     >> Filter wegen der "Netzneutralität" nicht durchgeführt wurde war das
>     >> Ergebnis klar.
>     >
>     > -v bitte. Ein paar Fragen dazu:
>     >
>     > -> Welche strafrechtliche Relevanz haben P2P-Blocker in
>     Freifunk-Netzen?
>     > In wie weit verstoßen Sie gegen das Fernmeldegeheimnis?
>     (Unterdrücken
>     > von Nachrichten?).
>     > -> In welcher rechtlichen Position sieht sich der FFRL, wenn er - im
>     > Gegensatz zu vielen anderen ISP - aktiv P2P-Filter einsetzt? Ist der
>     > FFRL ein ISP?
>     > -> Welche politische Position vertritt der FFRL in Bezug auf die
>     Haftung
>     > von Inhaltsanbietern, wenn er sich zur Installation von P2P-Filtern
>     > verpflichtet fühlt?
>     > These: Der FFRL sieht die Notwendigkeit zu Nutzung von
>     P2P-Blockern ein.
>     > Dies impliziert deren Wirksamkeit. P2P-Traffic muss grundsätzlich
>     > gefiltert werden, da er illegal ist.
>     >
>     > Ich bitte hier um Aufklärung!
>     >
>     > Ich finde es grundsätzlich "ok", TCP-Verbindungen in Freifunk-Netzen
>     > einzuschränken, da viele TCP-Verbindugen (etwa von P2P-Programmen)
>     > schnell zu unfairen Überlast-Situationen führen können.
>     >
>     > Gruß, Jan
>     >
>     > _______________________________________________
>     > Hauptmailingliste des Freifunk Rheinland e.V.
>     > FFRL at mailman.freifunk-rheinland.net
>     <mailto:FFRL at mailman.freifunk-rheinland.net>
>     > https://mailman.freifunk-rheinland.net/listinfo/ffrl
>
>     --
>     Herzliche Grüße
>     Torsten Schlabach
>     2. Vorsizender
>     Chemische Verbindung 77 e.V.
>     Arbeitsgruppe Panorama Computer Club
>     _______________________________________________
>     Hauptmailingliste des Freifunk Rheinland e.V.
>     FFRL at mailman.freifunk-rheinland.net
>     <mailto:FFRL at mailman.freifunk-rheinland.net>
>     https://mailman.freifunk-rheinland.net/listinfo/ffrl
>
>
>
>
> _______________________________________________
> Hauptmailingliste des Freifunk Rheinland e.V.
> FFRL at mailman.freifunk-rheinland.net
> https://mailman.freifunk-rheinland.net/listinfo/ffrl

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140524/77ffbe8b/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 263 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140524/77ffbe8b/attachment.pgp>