[Berlin-wireless] Anfrage Berliner VPN-Server

[Sven-Ola Tuecke]

Moins,

zwei Gedanken dazu.

Erstens: Sinn + Zweck des Freifunk-VPNs ist es, eine andere
Quell-IP-Adresse dranzukleben. Wegen der derzeitigen Rechtsauslegung in
diesem Land. Das machen wir mit der Umleitung, weil das IPv4-Protokoll
keine vernünftige (dezentrale) Technik dafür kennt. Schreib' mir eine
Möglichkeit, wie man über einen direkt-via-DSL-rausgehenden Tunnel etwas
machen kann, was der DSL-Betreibenden Person auf die Füße fällt, und ich
lass' es bleiben ;-)

Und zweitens: es kommt nicht darauf an, was die einzelne Person noch an
Geschwindigkeit erhält. Sondern darauf, ob + wie man
Datenverkehr-über-den-VPN-Server vernünftig abwehren kann. Und dafür
darf es (hoffentlich) noch erlaubt sein, nochmal über Sinn+Zweck dieser
Veranstaltung nachzudenken. Ein "normales" VPN verbindet ja die
Funktionen "a) Vertraulich (verschlüsselt)" und "b) Authentifiziert
(Quell-IP)". Wir brauchen nur teilweise (b) als Schutz vor
Abmahnanwälten und verzichten eh' schon aus Performanzgründen auf die
Verschlüsselung. Bei (b) liegt also das Optimierungspotential und bei
einem Tunnel-über-Tunnelausgang klebt ja immer die Quell-IP des
Tunnelbetreibers dran.

Gleichwohl ist es nicht dumm, über technische Konsequenzen nachzudenken.
Wenn man tatsächlich genau einen OpenVPN-UDP-Datenstrom direkt am GW
ausleitet könnte es tatsächlich sein, dass die OpenVPN-PMTU-Detection
nicht ordentlich funktioniert. Weil die möglicherweise über
ICMP-Frag-Needed läuft und natürlich falsche Werte zurückliefert, wenn
die OpenVPN-UDP-Pakete einen anderen Datenweg nehmen also die
ICMP-Pakete für die PMTU-Detection. Ich hab' nicht behauptet, dass eine
Datenwege-Optimierung Hopplahopp-mal-eben-so geht ;-)

Gruß // Sven-Ola

Am 30.11.2014 um 01:44 schrieb Kai 'wusel' Siering:
> On 28/11/14 22:00, Sven-Ola Tuecke wrote:
>> Hi,
>>
>> nix DPI. Ich denk da eher an eine Policy-Routing-Regel, die genau
>> eine Udp-Verbindung auf Port 1194 pro interner IP eben nicht über
>> Vpn03 leitet. Wär ziemlich risikolos für doe Gateway-Betreibende aber
>> eben für den Teilnehmer optimaler. Oder so.
>
> Ah, Kommunikationsfehler ;) Ich betreibe OpenVPN auf so ziemlich jedem
> Port außer 1194. Klar, jedweder Traffic DPORT 1194 UDP könnte im
> Prinzip direkt am heimischen xDSL rausgehen, anstatt erst über die
> OpenVPN-Strecke zu vpn03 laufen zu müssen. Also, theoretisch.
> Praktisch mag aber ein Freifunk-Nutzer einen OpenVPN-Tunnel für dummes
> Zeug nutzen, und dann fiele das doch wieder auf den
> Knotenbetreiber/Anschlußinhaber zurück, denn von dessen Anschluß kam
> ja die Verbindung zum OpenVPN-Server.
>
> Kurzum, das erscheint mir als Spiel mit dem Feuer.
>
> Ich will die Tage mal meinen Berliner Knoten von vpn03 auf eine meiner
> Kisten umbiegen und gucken, wieviel Performance ich einbüße bei
> OpenVPN über eine FF-Knoten-VPN-Exit-Strecke verglichen mit OpenVPN
> direkt. Gefühlt wird der FF-Knoten das Bottelneck sein, mit
> Gluon/fastd kommen wir in Gütersloh kaum über 8 Bit/sec hinaus, mit
> zwei Multi-GHz-CPUs an jedem Ende der OpenVPN-Strecke ist "etwas" mehr
> drin. Und schon der Cubietruck oder erst recht der Odroid, beides
> GHz-ARM-basierte Kistchen, liegen mit OpenVPN deutlich über 'nem
> Rapsberry [1], der schein's vergleichbar schlecht für verschlüsselte
> Tunnel geeignet ist wie die Embedded-CPUs der Standardrouter.
>
> MfG,
> -kai
>
> [1] http://v2.blogdoch.net/2014/03/06/wusel-165857/
>


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