Technische Details zu Mesh on WAN (Batman). Ports? Verbindungsaufbau?

Hallo zusammen,

wir haben ein Haus mit mehreren Knoten, bei denen Mesh on WAN aktiviert ist.
Ein Server kann in einer Testphase mit virtuellem VPN-Offloader (MeshOnWAN → fastd → Gateway) betrieben werden.
Dieser Server steht zur Zeit jedoch in einem anderen Netz. Um nicht alles umbauen zu müssen, interessiert mich, wie der Verbindungsaufbau von MeshOnWan funktioniert. Eventuell kann ich bei den vorhandenen Routern/Firewalls passende Einstellungen ohne Umbau vornehmen. Leider konnte ich keine Infos finden. Hat jemand einen Link, oder kann schnell zusammenfassen, wie batman die Verbindung aufbaut. Wie suchen die Knoten neue Partner, und wie kommunizieren Sie nach Verbindungsaufbau?

  • Broadcasts? oder andere Technik?
  • Genutzte Ports / Protokolle?

Im Endausbau kommt der VPN-Offloader in das gleiche Netz wie die 16 Knoten.
Eine Routinglösung würde mir während der Testphase SEHR viel Arbeit ersparen.

Vielen Dank.

MeshOnWAN ist kein Tunnel etc., es ist BATMAN per Kabel, ein Routing-Protokoll

MeshOnWan arbeitet auf Layer 2 (batman-adv), es muss also alles zwingend im gleichen Segment liegen.

Danke für die Antworten.

Die zwischen den Netzen liegende Firewall ist sehr Leistungsstark.
Ich kann das Knoten-Netz als „secondary“ mit auf das Server-Netz legen. Somit wird hier nicht geroutet sondern es liegt alles im selben Segment, aber dennoch kontrolliert die Firewall zwischen den „Netzen“ (Die nur noch ein Netz sind). Boadcasts etc. landen auch beim Server.
Das ganze hat in einer ähnlichen Situation schonmal geklappt.
Ich kann es aber nicht „offen“ lassen. Aus Sicherheitsgründen ist das nur denkbar, wenn ich an der Firewall dazwischen Regelwerke baue. Dafür muss ich wissen, was genau technisch im Hintergrund passiert.

Wie genau läuft die Kommunikation zwischen den Knoten bei MashOnWan / Batman? Schmeißt mich gerne mit Techdokus zu :wink:

1 Like

Doku ist hier, die ist aber für deinen Einsatzzweck vermutlich zu lückenhaft:

Genauer kriegt man das wohl nur aus den Implementierungen…

Wichtig sind da wohl: http://www.open-mesh.org/projects/batman-adv/wiki/Packet-types
Und: http://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/packet.h#l21

1 Like

Danke. Ich tauche dann mal ab ins Thema und werde den VPN-Offloader in den nächsten Tagen online bringen. Ich schreib dann hier, wie es geklappt hat.

Das Netzwerk Segment für Mesh-On-Wan muss auf jeden Fall ein eigenes Netzwerk sein. Die Batman-Adv Frames werden über das ganze Netzwerk verteilt. z.b. auch andere Wifi Netzwerke. Zwar kann man dadurch dann nicht in das interne Netzwerk einbrechen (Ist ja logisch getrennt) aber ein WiFi AP könnte dann nur durch den Batman-Adv Traffic unnutzbar sein.
Also drauf achten das es ein eigenes VLAN oder dediziertes Netzwerk Segment ist.

1 Like

Ich würde eher den Ansatz wählen, den Batman-Traffic („Mesh-on-Lan/Mesh-on-WAN“) in ein eigenes Vlan zu sperren.

Ob man im Gluon das inzwischen update-fest einstellen kann, dass MeshOnWan auf einem Vlan liegt: Keine Ahnung.
Ideal wäre sowieso, wenn das im expert-mode auf Lanbuchsen geschaltet werden könnte.

Nach etwas Einlesen und anfänglichen Tests war schnell klar, dass es nicht mal eben umsetzbar ist. Wir haben jetzt als Alternative einen WR1043ND v2.1 besorgt, der ausreichen Leistung für den 16.000 DSL als VPN-Offloader hat. Daher kann ich den Server so lassen wie er ist.
Leider habe ich dadurch auch keine Erfahrungswerte, BestPractice oder Lösungsweg für euch…außer, dass es nicht schnell umsetzbar ist :wink:
thread = closed

Um mal mit ein paar Misverständnissen aufzuräumen, die hier immer wieder durch das Forum geistern, wenn es um das „Allheilmittel VLAN“ geht…

Ja, mit VLANs kann man schöne Sachen machen, und LANs prima trennen.

Was nicht geht, ist ein Mesh-radio zu bridgen, darum macht es auch keinen Sinn, jedem Meshknoten, ein eigenes VLAN zu zu ordnen.

Auf Mesh-Knoten muß unbedingt BATMAN laufen!

Daran führt derzeit unter Linux kein Weg vorbei - Punkt!..und im LAN ist der Zusatztraffic durch BATMAN erstmal nicht so wild.

Dem kann man ggf. durch ein eigenes separates Freifunk-LAN entgegen wirken, und hier sind auch VLANs extrem hilfreich. (bei richtiger Planung!)

Ein eigenes VLAN mit eigenem Batman-Interface (batX) macht nur dann Sinn, wenn man mit geeigneter Hardware transparente Linkstrecken zwischen Nodes baut, da man so die Bandbreite des Link nicht mit unnötigen Traffic belastet.

Das alles hat bis zu diesem Punkt gar nichts mit dem fastd-Offloader zu tun.

Ein fastd-Offloader ist unter debian schnell aufgebaut, und selbstverständlich läuft darauf dann auch BATMAN.
Wenn man weis, was man tut, ist es auch relativ egal, ob die Plattform ein RaspberryPi , oder eine X86-Plattform ist.

Dieser ganze Gluon-x86-Hype ist in meinen Augen Mumpitz!

Das Image ist für Developer gedacht, um auf dem PC eine möglichst ähnliche Umgebung zum OpenWRT abzubilden, aber nicht für Produktiv-Einsätze.