[Berlin-wireless] puppets für community tunnel - wo sind die Puppenspieler?

[Holger]

Der thread ist eingeschlafen aber das Thema nicht. Nach wie vor segeln 
wir mit den community-Servern im Blindflug, keine Auslastung, Durchsatz etc.

Vereins-vpn03 ist seit Sonntag abgeschaltet, da könnten wir mal in die 
Pötte kommen.

Welche Vorschläge habt Ihr?

cheerio Holger


Am 02.04.2018 um 14:14 schrieb Nicco Kunzmann (gmx):
> Hallo,
> 
> ich hatte mal die Idee, einen Docker-Container als VPN-Server zu bauen,
> den man sehr schnell aufsetzen kann.
> https://github.com/niccokunzmann/decentral-community-vpn/
> 
>    * Man kann schnell einen eigenen Server aufbauen, wenn man möchte.
>    * Damit man allen Freifunkern erlauben kann, sich zu verbinden, werden
>      die öffentlichen Schlüssel auf GitHub verwaltet.
>    * Der Server kann diese Optionen ein-/ausschalten:
>        o Weiterleitung nach 0.0.0.0
>        o OLSR-Meshing über den Server
> 
> Damit könnte die Community, wenn die Server mal ausfallen sollten,
> schnell eigene Instanzen erstellen bzw.
> können diese über andere Vereine und Institutionen bzw. zu Hause laufen,
> wenn die wollen, wobei die Zertifikatvergabe weiterhin funktioniert und
> nur neue VPN-Verbindungen auf den Routern hinzugefügt werden müssen.
> 
> 
> Was denkt ihr darüber?
> 
> Viele Grüße,
> Nicco
> 
> On 04/02/2018 01:40 PM, Harald Stürzebecher wrote:
>> Hallo Sven
>>
>> Am 1. April 2018 um 20:50 schrieb Sven Röllig
>> <roellig at stiftung-freie-software.org>:
>>> Hallo,
>>>
>>> was für einen Sinn soll das Provisonieren mir Puppet machen?
>>>
>>> Sollen da Hunderte Maschinen mit Aufgesetzt werden?
>>>
>>> Reicht es nicht ein GIT Repo zu haben wo die Konfigurationen
>>> als Templates liegen?
>>>
>>> Soviel muss an der Konfiguration nun doch nicht geschraubt werden.
>> VPN03 waren AFAICT ungefähr (a-g?) sieben Maschinen. Für den
>> Community-Tunnel sehe ich mittelfristig ähnliche Anforderungen - zwar
>> weniger User, aber dafür mehr Traffic je User. Das wird sich eventuell
>> ausgleichen, mit geringerem Bedarf rechne ich jedenfalls nicht. Bei
>> der Anzahl von Geräten könnte sich IMHO eine zuverlässige
>> Automatisierung schon lohnen, z.B. um "mal eben" einen weiteren Server
>> einzurichten. Oder um eine einheitliche und dokumentierte
>> Konfiguration aller Instanzen sicherzustellen. Wenn hier und da mal
>> ein Admin über ssh herumbastelt, läuft das AFAICT sehr schnell
>> auseinander.
>>
>>> Die Hetzner Maschine läuft wieder! Ich hab festgestellt das die in
>>> anderen Communitys ebenfalls mit Hetzner ExitNodes Probleme
>>> haben weil über die Switche und Router der Traffic erfasst wird.
>>>
>>> Es gibt einen Hack, den ich nicht nicht ganz verstanden habe,
>>> bei dem die FW Dynamisch die Hetzner AS Systeme Filtert und alles
>>> was dann nicht Hetzner AS ist verwirft und somit auch Portscanns abfängt.
>> Gut, dass sich Hetzner nur über Port-Scans auf eigene Adressen
>> Gedanken macht. Wäre für den Freifunk ärgerlich, wenn sie auch den
>> Rest des Internets so "schützen" würden.
>>
>> IMHO ist das aber für den üblichen Einsatzfall der Rechner im Hosting
>> eine sinnvolle Maßnahme. Wenn z.B. ein Rechner, auf dem normalerweise
>> nur ein Web- oder Mailserver läuft, anfängt, Portscans zu machen,
>> deutet dass schon darauf hin, dass mit der Maschine etwas nicht
>> stimmt. Welchen triftigen Grund sollte der Admin des Rechners haben,
>> großflächig Ports zu scannen? Es ist also vermutlich jemand, der
>> unbefugt auf der Maschine ist. Da ist Sperren die sichere Lösung. In
>> den AGB von Hetzner steht bestimmt[1] auch was zu Portscans.
>>
>> Für den Sonderfall "VPN-Server für öffentliches WLAN" passt das
>> natürlich nicht. Das ist aber auch - was den potentiellen juristischen
>> Aufwand für Hetzner angeht - AFAICT kurz vor dem Tor-Exit-Node.
>>
>>> Ich hab im übrigen auch festgestellt das OpenVPN auf einem WDR4900
>>> über in einem Testnetz maximal 23 bis 35 MBit macht.
>>>
>>> Einen IPSec Tunnel macht bei gleichen Testbedingung ca. 73 bis 85 MBit.
>>> Vielleicht ist es Sinnvoll einen Paradigmenwechsel gleich mitzumachen
>>> und OpenVPN zugunsten der Geschwindigkeit und weniger Ressourcenverbrauch
>>> den Rücken zu kehren.
>> Interessant. Könnte sicherlich auch erstmal parallel zu OpenVPN
>> angeboten werden.
>> Läuft das auf allen üblichen Verdächtigen (IPv6-only, DS-Lite,
>> Carrier-Nat, Mobilfunk mit privaten IPv4, usw.) ohne große Klimmzüge?
>> Oder ist das jetzt eher eine High-Performance-Lösung, die nur auf
>> "Standard-Anschlüssen" läuft?
>> IIRC gab es in der Vergangenheit schon mal Versuche mit anderen
>> Tunnel-Lösungen, aber Berlin ist bei OpenVPN geblieben. In 2016 z.B.
>> wurde AFAICT[3] mal L2TP+Tunneldigger diskutiert. Was ist aus den
>> Experimenten geworden?
>>
>>
>> VG
>> Harald
>>
>> [1] https://www.hetzner.de/rechtliches/root-server/
>> [2] https://wiki.freifunk.net/Fastd
>> [3] https://lists.berlin.freifunk.net/pipermail/berlin/2016-February/032051.html
>>
>> _______________________________________________
>> Berlin mailing list
>> Berlin at berlin.freifunk.net
>> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
> 
> 
> 
> 
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein �ffentlich einsehbares Archiv
>