[Berlin-wireless] Foo-over-UDP (FoU) als Alternative zu OpenVPN für VPN03, c-base morgen

[Bastian]

Hi,

mir ist noch eine weitere Frage eingefallen:

Momentan betreiben wir passthrough mit NAT auf dem vpn03-Servern. Der
OpenVPN-Server hat sich gemerkt hinter welchem OpenVPN-Client welche
Endgerät-IP erreichbar ist. Stichwort OpenVPN iroute.

Das ist insofern toll, weil damit die kleinen Plastikrouter keine
NAT-Table pflegen müssen und somit auch wir doppeltes NAT vermeiden.

Diesbzgl. würde mich mal die NAT+iroute Table auf den OpenVPN-Servern
interessieren. Es scheint ja ganze communities zu geben, die sich einen
vpn03-Tunnel teilen.
Wie würde das mit FoU aussehen? Funktioniert das dank
Connection-Tracking und je Client ein eigenes Interface ganz automatisch?


On 02/29/2016 09:48 PM, Justus Philipp Beyer wrote:
>> On 24.02.2016, at 11:53, Bastian <fly at d00m.org> wrote:
> 
>> Ich kann leider heute nicht in die base kommen und stell deswegen meine
>> Fragen einfach hier:
>>
>> *) Funktionieren FoU auch mit einer MTU < 1280 Bytes?
> 
> Ja, mit IPv4 schon.

Wie wuerde sich FoU bei einem Dual-Stack Lite Anschluss mit 1280er MTU
bei IPv6 verhalten?

>> *) Setzt FoU das DF Bit?
> 
> Ja.
> 
>> *) Lassen sich FoU-interfaces bridgen? Das würde das "ein iface pro
>> client" Problem lösen und ggf. sogar DHCP erlauben.
> 
> Nein. Bridge ist Layer 2, FoU kapselt direkt Protokolle auf Layer 3 - z.B. IP oder IPv6.
> Alternativ gibt es auch die Spielart Generic UDP Encapsulation (GUE) bei der Ethernet-Frames per UDP verpackt verschickt werden. Damit gehen dann Bridges, DHCP, BATMAN und mehr.
> 
>> *) What about IPv6?
> 
> Geht, erfordert bei FoU aber einen separaten Tunnel da in den Headern kein Feld vorhanden ist um das transportierte Layer-3-Protokoll zu vermerken. 
> 
>> *) Schon eine Idee für Authentifizierung/Autorisierung bzw.
>> "Notfall-Blacklist”?
> 
> Ja, eine Idee: Für jeden Tunnel teilen sich Tunnelbroker (VPN03) und Client ein Shared Secret. Mit diesem Geheimnis kann der Client eine Umkonfiguration (also Peer-IP und -Port) seitens des Brokers anstoßen.

Cool! Sowas lässt sich auch ziemlich einfach über mehrere Tunnelbroker
Instanzen synchron halten und Blacklisting tut auch.

>> Ohne von FoU abzulenken möchte ich an dieser Stelle nochmal auf L2TP +
>> Tunneldigger hinweisen. Auch hier ist das NAT-Problem gelöst, wir
>> bekommen bridgeable interfaces, native Hooks und sogar Loadbalancing auf
>> Applikation layer.
> 
> Das ist ein wichtiger Hinweis. Wir haben am Mittwoch auch Tunneldigger besprochen. Abgesehen davon, dass für den VPN03-Use-Case ein Layer-2-Tunnel ineffizienter ist, verleitet Tunneldigger mit seiner sparsamen Dokumentation nicht gerade zu Experimenten.

Na gut, auch zu allen anderen Broker-Technologien in Kombination mit FoU
finde ich gerade ziemlich bis gar keine ausgiebige Dokumentation. Bei
Tunneldigger wissen wir zumindest wen wir alles in der
Wireless-Community so fragen können.

Cheers, Bastian

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160301/cb0b625a/attachment.sig>