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

Di Mai 15 01:13:46 CEST 2018

Augen zulassen und weiter laufen ...

Am 15.05.2018 um 01:02 schrieb 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
>>
> 
> _______________________________________________
> 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