Hallo Forum,
ich habe im Netz verschiedene Anleitungen gefunden um einen Offloader zu basteln.
Allerdings wird hier immer von einem Futro Image ausgegangen.
Ich möchte hier meinen normalen alten Desktop PC als Offloader nutzen.
Auf dem PC ist derzeit Debian 8.
Ich habe ein Futro Image mittels dd auf Stick kopiert, dann unsere Bremer Firmware x86generic raufkopiert.
Der Stick bootet allerdings nicht.
Ich vermute mal das Futro Image ist hier fehl am Platz.
Auch habe ich unter Debian unser Bremer Virtualbox Image getestet, hier kommt beim booten sofort Kernel Panic.
Wie mache ich denn aus einem normalen PC einen Offloader, hat da jemand einen Tipp?
Ob ich Debian drauf lasse, oder irgendein Ubuntu, oder der PC Platt gemacht wird für OpenWRT ist eigentlich egal.
Habe das gluon-ffhb-2016.1.5+bremen1-x86-virtualbox.vdi auf einem Debian 64bit System in Virtualbox gebootet, dort kommt aber Kernel Panic. Muss ich ein nicht-64bit Debian verwenden?
Zunächst rate ich davon ab, weil ein PC viel zu viel Strom frisst. Du sprichst hier von einem „alten Desktop-PC“, der dürfte so 70 Watt fressen oder so. Das sind übrigens 140 € im Jahr an Stromkosten, also über 10 € pro Monat.
So einen Futro hättest du schnell wieder raus. Wenn der PC sowieso läuft, weil er noch andere Dienste erledigt, wäre Virtualisierung eine Option. Hier empfehle ich KVM und dort brauchst du das x86_kvm-Image mit virtio-NICs.
Eine native Installation von USB-Stick ist möglich, aber nicht empfehlenswert.
In welcher Community bist du überhaupt? Wenn diese bereits auf L2TP umgestellt hat, wäre ein Offloader ohnehin unnötig.
Also das funktioniert jetzt alles in einer Virtualbox.
Ich komme auch auf 192.168.1.1 zum konfigurieren.
Wie sage ich jetzt dem Offloader das meine eth0-Karte am Internet hängt und an meiner eth2-Karte ein Freifunk Router hängt mit Meshonlan aktiviert?
Ich habe in der Virtualbox 2 Adapter konfiguriert, beide im Bridge Modus
Hallo Matthias, die Stromkosten spielen keine Rolle. Ist doch nur zum ausprobieren, auch wenns so bleibt.
Der PC ist eh immer an.
Ich höre zum ersten mal von l2tp. Liest sich ja ganz gut. Ich hoffe das wird in Bremen bald eingesetzt, mit den kleinen Routern ist es ja eine Katastrophe.
Für mich ist es Umweltverschmutzung, wenn ein x86er nur für Freifunk läuft. Die Kosten sind mir da eher egal, ist nicht mein Geld.
Aber wenn du ihn eh noch für was anderes nutzt, spricht nichts dagegen.
Zum Technischen: Wichtig ist, dass vor dem ersten Start des virtuellen Gluons bereits zwei Netzwerkkarten konfiguriert sind. Gluon scannt nur beim aller ersten Start nach den Macadressen, danach nie wieder. Wenn dem nicht so war, kannst du das Image direkt wegwerfen und neu anfangen.
Ob beide Netzwerkkarten erkannt wurde, kannst du mit
ip a s
prüfen. Gibt es sowohl eth0 als auch eth1?
Gluon nutzt eth1 immer als DSL-Port und eth0 für das Client- oder Meschnetz. eth1 kann man also einfach auf NAT oder Bridge stellen (auf den promiscen Modus* achten!) und wenn du dann über eine physikalische Netzwerkkarte das Client- oder Meschnetz rausfallen lassen willst, musst du diese Karte als Brücke konfigurieren. Auch hier wird der promisce Modus benötigt.
Ich weiß nicht genau, wie VBox das handhabt, für KVM muss man die Brücke schon vorher auf dem Hostsystem konfigurieren.
Grüße
Matthias
*) Der promisce Modus ermöglicht, dass der Treiber der physikalischen Karte auf mehrere Macadressen, nämlich die echte und die virtuelle, reagiert. Sonst kommen die Pakete, die von außen an die VM gesendet werden, nicht an.
Warum macht ihr eigentlich immer diesen Gluon schrott auf X86 Geräte?
FastD und Batman gibts im Repo für Debian/Ubuntu basierende Distris,
das ist maximal ein Config File bearbeiten und schon läufts nebenher auf der heimischen Routing kiste.
aber damit fällt die Verschlüsselung des Tunnels weg, daher machen es viele communities nicht. Technisch mag das vielleicht diskutabel sein, aber wenn man als community immer damit geworben hat, möchte man in der Regel nicht Wort brechen.
Ja, wer mit einem »verschlüsselten Tunnel« geworben hat, bleibt auf fastd festgenagelt. Da allerdings schon heute der ISP in den Datenverkehr nicht gucken darf, und bei SSL-Verbindungen sowieso nur noch Start- und Endpunkt der Verbindung sieht, steht der »Sicherheitsgewinn« gegen den nicht zu leugnenden Performanceimpact …
Weil die Mehrzahl solcher Installationen für mindestens Probleme, wenn nicht katastrophale Situationen in den den betroffenen Domains führt über kurz oder lang.
Wenn wir also von „Schrott“ sprechen möchten, dann würde ich das ganz klar auf Deinen Vorschlag beziehen.
Wäre mir neu, erzähl doch mal was für gravierende Probleme auftreten?
Ich habe fast ein Dutzend solcher Installationen laufen, schon zu Ruhrgebiets Zeiten
Für mich ist das einfach nur Ressourcen Verschwendung, aber kann man sehen wie man will
Wenn Deine Arbeitszeit keine Resource ist, dann stimme ich Dir zu.
Und was die Katastrophen anbelangt:
RPI „ohne Hop-penalty“ aber mehreren Fastd-Links an einem kreuzlahmen DSL-Anschluss in Frankfurt
versehentliche „BallsOfSteel“-Exits, nachdem T-Online plötzlich auch IPv6 „verteilt“ hat an die Kunden in Düsseldorf. (Routing zum Fastd ging nur für IPv4 zum Batman-Gateway, Knoten hat sich aber zusätich auch versehentlich als lokaler Gateway announced, zwar ohne IPv4, aber eben die öffenltichen IPv6er der Telekom ins Netz geschoben)
unsichbare/dunkle Knoten (Kein Alfred) im Rheinufer, die sich aber selbst zum Alfred-Master aufschwangen, die Daten aber nicht rebroadcasted haben
Domainbridges von Aachen aus in Fichtenfunk, Gelsenkirchen und Düsseldorf. (Jemand, der mit mehreren Domains in seinem PC simultan experimentiert hat an der Hochschule. Master-Absolvent an einem Lehrstuhl für Rechnernetze…)
Es geht ja auch nicht darum, dass man auf leistungsfähiger Hardware nur Gluon laufen lässt - das wäre, wie du sagst, Verschwendung (da kann man besser Gluon in einer VM laufen lassen und den Rest des Rechners noch anderweitig nutzen). Es geht darum, dass man Gluon-Images nutzt, anstatt Eigenbauten, um Fehlerquellen zu vermeiden und den Wartungsaufwand somit geringer zu halten.
Unsere Community hat noch nicht auf L2TP umgestellt, weil sie es noch nicht „kann“.
Auch wenn alle es wollen.
Es nur 2-3 Leute die für die Firmware zuständig sind, und es soll wohl sehr schwierig sein das hinzubekommen.
Man könnte es hinkriegen, aber ohne ipv6 Funktionalität.
Leider fehlen uns dafür wohl noch ein paar Firmware-Bäcker die sich damit gut auskennen.
