Dezentrales VPN
Locked
 
|
Nicco Kunzmann (gmx) |
Dezentrales VPN
|
|
|
Hannes Fuchs |
Re: Dezentrales VPN
|
|
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 > [hidden email] > https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [hidden email] https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users |
signature.asc (879 bytes) |
|
Nicco Kunzmann (gmx) |
Re: Dezentrales VPN
|
|
|
|
Hannes Fuchs |
Re: Dezentrales VPN
|
|
Hallo,
Am 15.03.2018 um 11:08 schrieb Nicco Kunzmann (gmx): > 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 > Interessanter Ansatz. Noch ein Hinweis: Die von die verwendeten IPs nutzt Freifunk Aachen [1]. Das könnte langfristig (sehr langfristig :) zu Problemen beim IC-VPN führen. Ich würde an der stelle einfach Kabelkopplungs IPs [2] verwenden, sofern das NAT durchgehend 100Mb macht und nicht durchs Internet geht. Alternativ bietet sich auch was aus 172.16.0.0/12 an, da werden aber auch Bereiche für VPN (IC, GW, Potsdam) verwendet. [1] https://wiki.freifunk.net/IP-Netze#IPv4 [2] https://wiki.freifunk-potsdam.de/IP-Adressen#Spezialanwendung:_Kabelkopplung_.28Mesh_.C3.BCber_LAN.29 Grüße Hannes > 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 >>> [hidden email] >>> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users >>> >> >> >> _______________________________________________ >> Users mailing list >> [hidden email] >> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [hidden email] > https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [hidden email] https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users |
|
|
Sven R. |
Re: Dezentrales VPN
|
|
| Free forum by Nabble | Edit this page |