Dezentrales VPN

classic Classic list List threaded Threaded
5 messages Options
Nicco Kunzmann (gmx) Nicco Kunzmann (gmx)
Reply | Threaded
Open this post in threaded view
|

Dezentrales VPN

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
Hannes Fuchs Hannes Fuchs
Reply | Threaded
Open this post in threaded view
|

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) Download Attachment
Nicco Kunzmann (gmx) Nicco Kunzmann (gmx)
Reply | Threaded
Open this post in threaded view
|

Re: Dezentrales VPN

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
[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
Hannes Fuchs Hannes Fuchs
Reply | Threaded
Open this post in threaded view
|

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

signature.asc (879 bytes) Download Attachment
Sven R. Sven R.
Reply | Threaded
Open this post in threaded view
|

Re: Dezentrales VPN

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-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

_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users