<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hallo,<br>
<br>
ich hatte mal die Idee, einen Docker-Container als VPN-Server zu
bauen, den man sehr schnell aufsetzen kann.<br>
<a moz-do-not-send="true"
href="https://github.com/niccokunzmann/decentral-community-vpn/">https://github.com/niccokunzmann/decentral-community-vpn/</a><br>
<ul>
<li>Man kann schnell einen eigenen Server aufbauen, wenn man
möchte.</li>
<li>Damit man allen Freifunkern erlauben kann, sich zu verbinden,
werden die öffentlichen Schlüssel auf GitHub verwaltet.</li>
<li>Der Server kann diese Optionen ein-/ausschalten:</li>
<ul>
<li>Weiterleitung nach 0.0.0.0<br>
</li>
<li>OLSR-Meshing über den Server</li>
</ul>
</ul>
Damit könnte die Community, wenn die Server mal ausfallen sollten,
schnell eigene Instanzen erstellen bzw.<br>
können diese über andere Vereine und Institutionen bzw. zu Hause
laufen, wenn die wollen, wobei die Zertifikatvergabe weiterhin
funktioniert und<br>
nur neue VPN-Verbindungen auf den Routern hinzugefügt werden müssen.<br>
<br>
<br>
Was denkt ihr darüber?<br>
<br>
Viele Grüße,<br>
Nicco<br>
<br>
<div class="moz-cite-prefix">On 04/02/2018 01:40 PM, Harald
Stürzebecher wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFhJTv6tTi7ivwCZGy7dypjOZspPhzCKwXLusfUTuw2uG8tNEw@mail.gmail.com">
<pre wrap="">Hallo Sven
Am 1. April 2018 um 20:50 schrieb Sven Röllig
<a class="moz-txt-link-rfc2396E" href="mailto:roellig@stiftung-freie-software.org"><roellig@stiftung-freie-software.org></a>:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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] <a class="moz-txt-link-freetext" href="https://www.hetzner.de/rechtliches/root-server/">https://www.hetzner.de/rechtliches/root-server/</a>
[2] <a class="moz-txt-link-freetext" href="https://wiki.freifunk.net/Fastd">https://wiki.freifunk.net/Fastd</a>
[3] <a class="moz-txt-link-freetext" href="https://lists.berlin.freifunk.net/pipermail/berlin/2016-February/032051.html">https://lists.berlin.freifunk.net/pipermail/berlin/2016-February/032051.html</a>
_______________________________________________
Berlin mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Berlin@berlin.freifunk.net">Berlin@berlin.freifunk.net</a>
<a class="moz-txt-link-freetext" href="http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin">http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin</a>
Diese Mailingliste besitzt ein ffentlich einsehbares Archiv</pre>
</blockquote>
<br>
</body>
</html>