Neuanfang: VPN-Beschleunigung jeglicher Art

wusel · 13. März 2015 um 00:31

FTR, mit folgendem Setup scheine ich einen Banana Pi als fastd-Offloader am Start zu haben:

root@gw-bananapi:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-ffgt         8000.028906c30566       no              eth0
root@gw-bananapi:~# batctl if
ffgt-mesh-vpn: active
br-ffgt: active
root@gw-bananapi:~# ip route show
default via 192.168.5.1 dev eth1 
10.255.0.0/21 dev br-ffgt  proto kernel  scope link  src 10.255.1.2 
192.168.5.0/24 dev eth1  proto kernel  scope link  src 192.168.5.113
root@gw-bananapi:~# ls /etc/fastd/ffgt-mesh-vpn/peers/
root@gw-bananapi:~# ls /etc/fastd/ffgt-mesh-vpn/backbone/
gw01

Der Knoten, der „uci set fastd.mesh_vpn.enabled=0“ und „uci set network.mesh_wan.auto=1“ fährt, sieht so aus:

root@tst-MR3420v2:~# brctl show

bridge name     bridge id               STP enabled     interfaces

br-client               7fff.e894f6a8f354       no              eth1

bat0

wlan0

br-wan          7fff.e894f6a8f353       no              eth0

root@tst-MR3420v2:~# batctl if

br-wan: active

wlan0-1: active

root@tst-MR3420v2:~# ip route show

10.255.0.0/16 dev br-client

root@tst-MR3420v2:~# ps w | grep fast

1986 root      1528 S    grep fast

Trace innerhalb batman_adv zu anderem Knoten:

root@gw-bananapi:~# batctl tr ea:94:f6:4b:12:9c
traceroute to ea:94:f6:4b:12:9c (ea:94:f6:4b:12:9c), 50 hops max, 20 byte packets
 1: de:ad:be:ef:00:00  36.096 ms  36.215 ms  36.347 ms
 2: ea:94:f6:4b:12:f2  101.127 ms  96.826 ms  96.807 ms
 3: ea:94:f6:4b:12:9c  98.743 ms  98.195 ms  103.771 ms

root@tst-MR3420v2:~# batctl tr ea:94:f6:4b:12:9c

traceroute to ea:94:f6:4b:12:9c (ea:94:f6:4b:12:9c), 50 hops max, 20 byte packets
1: de:ca:fb:ad:57:01 0.136 ms 0.088 ms 0.077 ms
2: de:ad:be:ef:00:00 36.311 ms 35.888 ms 35.901 ms
3: ea:94:f6:4b:12:f2 105.085 ms 98.861 ms 99.947 ms
4: ea:94:f6:4b:12:9c 107.278 ms 99.330 ms 99.328 ms

Der Knoten tst-MR3420v2 sendet eine test-SSID aus (und mesht nicht mit normalen FFGT-Knoten), ich kann mich darüber verbinden, das Endgerät bekommt IPv4 (RFC1918) und IPv6 (public), IPv4- und IPv6-Ziele sind erreichbar. Leider hänge ich derzeit an einem lokalen Bottleneck (VDSL 25, der verwendete Router auf ARM-Basis macht aber bei unter 20 MBit/sec Schicht); ferner teste ich im Live-Mesh, d. h. ich bin immer auf die Performance des/der (zur Zeit ist nur genau 1 GW verbunden, um die Last steuern zu können) echten Gateways begrenzt.

MPW · 13. März 2015 um 07:57

Funktioniert Alfred bei dir?

wusel · 13. März 2015 um 21:06

Auf dem Banana Pi? Never tried, wenn ich’s anders hinbekommen hätte, hätte ich wirklich nur eine Verbindung von eth0 nach fastd auf dem GW gemacht, also nicht einmal batman auf de Banana Pi laufen. Aber leider ist batman_adv mir noch immer zu ungriffig. Normale Tunnel verstehe ich; was batman_adv macht, verstehe ich nur scheibchenweise

MPW · 14. März 2015 um 08:33

Scheitert es am kompilieren der alten 2014.3er-Version (neuere sind nicht zu FF kompatibel) oder arbeitet es nicht richtig?

Probier es Mal mit festen IPs, dann hat es bei mir funktioniert. Da musst du dir eine von der Community reservieren lassen. Damit hat es zumindest bei mir auf x86 Ubuntu funktioniert.

wusel · 16. März 2015 um 23:49

?ECONTEXT

Ich habe hinter meinem Banana Pi, der fastd offloaded, einen MR3420, der taucht auch in der Karte auf. Aber ich brauche kein Alfred auf dem Banana Pi, wozu? Wäre es ein Gluon, ja, aber als fastd-Offloader stört es mich eigentlich schon, daß er im batman_adv mitspielt.

MPW · 17. März 2015 um 07:54

Ich hab bei meiner Lösung immer versucht, dass der Offloader wie ein normaler Knoten im Graph auftaucht, aber wenn du das anders handhabst, ist doch auch gut. Hätte mich nur interessiert, ob er bei dir läuft.

wusel · 20. März 2015 um 01:32

Bei Gluon-x86 sähe ich einen SInn, täte der Offloader auftauchen.

DerTrickreiche · 20. März 2015 um 01:43

Wozu?
Wen interessiert, in welchem Keller der Offloader steht?

Die aktiven Knoten melden ihren Standort - das ist doch viel aussagekräftiger!

p.s. auch auf die Gefahr hin, daß ich mich wiederhole; Gluon-x86 ist eine Sackgasse!

MPW · 20. März 2015 um 09:23

Ja ich merke es auch langsam. Hast wohl - wenn ich das vorsichtig nach dem Bild beurteilen darf - etwas mehr (Lebens-)Erfahrung als ich . Denn wie kürzlich von @tcatm getestet, schafft wohl selbst ein i5 ohne AES nur ~60 Mbit/s. Das wird der Grund sein, warum mein J1800 so schlecht ist, denn er hat kein AES.

Was ist denn dein bisher bester Ansatz um wirklich eine 50 oder 100 Mbit-Leitung auszulasten? Ich hab mich ehrlich gesagt etwas verrant und suche einen neuen Ansatz.

Die Alternativen, die ich momentan sehe, sind ein stärkerer Router oder ein Raspberry. Aber was schafft der wirklich? Langfristig geht’s wohl nicht ohne multithreadding für fastd.

Allerdings muss man sagen, dass die Geschwindigkeit hier auch einfach stark schwankt. Mal kriege ich nur 4-5 Mbit/s runter und Mal 11 Mbit/s. Vermutlich brauchen wir einfach mehr Backendkapazität jetzt.

DerTrickreiche · 20. März 2015 um 21:38

Ich glaube, wir haben da unterschiedliche Herangehensweisen

Mir geht es darum, zu verstehen, was unter der Haube eines FF-Router eigentlich passiert.

Wenn ich das wirklich durschaue, und beim Aufsetzen solch einer Kiste nicht mehr stumpf einem HowTo folgen muß, kann ich das auch beliebig skalieren.

Technisch ist es dann völlig egal, ob ich das auf nem RaspberryPi oder einem X86-Board mit i7 installier, und daher hat mich die Geschwindigkeit auch bisher überhaupt nicht interessiert.
Zumal der Flaschenhals scheinbar ohnehin nicht der Router ist, und neuere Router Modelle i.d.R. auch leistungsfähiger als die Vorgänger sind.

Das ist der Punkt, und die mickerigen 841 sind ja nicht für alle Zeiten das Maß aller Dinge

Darüber hinaus sehe ich den Vorteil solcher Konstruktionen eher bei grösseren Installationen mit vielen Link-Strecken - sicher nichts, was der Otto-Normal-Freifunker braucht.

pRiVi · 21. März 2015 um 13:01

Ich habe bereits in einem anderen Post erklärt woran das liegt… Ich hätte auch schon längst hierfür an Verbesserungen gearbeitet, würden wir in Augsburg nicht immer noch von Monic als nicht Freifunkkompatibel gelten, da es ja in Augsburg schon Freifunker gibt und deren Intoleranz geschützt werden muß.

Ich hatten mir das mit dem @anon75826926 auf dem letzten CCC Kongress angeschaut, und da ist zu sehen dass der fastd nur für unter 20 % der Rechenzeit verantwortlich ist, der Rest geht bei den Kernel-Kontextswitchen verloren.

Solange oben genannte Problematik unverändert bestehen bleibt, werde ich meine Zeit nicht in ein Projekt stecken dessen Bundesverein uns für unpassend hält. Darf sich also jemand anderes anschauen.

SenorKaffee · 21. März 2015 um 23:53

Nett, dass du immerhin Bescheid sagst, dass du deine Mithilfe taktisch verweigerst. Macht spontan symphatisch.

pRiVi · 21. März 2015 um 23:57

Ich habe schlichtweg keine Lust meine Zeit in ein Projekt zu stecken, dass immer noch nicht gegen unsere Ausgrenzung vorgeht und weiterhin von uns erwartet Intoleranz zu akzeptieren. Ich sehe nichts verwerfliches daran meine ehrenamtliches Engagement nur in die Dinge zu stecken in denen ich Wert sehe.

Und immerhin habe ich unsere Ergebnisse euch mitgeteilt, so könnt Ihr davon nutzen ziehen. Ich hätte auch einfach nichts schreiben können, dann hättet Ihr noch nicht mal gewusst dass man hier optimieren kann.

DerTrickreiche · 22. März 2015 um 00:00

Ich möchte doch darum bitten, das Faß jetzt hier nicht ein weiteres mal aufzumachen!
In diesem Thread geht es um VPN-Beschleunigung und nichts anderes.

Wir haben alle zur Kenntnis genommen, daß du nichts beitragen willst, und bitten daher darum, es dabei zu belassen!

MPW · 22. März 2015 um 00:00

Ich weiß leider nicht, was für einen Kindergarten ihr da baut.

Aber ich war da sicherlich nicht beteiligt. Könntest du mir sagen, ob du schon Optimierungspotential gefunden hast? Wäre echt klasse, denn fastd ist eine der Geißeln von Freifunk.

/edit: Bzgl. VPN denke ich müssen, wir das Pferd Mal andersherum aufziehen. Statt zu experimentieren Mal mit dem stärksten Pferd, einer leistungsstarken Desktop-CPU anfangen und gucken was realistisch ist.

pRiVi · 22. März 2015 um 00:05

@MPW Eine Idee wäre sich von der TUN/TAP Schnittstelle zumindest für TCP zu lösen, und nur noch nicht-TCP darüber zu übertragen. TCP kann man viel effizienter über transparente TCP-Relays transportieren, da der Kernel pro read/write syscall gleich Megabytes an Daten ins Userland und zurück übertragen kann und nicht nur 1500 (minus IP/TCP Overhead) Bytes. Das ganze hilft natürlich nur für TCP und nicht für UDP.

Ansonsten: Tun/Tap Schnittstelle auf Kernelseite verbessern.

Bezüglich Kindergarten… ich fänds schon toll wenn sich alle damit beschäftigen um auf der WCW Stellung beziehen zu können.

MPW · 22. März 2015 um 00:11

Danke für die Infos. Könntest du evtl. dafür Mal einen Branch anlegen? Ich verstehe da leider nicht viel von, würde das aber wahnsinnig gerne Mal testen. Soweit ich dich verstanden habe, würde das sowohl auf den Billigroutern als auch auf Offloadern für mehr Durchsatz sorgen, richtig?

Also wenn da wirklich was Signifikantes bei rumkommt, würde ich dir oder in deinem Namen einen Router spenden.

/edit: Natürlich würde ich das dann auch kompilieren und mittesten, nur programmieren kann ich es leider nicht.

Bitte eröffnet dafür ein eigenes Thema, wenn es da Diskussionsbedarf gibt. Ich kenne die persönliche Ebene des Streits leider überhaupt nicht und möchte mich da auch nicht einmischen.

pRiVi · 22. März 2015 um 00:18

Bei der TUN/TAP Verbesserung wäre vermutlich einiges rauszuholen. Bei allen Systemen, klein wie groß. Theoretisch irgendwas bis zu 400% mehr… allerdings ist wohl 100-200% realistischer. Da Kernelseitige Programmierung notwendig ist, ist das nichts für einen Wochende mal, sondern schon was größeres… Viel größeres… Vieleicht hat der @anon75826926 ja mal lust… Der weiß bescheid.

Transparente TCP-Relays brauchen viel RAM, sind also weniger was für die kleinen Boxen, sondern eher für Kisten mit viel RAM. Können übrigends allgemein die Geschwindigkeit erhöhen da geringerere Latenz auf TCP wirkt, was zu größerer Bandbreite führen kann, und auch retransmits schneller verarbeitet werden. Fürs WLAN natürlich sehr schön, wo schon mal was verloren gehen kann. Müsste mal mal ausprobieren… Ich würde schon vermuten dass man locker auf die doppelte Leistung kommen müsste…

Ich bin ja laut Monic nicht zugehörig zum Freifunk da „nicht ganz passend“ , also werde ich auch nichts machen solange das so ist. Warum sollte ich auch. Ist euer Bundesverein, müsst Ihr mit dem klären warum er Leute und Communites ausschließt oder euch eben davon, oder zumindest dieser Entscheidung, distanzieren. Kannste ja mal auf dem WCW dazu fragen.

MPW · 22. März 2015 um 00:26

Also, machen wir einen Schuh draus. Wenn du das umsetzt gibt’s 'nen schönen Router von Ubiquity oder den Wert in Bar an deine Community. Natürlich wiegt das nicht die Arbeitszeit auf, sondern soll ausdrücken, dass ich es mega genial fände, wenn du das probieren würdest.

Grüße
MPW

pRiVi · 22. März 2015 um 00:28

Ich würde gerne zu euch gehören, nur leider ist es deinem Bundesverein/Monic wichtiger daß Leute in Augsburg Freifunk zu ihrem Privatprojekt machen dürfen. Und wenn wir nicht dazu gehören dürfen, gehöre ich wie auch die anderen nicht dazu. Sorry.