also nochmal von vorne. Nach dem ganzen Rumgeschiebe ist das alte Thema kaputt. Also mache ich hier Mal ein neues auf. Ich schlage vor, das alte einfach ruhen zu lassen.
Zusammenfassung aus dem Kopf:
Gluon Master baut Images für KVM, VMware und VirtualBox. Auf langsamen x86-Cpus haben diese allerdings Performanceprobleme. @anon75826926 hatte angeboten nochmal zu schauen, woran es bei den virtio-Treibern hängt, von denen könnte man eine höhere Performance erwarten
Fastd hat Performanceprobleme beim Wechsel vom Kernel- zum Userspace und kann kein Multithreadding.
Es soll untersucht werden ob umac oder aes128-gmc schneller ist, wenn der Prozessor aes kann
@DerTrickreiche: Du hattest mir den Link gepostet, indem es darum ging, Debian direkt als Offloader zu nutzen. Bei mir blieb die Frage offen, welche IP ich dann vergeben soll. IPv4 ist doch immer 10.43.0.1 aber wie verhält es sich bei IPv6? Der Link bezog sich mehr auf feste Server, ich möchte ja, dass der Offloader sich wie ein ganz normaler dynamischer Knoten verhält.
Dieses Thema wurde von mir so eröffnet, inklusive Titel, und ist als umfangreiche Diskussion gedacht. Ich verbitte mir das Abspalten oder Einfügen von Beiträgen insbesondere auch dann, wenn vom Hauptthema abgewichen wird.
Grundsätzlich solltest du schon mal nicht Cipher und Message Authentication Code vermischen, da in fastd beides unabhängig voneinander konfigurierbar ist.
AES128 und Salsa20/12 sind Cipher, UMAC und GMAC/GCM sind MACs.
Nach meiner Erfahrung ist UMAC in jeder Situation schneller als GMAC, sogar wenn die CPU GMAC das per PCLMUL beschleunigen kann.
Auf Geräten ohne Crypto-Beschleunigung ist Salsa20/12 deutlich schneller als AES128. Bei Crypto-Beschleunigern kommt es stark darauf an, wie der Zugriff darauf läuft. Bei vielen Embedded-Kisten kann nur der Kernel direkt auf die Crypto-Hardware zugreifen, und aus dem Userspace geht das nur auf Umwegen (z.B. beim Geode-Prozessor). AES-NI in modernen Intel-CPUs ist die einzige Ausnahme, die mir bekannt ist; AES-NI ist als Erweiterung des Instruktionssatzes der CPU realisiert und kann von jedem Prozess direkt verwendet werden.
Mit AES-NI ist AES128 unschlagbar schnell, da kommt auch Salsa20/12 nicht dran (wobei der Unterschied auch nicht riesig ist…). Andere Crypto-Beschleuniger, die nicht vom Userspace nutzbar sind, sind völlig nutzlos.
Also ergibt sich als Fazit für die empfohlenen Cryptomethoden:
Wenn beide Seiten AES-NI haben: aes128-ctr+umac (fastd muss mit OpenSSL-Support kompiliert werden, damit AES-NI verwendet wird)
Danke für den ausführlichen Beitrag. Werde Mal die Technikabteilung hier in Münster fragen, wie die das kompiliert haben. Unsere Gateways kommunizieren nämlich über aes untereinander.
Man könnte zwar nochmal einen ausführlichen Gegentest machen, aber das klingt danach, als ob es ziemlich Hand und Fuß hat.
Um Images für die VM zu kompilieren brauchst du einen Linux-Rechner mit den nötigen Tools (auf Arch z.B müssen git, wget und subversion nachinstalliert werden). Ein schneller Computer ist auch zu empfehlen. Dann im Terminal: (hier verwende ich im Moment bewusst den master da dort aktuellere Netztreiber drin sind)
git clone https://github.com/freifunk-gluon/gluon
cd gluon
Jetzt die Konfiguration in einen neuen Ordner „site“ kopieren (site.conf findet sich auf jedem bestehenden Router der Community unter /lib/gluon/site.conf, site.mk musst du dir von Github ziehen oder die Maintainer deiner Community fragen). Nun:
make update
make GLUON_TARGET=x86-generic
make GLUON_TARGET=x86-kvm_guest
Die VM Images finden sich jetzt im Ordner „images/factory“.
Läuft bei mir in KVM und ich komme auch in den Config Mode uns mache Mesh-VPN an und starte neu, aber dann guckt man auf die Konsole und unter ifconfig gibt es weder bat0 noch mesh-vpn (ist das normal?) und fastd scheint nie zu starten.
Wenn beim aller ersten Start nicht alles korrekt ist und z.B. kein Netzwerkinterface erkannt wird, ist das Image nicht mehr zu retten und du musst neu anfangen. Die korrekte Initialisierung findet nur beim aller ersten Mal statt.
Also VM gelöscht, Image neu rüberkopiert und so und jetzt funzt es habe aber dieses mal zwar Mesh-VPN angemacht, aber (das hatte ich eben nicht erwähnt) kein Mesh on WAN
Eigentlich geht die IP-Vergabe an allen Stellen automatisch.
Der Offloader bezieht die lokale IP via DHCP von deiner Fritzbox oder was auch immer.
Der Fastd-Tunnel wird an ein weiteres Interface gebunden, das seine IP via DHCP durch den Tunnel bekommt
Zu IPV6 kann ich nicht viel sagen…da fühl ich mich noch nicht sattelfest
Ohne ist es sinnlos, oder was hast du vor? Kann gerade keine sinnvolle Anwendung dieser Konfiguration erkennen. Ping zu google müsstest du aber trotzdem haben, wenn fastd steht.
Ne, die Frage war, wie diese Subsektion Netzwerkkonfiguration aussehen muss, wenn ich keine feste IP will, sondern sich die VM wie ein normaler Router verhalten soll.
/edit:
Ah okay, dann muss ich mal gucken, wo ich die Info herbekomme. Ohne den Teil geht es jedenfalls nicht.
