Moin,
Ich habe heute ein GL-MT300N-V2 bestellt. Die Technischen Daten sahen ganz gut aus
MediaTek MT7628AN CPU-Kerne: 1, CPU MHz:580, Flash MB :16, RAM MB :128 für 23 Euro beim großen Versandhändler aus Amiland. Klingt eigentlich ganz gut meiner Meinung nach da müsste doch mit Freifunk was gehen.
Gut das Ding unterstützt von Haus aus OpenVPN einfach die Config Datei Hochladen und Fertig. Sollte laut Rezensionen so 10 Mbits schaffen mit OpenVPN klar das ist nicht viel aber da geht sicher mehr.
So habe meinen Bekommen. Bin ganz Begeistern ist total klein und Geschwindigkeit im WLAN ist auch ganz gut der hat meine 100 Mbits hier Problemlos aufs Ipad bekommen.
Das System Läuft mit OpenWRT an den man auch spielen kann. Es gibt ich sag mal zwei Webinterfaces einmal das vom Hersteller und einmal das von OpenWRT.
Als VPN wird einmal Openvpn als Client und Server Angeboten. Außerdem Wireguard jeweils als Client und Server.
Mit OpenVPN bin ich auf 10 Mbits Down und Up gekommen
Wireguard konnte ich leider nicht aktuell noch nicht Testen da muss ich erstmal mein vServer neu Konfigurieren
Mein Fazit bis jetzt Für den Preis ist das echt Super das hätte ich nicht gedacht. Für Freifunk ist das ganze ding Interessant mal sehen was drauf wird. Ach ja ein Netzteil wird nicht Mitgeliefert scheint aber auch Versionen zu geben die eins von Werk auf eins haben.
Nachtrag: hab’s jetzt selbst ausprobiert; ich nutze die bislang wie gesagt nur als »iLO-Firewall« (WAN-Port im RZ an internet-facing Switchport, LAN-Port hängt an iLO[1]-Port des Servers, über WAN baut der Router eine OpenVPN-Verbindung zu einer Management-VM in einem anderen RZ auf). Aber darüber bringt eine dd-nc-Pipe tatsächlich auch nur 1.1 MB/s:
root@adm01:~# dd if=/dev/zero bs=4M count=10 | nc -q 2 100.64.1.2 8888
10+0 records in
10+0 records out
41943040 bytes (42 MB, 40 MiB) copied, 37.6957 s, 1.1 MB/s
root@GL-MT300N-V2:~# nc -w 5 -v -l -p 8888 | dd of=/dev/null bs=4M
Hmm. Das überrascht mich jetzt doch, muß ich mir die Tage mal genauer angucken — da es nicht auf Bandbreite/Geschwindigkeit groß ankommt bei dem Einsatz, habe ich das vorher nicht ausprobiert
[1] iLO: herstellerspezifische IPMI-Lösung aus den frühen 00er Jahren, bevor IPMI herstellerübergreifender Standard wurde.
So habe mal zum Spaß Serverseitig die Verschlüsselung von 256 Bit auf 128 Bit geändert. Das Ergebnis bleibt gleich vom Speed her. Hätte ja Theoretisch steigen müssen was allerdings nicht Passiert ist. Vielleicht hat ja jemand noch ein paar Ideen
Update 25.04.2019 21 Uhr
Habe ein wenig weiter damit Gespielt. Wenn ich Speedtest durchlaufen lasse gibt es am Anfang immer schon ein Drop auf 35 Mbits 1 Sekunde später gehts auf Stabile 10 Mbits. Als ob da eine Drossel drinen wäre der CPU geht auch von der Auslastung her.
hab mir letztens auch einen MT300N-V2 als Spielzeug und für unterwegs zugelegt.
Lief testweise problemlos einige Stunden mit der experimentellen Firmware von FF MWU (2019.1+mwu~exp2019042401).
Die Empfangsqualität war im Schnitt beim meshen gegen einen TP-Link 941n und einen 740n jeweils 8-11db (je nach Aufstellung des GL-iNet) schlechter als die Empfangsqualität der TP-Links.
Kleines Update von mir ich habe grade wieder zeit gehabt und ein wenig mit den Vorinstallieren VPN Protokollen gespielt.
Mit OpenVPN komme wie vorher auf 10 Mbits Dwon und Upload
Mit Wireguard komme ich auf 45 Mbits Download und 25 Mbits Upload
Ich habe hier VDSL 100 der Server von Wireguard ist mein Eigener bei der Netcup (VPS 200 G8)
Meine Empfehlung ganz klar zu Wireguard VPN das kleine teil hat ordentlich Dampf und ich habe ein neunen Offloader fürs Gastnetz gefunden. Sicher auch Interessant für Freifunk
Wireguard ist ein ziemlicher Alptraum aufgrund der blödsinnigen Verquickung von Tunneln und IP-Adressen. Das mag ja bei Hub-Spoke toll sein, aber Wireguard ist schlicht nicht in der Lage, „links“ und „rechts“ mit 0/0 oder::/0 zu arbeiten
Da wird hier ja nun nicht über Freifunk-Verwendung disktuieren (offensichtlich):
Wireguard ist in vielen Belangen ein Alptraum. Man spürt ziemlich schnell, dass die Entwickelnden einen sehr begrenzten Usecase (Platformen, Architekturen) im Blick haben. Und dass von der ursprünglichen Idee „ein L3-Interface wie jedes andere auch“ irgendwie dann doch wenig wirklich real ist.
Auf IoT-Geräten ohne hinreichend valide Zeit oder hinreichend Randompool kommt man erst gar nicht vom Fleck. Und wie von Dir beschrieben, hinterher legt man doch irgendwie weitere GRE oder gar GRETAPs über das Wireguard-Interface, um an Limitations von Wireguard herumzukommen.
Ich bin recht neu auf dem Gebiet VPN und versuche momentan einen Reiserouter einzurichten, um von Unterwegs in mein Heimnetzwerk zu kommen. Leider komme ich mit einem WR902AC nicht über 6 MBits per OpenVPN hinaus. Jetzt denke ich über Wireguard nach und bin auf deinen Post gestoßen. Könntest du den bitte näher erklären?
Auch bei Deinem Post, würde ich mich über eine nähere Erläuterung riesig freuen am besten in einfachen Worten
Ja, aber in Deinem Usecase ist es irrelevant, WireGuard wird, wie auch direkt L2TP, bessere Durchsatzraten liefern — für ein Szenario wie Deins wurde WG entwickelt. Ich hingegen möchte n (n>2) Standorte per WireGuard vernetzen, sodaß überall 0/0 bzw. 0::/0 – die Defaultroute bzw. das alle Adressen beinhaltende Prefix – auf beiden Seiten der WireGuard-Konfiguration steht. Das kann WireGuard designbedingt nicht. Kurz: ein klassischer »Road-Warrior-Tunnel« – lokal 192.168.1.0/24, remote 0/0 – ist kein Problem. Aber wenn ich zwei Rechner, die 0/0, also das gesamte Internet, erreichen können, per WireGuard verbinden will, wird’s … difficil.
am besten in einfachen Worten 