[FFP] Dezentrales VPN

Nicco Kunzmann (gmx) niccokunzmann at gmx.de
Do Mär 15 11:08:49 CET 2018


Hallo Hannes,

ich bedanke mich für die ausführliche Beschreibung.
Ich habe mich dadurch mehr mit OpenVPN beschäftigt und auch ein
Problem lösen können: Mesh zwischen 10.22.254.158 und 10.22.254.161
durch ein NAT-Gateway.
Hier ist der Blog-Post:
http://niccokunzmann.github.io/blog/2018-03-15/olsr-meshing-durch-nat-openwrt-to-openwrt-tunnel-berliner-freifunk-firmware

Dankesehr!
Viele Grüße,
Nicco

On 03/13/2018 05:09 PM, Hannes Fuchs wrote:
> Hallo,
>
> *dezentrales VPN*
> Ein wirklich dezentrales VPN würde bedeuten, das am besten der Router
> selbst Client sowie Server ist. Dafür bietet sich Tinc VPN [1] an. Tinc
> kommt z.B. bei dem IC-VPN [2] zum Einsatz. Bei einer wirklich
> dezentralen Lösung gibt es aber mehrere Probleme:
> - NAT (hier könnte IPv6 Abhilfe schaffen)
> - Austausch von IP-Adressen/FQDNs (evtl. dyndns -> Zentral DNS)
> - Austausch von Pubkeys untereinander (evtl. TXT Record -> Zentral DNS)
> Im Idealfall hätte dann jeder Router zu jeden anderen eine VPN
> Verbindung. Also alleine für VPN über 100 Stück, wobei sich dies auf
> Routern mit Uplink beschränken sollte.
>
> *Anwendungsfall: Firmennetz*
> Elegant wäre natürlich hier ein VLAN, um die FF KK vom restlichen Netz
> zu trennen. Hier einen extra VPN (meinetwegen auch im Firmennetz)
> aufzusetzen sehe ich als zu großen Overhead. Eine Alternativ könnte das
> schon erwähnte Tinc sein. Besser sind vermutlich einfache
> Tunnel-Protokolle wie z.B. IPIP [3] oder auch gretap [4]. Siehe auch
> "Performance of tunneling methods in OpenWRT" [5], dort sind auch
> Konfigurationsbeispiele zu finden.
> In Firmennetzen wird auch gerne das Private 10.0.0.0/8 (oder ein Teil
> davon) verwendet. Da kommt es schnell zu Überschneidungen mit dem
> FF-Netz, was wiederum Probleme bereitet.
>
> *Potsdam-VPN*
> Wie ein Potsdam-VPN Server eingerichtet wird ist im Wiki [6] zu finden.
>
>
> Ein wirklich dezentraler VPN käme den Freifunk-Gedanken am nächsten,
> aber das haben wir auch schön öfters beim Treffen "durchgekaut" und auch
> wegen der oben genannten Problem und Komplexität verworfen. Man kommt
> einfach bei so etwas nicht ohne zentrale Instanz oder manuellen
> Konfigurationsaufwand aus.
>
>
> [1] https://tinc-vpn.org/
> [2] https://wiki.freifunk.net/IC-VPN
> [3] https://tools.ietf.org/html/rfc2003
> [4]
> https://openwrt.org/docs/guide-user/network/tunneling_interface_protocols?s[]=gretap#protocol_gretap_ethernet_gre_tunnel_over_ipv4
> [5]
> https://justus.berlin/2016/02/performance-of-tunneling-methods-in-openwrt/
> [6] https://wiki.freifunk-potsdam.de/Potsdam-VPN#Server
>
> Grüße
> Hannes
>
> Am 13.03.2018 um 15:29 schrieb Nicco Kunzmann (gmx):
>> Hallo,
>>
>> ich habe mal einen Entwurf erstellt, in dem ich ein dezentrales VPN für
>> Potsdam vorschlage.
>> https://github.com/niccokunzmann/decentral-community-vpn
>> Mein einfacher Use-Case wäre, dass ich z.B. Freifunk-Meshing in
>> Firmennetzen erlauben möchte,
>> in denen OLSR nicht so leicht meshen kann - verschiedene Subnetze und
>> Gateways.
>>
>> Wer mag, kann mitmachen.
>> Wo ich Hilfe bräuchte: Wisst ihr noch, wie ihr das Potsdam-VPN
>> eingerichtet habt?
>> Ich würde diesen Server gerne dazu kompatibel haben.
>>
>> Viele Grüße,
>> Nicco
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.freifunk-potsdam.de
>> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
>>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.freifunk-potsdam.de
> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk-potsdam.de/pipermail/users/attachments/20180315/846739a9/attachment-0001.html>


Mehr Informationen über die Mailingliste Users