Offloader-Installation, virtualisiert (Proxmox, VLANs etc)

Technik Hardware
1

Hallo,

mein Name ist Michael und ich bin neu hier.

Ich möchte bei uns in der Firma für Gäste, Leiharbeiter, Ferienjobler und Trucker Freifunk anbieten. Nach einigen Abenden lesen in Wikis, Foren und Blogs, habe ich mich nun ans Werk gemacht und einen Offloader mittels einem Barebone aufgesetzt. Da der Rechner sowieso unbenutzt im Schrank lag, erschien mir dies sicherer als eine Offloader-VM auf einem Produktivserver zu betreiben.

Der Barebone hatte acht NICs. Vier davon sind onboard, die anderen vier waren per miniPCIe nachgerüstet. Letztere habe ich durch ein WLAN-Modul ersetzt. Die Schnittstellen sind wie folgt belegt:

eth0: Mesh-on-LAN
eth1: br-wan
eth2: unbenutzt
eth3: br-client (umgeleitet durch: uci set network.client.ifname=„eth3 bat0“)

eth1 habe ich mit unserer pfSense verbunden. br-wan hat quasi sein eigenes DMZ-Interface.

eth3 habe ich mit einem Switch verbunden, und gebe es mittels VLAN 71 auf unseren APs aus. Aus Sicheitsgründen habe ich an allen Switches in diesem Schrank ACLs eingerichtet, damit auch nur dieser eine Steckplatz funktioniert. Falls das Kabel irgendwann jemand falsch einstecken sollte, haben wir zumindest Freifunk nicht im eigenen LAN, bzw. umgekehrt.

Jetzt ist mir aufgefallen, dass auf allen involvierten Switches einige hundert MACs in VLAN 71 gelernt wurden. Standardmäßig werden 600 dynamische MACs pro Port erlaubt, welche oftmals auch erreicht werden. Mir erscheint das etwas viel. Was sind das für Adressen? Supernodes? Was passiert wenn das Limit erreicht wird? Ein Testlimit von 10 MACs hat auch funktioniert…

Ich meine gelesen zu haben, dass ich mit o.g. Konstruktion nicht mesh-fähig bin. Derzeit gibt es keine Nachbarn mit Freifunk. Aber wenn, dann sollte es auch funktionieren. Meine Überlegung wäre: eth0 auf eth2 zu brücken und daran jeweils ein TP-Link CPE210 mit Gluon-Image nach links, sowie nach rechts des Gebäudes auszurichten. Somit würde ich die Straße versorgen, mesh-fähig sein, und die Supernodes nicht mit weiteren VPN-Verbindungen belasten. Sehe ich das richtig? Wie würdet ihr das realisieren?

Mir würden noch weitere Fragen einfallen, aber erst mal soll’s genug sein :slight_smile:

Vielen Dank und Grüße,

Michael.

2

Nachtrag: Das nachgerüstete WLAN-Modul wird nicht gefunden. Mein Gedanke war, daran eine Außenantenne für’s Mesh zu installieren. Kann das so überhaupt funktionieren?

3

Hallo,
Schön, dass du Freifunk anbieten willst!
BATMAN-ADV ist ein Layer 2-Mesh - das heißt, du bekommst alle MACs aus deinem Netzsegment mit.
Zunächst wäre es aber mal interessant zu wissen, welche Firmware du verwendest.

Was das Meshing betrifft: Man kann entweder einen Outdoor-Freifunk-Node über Mesh anschließen, der dann mit anderen Mesht. (CPE210 bekommen Mesh on LAN/WAN). Technisch ginge es auch, dasselbe Signal zum „Partner“ über eine Richtfunkstrecke zu führen. Mesh klappt dann nicht automatisch, dafür aber vermutlich mit besserem Durchsatz.

Am besten ist hier wohl der Kontakt zur lokalen Community.

Viele Grüße
margau

1 „Gefällt mir“
4

Firmware:
0.22.1-stable.0-20180715 / gluon-v2017.1.8

Ich dachte eine „selbstbau“ Mesh-Lösung wird nicht gern gesehen, weil es gegen das Prinzip ist. Deine erste beschriebene Option ist quasi so, wie ich das auch denke (Anschluss CPE bei mir an eth0)? Für die Richtfunkstrecke braucht die Gegenstation entsprechende bzw. zusätzliche Hardware. Es darf ja immer nichts kosten…

Ja, habe mir schon überlegt beim nächsten Treffen dort mal zu erscheinen.

Danke.

Michael

5

Hallo,
ich meine hier tatsächlich die Community, nicht die Gluon-Version.

Ich persönlich bin der Meinung lieber „koordiniertes Mesh“, ggf. Als Richtfunk, das funktioniert dann auch richtig.

Viele Grüße
margau

1 „Gefällt mir“
6

Hi,
bin bei Freifunk-Westpfalz.

Ich habe mit Mesh wenig Erfahrung, aber klar, koordiniertes ist mir auch immer lieber. Aber da sind wir wieder bei der Prinzipfrage. Ich habe schon oft schlechtes darüber gelesen, dass man damit vom Standard abweichen würde. Dass das mit Freifunk nicht mehr viel zu tun hat, etc… Frag mich jetzt bitte nicht nach Links. Ich müsste wieder suchen.

Danke.

7

Das ist etwas, was am besten mit der lokalen Community diskutiert wird; konzeptionell ist Freifunk ›immer‹ (auch) ein Experimentalnetz, allerdings kann ein kleiner Fehler bei einem lokalen Setup aufgrund der Technik (bei Gluon-basierten Netzes derzeit i. d. R. Layer-2-Maschennetzwerk) zu Problemen im gesamten Netz führen. Daher finden einige Gruppen Bastelleien toll, andere nicht.

Selbstbau bedeutet aber meistens, daß kein automatisches Update funktioniert; das wiederum bedeutet, daß die Selbstbaulösung ggf. bei Änderungen im Netz (Kanal- oder SSID-Wechsel; Aufteilung von/in Domänen/Hoods/Meshes; Änderung Meshverfahren; Änderung batman-Version; VPN-/Gateway-Änderungen; …) abgehängt wird/manuell und koordiniert angepaßt werden muß, wohingegen ein (VM-) Image mit fest definiertem eth0-eth1-Pärchen (meistens) derlei Änderungen automatisch mitnehmen kann. Denn auch wenn es rd. 44.000 Freifunk-Knoten in Deutschland gibt, ist die Zahl derer, die in den lokalen Communities aktiv mitarbeiten, weitaus geringer (›gefühlt‹ ein einstelliger Prozentanteil) — aus genannten Gründen ist aber zumindest eine aktive Verfolgung der lokalen Aktivitäten bei Selbstbau ›ratsam‹.

Insofern würde ich normalerweise raten, den Barebone mit dem Standard-x86-Image Deiner Community zu bestücken und nur 2 der 4 Ethernets zu nutzen; für die VLAN-71-Aktion reicht es, das br-client-ethX zu haben. Um außen Mesh anzubieten, würde ich entsprechend unterstützte Outdoor-Geräte vorschlagen, die eine direkte VPN-Verbindung aufbauen. Zweckmäßigerweise wäre dabei darauf zu achten, daß sie sich nicht gegenseitig ›sehen‹, das erhöht dann auch tendentiell den Durchsatz je Outdoor-Knoten.
Das ist die für alle Seiten streßfreieste und wartungsärmste Variante — zugegebenermaßen nicht die resourcenoptimierte. Alternativ ggf. 2 VMs, 1 als Offloader für das VLAN-71-Setup, 1 als Offloader mit Mesh-on-LAN für ein weiteres VLAN, in denen die Outdoor-APs landen.

1 „Gefällt mir“
8

Moin.

Also den Knoten hinzustellen und nie wieder anzuschauen, habe ich nicht vor. Ich interessiere mich dafür zu sehr für die allgemeine Technik dahinter. Wenns auch noch dauert, bei diesen mMn. exotischen Protokollen, tiefer durchzublicken.

Hmm, also br-client musste ich in der Konsole umbiegen. Aber Mesh-on-LAN liegt sowieso standardmäßig auf eth0. Das ist doch, was ich brauche? Theoretisch müsste ich doch auch damit in nen Switch gehen können (eigenes VLAN / eigener Switch) und daran so viele Gluon-Nodes anschließen, wie ich möchte? Ports also am besten z.B. per privateVLAN oder ACL isolieren?

Hat deine Empfehlung, zwei VMs zu nutzen, einen besonderen Grund? Wie schon gesagt, auf nen Produktivserver möchte ich aus Sicherheitsgründen nicht, und der Barebone wird sich wohl sehr quälen. Ausprobiert habe ich es allerdings noch nicht.

Alles in allem sind das schon ein paar Fragen. Sorry. :wink:
Vom Eröffnungspost sind auch noch diverse offen: z.B. was passiert (mit Freifunk) wenn die dynamische MAC-Tabelle voll ist, bzw. künstlich begrenzt wird? Sind alle diese MACs nötig, und wenn nein, lassen diese sich irgendwie schon gluonseitig eingrenzen/begrenzen?

Vielen Dank.
Michael

9

dynamische MAC-Tabelle

Freifunk ist meistens ein L2-Netz.
Du siehst also tatsächlich alle Clients im ganzen Netz bei dir am Ethernet-Port, bzw. alle Broadcast-Pakete von allen Nutzern.

Deine Switches lernen dann natürlich, dass hinter diesem Port mit dem Offloader die ganzen MAC-Adressen liegen.
Das Verhalten bei „voller“ MAC-Tabelle kommt nen bisschen auf deine Switches an, aber die meisten werden bei einer überlasteten MAC-Tabelle anfangen in einen Broadcast-Modus zu schalten und die Pakete auf allen Ports rausschieben. Quasi wie Hubs früher.
Das kann evtl. etwas unschön für dein Netzwerk sein.

Wenn du Freifunk mit eigenen APs ausstrahlst, musst du auch relativ genau auf die Airtime-Nutzung in den APs aufpassen.
802.11b sollte nach Möglichkeit komplett deaktiviert sein, die basic und multicast-Rates sollten erhöht werden (z.B. auf 12MBit/s oder mehr) und je nach verwendeter WLAN-HW evtl. noch andere Tricks.

Was setzt Ihr da an WLAN-Lösung ein?

Eine weitere Alternative wäre es, auf dem VLAN nur Mesh-on-LAN zu machen und dann noch eigene Freifunk-APs aufzuhängen, welche per LAN an diesem Mesh-on-LAN VLAN hängen.
Die Rechenleistung bringt dann die x86 Kiste auf und die Freifunk-Router sind nur simple APs.

Was du definitiv niemals machen möchtest, ist das Mesh-on-LAN auf einen WLAN-AP geben.
Das sorgt für eine Nutzung von so ziemlich aller verfügbaren Airtime und macht dir geländeweit das WLAN unbrauchbar/unbenutzbar.

Viele Grüße
Manawyrm

1 „Gefällt mir“
10

Hi,

also dass Freifunk Layer 2-Routing macht, ist mir ja schon bekannt. Die Switches laufen nicht voll, dafür sorge ich schon. Die meisten haben auch genug Kapazität. Mir gehts darum, was mit dem Freifunk-Netzwerk passiert.

Genauer gesagt: Ich habe testweise den Switchport am br-client auf „static only“ umgeschaltet und nur die Adressen des Freifunkrouters händisch eingetragen. Da geht nix, das ist klar. Dann habe ich eingestellt, dass der Switch lediglich auf besagtem Port 10 MACs dazulernen darf. Ab dann konnte ich ohne Einschränkungen im Freifunk surfen. Nun habe ich ja eine künstliche Begrenzung von 10 MACs. Ich vermute mal da waren zufällig Supernodes dabei, über die ich sowieso die Verbindung hergestellt habe. Spinnen wir weiter… Da nur 10 MACs in der Tabelle sind, dürfte ich doch vieles vom freifunkinternen Netz nicht erreichen. Also irgendwas wird nicht funktionieren(?). Getestet habe ich das aber nicht mehr, weil ich nicht vor Ort bin. Nehmen wir an, der Wert stünde auf Standardeinstellung, was 600 MACs pro Port sind. Ab 10 Uhr morgens ist dieser Wert erreicht und theoretisch dürfte nun wieder irgendetwas nach Zufallsprinzip im Freifunknetz nicht erreichbar sein. Versteht ihr nun was ich meine? Vielleicht mache ich mir ja auch unnötige Gedanken und wir kommen hier nicht weiter. Ich wundere mich nur, darüber im Netz garnichts zu lesen. Gesucht habe ich bereits…

Allerdings fällt mir gerade ein, ich wollte mal interne Dienste unserer Community aufrufen, und da war rein garnichts davon erreichbar. Ob das Wiki nicht gepflegt ist, oder ob es an mir liegt → keine Ahnung.

WLAN-technisch haben wir keine Probleme. Auch seit und mit Freifunk nicht.

Das sind HP M330 im Clusterbetrieb.
802.11b ist deaktiviert, Kanalbreite 2,4 GHz = 20 MHz, Kanalbreite 5 GHz = 40 MHz, Multicastrate steht auf Automatik. An was genau merke ich, dass ich diese höher stellen muss?

Wo ich die Airtime sehe, weiß ich garnicht. Ich finde die Oberfläche nicht all zu komfortabel.

Das ist gut zu wissen, denn irgendwann hätte ich das sicher mal ausprobiert.

Intern muss auch Freifunk über unsere APs laufen. Es gibt zu viele Räume, Stahl und Maschinen in den Hallen, um da noch auf die Schnelle etwas paralleles dazu zu bauen.

Also dann doch für die Straße zwei CPE210 an meinen bestehenden Offloader an eth0 wurschteln? Ich kauf einfach mal zwei und gucke was dabei rauskommt. Die Sache mit Mesh-on-LAN bzw. Mesh-on-WAN ist mir noch etwas suspekt. Bzw. Mesh-on-WAN verwirrt mich total. Ich bin gelernter Werkzeugmacher, bin kurz danach zum Mechatroniker mutiert und in den letzten Jahren eben auch noch zum Netzwerker. Mit Virtualisierung, Servern (Linux/Windows), IPv4 Routing, VLANs, und etwas IPv6 komme ich gut zurecht. Aber mit Freifunk und Mesh hatte ich nie etwas zu tun. Da ist einfach alles Neuland.

Danke und Grüße,
Michael.

11

Verstehe ich so nicht. Wenn man es macht, macht man es doch genau besser so als herkömmlich (das Wort ist für mich vollkommen von der Werbung versaut). Wenn ich überhaupt über Wifi meshen will, dann doch über MoL und separate AP-Paare (>>„WLAN Kabel“), weil man dann viel mehr Einfluss hat, was da genau passiert und welche Airtime genutzt wird (sprich Kanäle etc).

Normal liegt das Meshing per Wifi ja zwangsläufig bei single radio Knoten auf demselben Kanal wie das Client Netz und das ist das, was man vermeiden möchte. Wobei ich hoffe, dass kein broadcast traffic tatasächlich raus geht über das MeshIf, solange dem Knoten klar ist, dass da kein echter Meshpartner da ist. Also Meshing mal anbieten und dann ggf sofort bessere Abhilfe schaffen.

1 „Gefällt mir“
12

Wenn Du sie nicht geschenkt bekommst, besser keine CPE210. Lies hier im Forum noch mal genauer nach denen. Kaum Richtwirkung und zu unempfindlich. Und in Ballungsgebieten ist 2.4 eh tot und was draussen hängt, empfängt so viel anderes und hält daraufhin die Klappe, dass da nichts geht. Also ggf besser CPE510, wenn ich jetzt mal so bei der Linie bleibe, aber je nach Zielvorstellung gibt es sicher besseres, weil da ja nun gluon tendentiell wegfällt. Ich bin jetzt nicht sicher, welche 5GHz-fähigen gluon Geräte auch outdoor dürfen, bzw ob überhaupt.

13

Das ist nichts anderes, als dass das logische interne Mesh-Interface auf die Lanports bzw den Wanport gebridged wird oder eben nicht. Und das macht eben nur genau im spezifischen Bedarfsfall. Der Ottonormalknoten hat an blau bzw WANPort den Uplink/DSL Router und da ist das private WLAN/Wifi dran und da hat Meshtraffic nichts verloren (ausser Mesh-VPN eben, aber der ist komplett unicast zum VPN Server und das MoW Setting hat damit nichts zu tun).

MoW braucht man typisch dann, wenn zB Knoten kaskadiert, an gelb aber noch Client Lan aktiv hat. Dann kann man über blau mit dem Uplink Knoten dort an gelb meshen. MoW und Mesh-VPN schliessen sich also typisch aus, Da koennte auch gerne Wifi aus sein, weil das ein Knoten sein könnte, der nongluon-APs/Bridges versorgt.
(kleine Edits)

1 „Gefällt mir“
14

Hi,

das bringt Licht ins Dunkel. Man kann es sich auch komplizierter denken als es ist. Vielen Dank.

Also ihr habt mich überzeugt. Ich mache erst mal nix. Wenn jemand in der Nähe einen weiteren Knoten aufstellt, kann man immer noch schauen wie man diese am besten verbindet.

Grüße,
Michael.

15

Moin freifunker,

Ich hab mich gerade so grob rein gelesen ich erzähle kurz über mein Netzwerk. Ich selber hab ein offloader vm unter proxmox laufen und hab nur eth0 für mesh-lan und eth1 br-wan und eth0.10 clients.

Das war alles nicht leicht das ich mesh on lan und clients benutzen kann… Egal jetzt läuft es.
Selbst für den @Echtes_Schnitzel hab ich das Netzwerk so eingerichtet und er hat es fast gleich außer das der ein futro s550 hat sonst ist alles andere gleich.

So jetzt kommen wir zu der config vom switch für den wan ist ja klar, aber für das client Netz und mesh on lan nicht ich hab für mesh die vlan id 5 und hab auf den switch auch untagged gemacht und pvid auch auf 5 und sehe es läuft und hab auf den Port noch die id 10 auf tagged gesetzt und sehe da es läuft.

Wer hilfe braucht bei der Konfiguration stehe ich gerne zur Verfügung.

Gruß Erick

1 „Gefällt mir“
16

Hallo Erick, Hallo zusammen,
bin ganz frisch hier, gerne komme ich auf Dein Angebot zurück bei einer Offloader Installation unter proxmox zu helfen.:grin:
Ich stehe vor der scheinbar unlösbaren Aufgabe das ans Laufen zu bekommen.
Ich würde mich sehr freuen, wenn Du mir die Augen öffnen könntest.

Zu meiner Config:

DSL mit Fritzbox. Die Fritzbox hängt in der DMZ, gemeinsam mit einem Bein der PFSense Firewall. Dort terminiert auch eine vNIC der OffloaderVM „Freifunk“, bekommt auch eine IP von der Fritzbox und spannt, wenn ich die Konsole richtig interpretiere auch ein VPN erfolgreich auf. Die andere vNIC soll in ein VLAN „FreifunkWLAN“ in das meine Unifi APs ein Freifunk WLAN hinverbinden. Dort bekommt ein Client aber keine IP, auch ein virtueller Client auf der gleichen vmBridge nicht. Woran liegt das? Woran erkennt man die korrekte Funktion des node? Ich das entsprechende eth überhaupt als „client“ ausgewiesen? :unamused:

Ich hab da an der config geschraubt, bin aber nicht sicher ob das alles passt, da ich erst vor wenigen Tagen in den Freifunk Topf gefallen bin und vor 48 Stunden noch nie was von gluon gehört hatte. Ach fa, Firmware ist ‚2019080617-bet‘ - ‚v2018.2.2-1-g2280cb3‘ branch=‚beta‘
Aus Frust hab ich gestern erstmal einen WR841N bestellt um wenigstens damit einen ersten Node erfolgreich einzurichten. Aber den bekomme ich sicher auch woanders unter wenn das mit proxmox klappen würde. :wink:
Ich bin hier Dankbar für jeden Tipp!
Viele Grüße
Sebastian

17

Du ist kein Problem meld dich mal bei mir privat auf Telegram @haper99

18
  1. was sagt die VM auf der Konsole auf „batctl gwl“?
  2. Dir ist klar, dass Gluon während des Bootens teilweise mehrmals die Mac-Adresse ändert? Promisc-Mode („nicht gelockte Mac“) ist für die interfaces unabdingbar.

grafik

grafik
grafik854×458 72.3 KB

grafik
grafik706×328 20.9 KB

grafik

19

die VM auf der Konsole sagt:

2019-08-15%2021_58_49-Window
2019-08-15%2021_58_49-Window717×402 18.1 KB

und die vmbridges haben promiscous = on:

10: vmbr2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:26:55:df:6e:94 brd ff:ff:ff:ff:ff:ff
11: vmbr3: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:26:55:df:6e:97 brd ff:ff:ff:ff:ff:ff

2019-08-15%2022_01_40-Window
2019-08-15%2022_02_33-Window

20

Du hast keine gateways in reach!

bitte output von

ip a
brctl show

(und wenn Du ein „ping 8.8.8.8“ erfolgreich absetzen könntest, das wäre schonmal ein Anfang. Derzeit hat der Knoten offensichtlich gar keinen Internet-Uplink)

das wird auch der Output sein sinngemäß von

logread -f