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

[Philipp Borgers]

Router erhält vom Server eine IP. Auf diesem Interface wird NAT auf Seite des
Routers gemacht. Wenn wir nicht genug öffentliche IPv4-Adressen haben, gibt es
halt nochmal NAT auf dem Server. Führt dazu, dass der Tunnel wie ein "normaler"
Provider-Anschluss wirkt und wir viel einfacher Internet ohne VPN anbieten
können.

Informationen über die internen Tabellen von OpenVPN können wir versuchen
auszugraben. Hinweise auf Tools/Wege zum Ziel bräuchten wir dann.

Wir sprechen vielleicht von 2000 IPs pro Instanz. Ich glaube die Tabelle ist
nicht gerade voll und bei konstanten oder logarithmischen Zugriffszeiten sollte
da auch kein Bottleneck versteckt sein.

Falls mir jemand erklärt wie ich ordentlich das OpenVPN mit perf, gprof oder x
profile, kommt vielleicht nochmal mehr Butter bei die Fische.

Gruß Philipp

On Tue, Mar 01, 2016 at 02:19:24AM +0100, Bastian wrote:
> 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
> 



> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ?ffentlich einsehbares Archiv

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160303/3bd2ad0c/attachment.sig>