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
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
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-openwr... 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
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-openwr...
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... 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 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
Hallo, dass es mit den ips aus 10.22.0.0/16 nicht funktioniert hat kann da ran liegen, dass noch kein olsr lief. fürs potsdamvpn verwenen wir bisher nur 172.22.25[123].0/24, der rest aus 172.22.0.0/16 sollte noch zur verfügung stehen. Sven Am 15.03.2018 um 11:24 schrieb Hannes Fuchs:
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-openwr...
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...
Grüße Hannes
Dankesehr! Viele Grüße, Nicco
participants (3)
-
Hannes Fuchs -
Nicco Kunzmann (gmx) -
Sven R.