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@lists.freifunk-potsdam.de >> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users >> > > > > _______________________________________________ > Users mailing list > Users@lists.freifunk-potsdam.de > https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
