Mesh-VPN - wozu?

Hallo zusammen,

ich habe einen Freifunk-Knoten bei FFRGB auf gluon v2018.1.3 in Betrieb genommen und mir sind noch ein paar Sachen unklar.

Das Mesh-VPN ist dazu da, dass der Traffic im Freifunk-Client-Netz über ein Gateway geleitet wird - soweit klar. Ich frage mich jedoch die ganze Zeit wieso dann nicht einfach ein normaler VPN-Tunnel aufgebaut wird, sondern im ganzen „Layer 2“-VPN batman-adv aktiv ist?! Welchen Hintergrund/Vorteil hat das?
Wie ist das eigentlich bei IPv6? Man bekommt ja öffentliche IP’s zugewiesen, welche dann über das Gateway und VPN geroutet werden. Ändern sich die IP’s oder gibt es hier eine Nachvollziehbarkeit? (Störerhaftung)

Wozu gibt es das „primary0“, das „local-port“ und das „local-node“ Interface? Hierzu konnte ich auch nahezu keine Infos finden.

Vielen Dank im Voraus!!!

Beste Grüße

Tante G findet dazu eigentlich genug, ggf. auch bei libremesh.org; Kurzfassung daher: technisch bedingt muß hinter einer SSID ein Layer-2-Netz hängen, daher finden z. Zt. in Ein-SSID-Freifunk-Netzen überwiegend Layer-2-Technologien (d. h. B.A.T.M.A.N. Advanced) Anwendung.

Falls Du Filesharing über Deinen Knoten machst (direkt, nicht über einen Client an Deinem Knoten) und der ohne Privacy Extensions ins Netz geht, könnte man über diese aus der MAC abgeleitete IPv6-Adresse und öffentlich zugängliche Listen latent zu einem Standort kommen, und damit auf Dich als Störer. Da dies entsprechende Änderungen an der Konfiguration des Freifunk-Knotens voraussetzt, ist die Standardantwort also nein.

Hallo wusel,
danke für die Antwort!

Dass hinter einer SSID ein Layer 2 Netz liegen muss, ist mir bewusst. Mir ist nur nicht bewusst, warum in dem VPN batman-adv aktiv ist, wenn doch sowieso alles über das Gateway geroutet wird. Man könnte doch auch einfach mit Fastd/Gretap/L2TPv3 ein Layer 2 - VPN zum Gateway aufbauen und dann dann das jeweilige Interface in die Client-Bridge mitreinhängen, was genau den gleichen Effekt hätte?!

Man könnte auch ein Layer1-Netz dahinterhängen, hätte in Folge dann ebenfalls das gleiche Layer2.
(Wäre aber performanter, wie kommerzielle €€€-Lösungen mit Slave-Radios, die an zentralen Controllern hängen, die wirklich „live“ die Radios steuern.)

Dann sähen alle Clients nicht nur eine SSID, sondern auch nur eine BSSID. Dann hat der Radiocontroller die Meldung welches Radio welchen Client wie gut „hört“ und gibt dann den Befehl aus, welches Radio sich um den Outbound-Traffic zum jeweiligen Client kümmert.

Ist nur aus Latenzgründen mit unserer derzeitigen meshtechnik nicht machbar.

s/das Gateway/die Gateways — und dann probiere das geistige Experiment bitte noch einmal. Ferner hänge für jenes am mesh0-Interface eines Knotens K1 hinter Gateway G1 ein Knoten K2, der wiederum mit einem Knoten K3, welcher wieder einen eigenen Uplink zu Gateway G1 (wahlweise G2) hat, vermesht ist. Und an client0K1 und client0K2 sowie client0K3 hängen jeweils 1-4 Endgeräte. Bekommt das die Bridge auf den Gateways noch gebacken? (Abgesehen davon, daß ein Bridging Wired<>Wireless nicht funktioniert.)

Aus meiner Sicht bildet batman-adv.ko quasi die Control-Plane, mit der das ganze Konstrukt erst zum verteilten Switch wird.

Oder man simuliert den Layer 2 hinreichend funktional für typischen Web-Traffic, indem man auf Layer 3 die notwendigen Vorkehrungen trifft (DHCPv4 & /32-Routing & NATv4, kein IPv6); beides ist aber nicht das Thema :wink:

Das auf Layer-2 basierende Batman-Protokoll ermöglicht es, seine IP-Bereich stadtweit (oder wie groß das Freifunknetz räumlich eben ist) mitzunehmen und so zu roamen, ohne dass Layer-3 (IP) Verbindungen abreißen.

Mittelfristig wird wohl auf das Layer-3-Protokoll Babel umgestellt.

Grüße
Matthias Walther

Genau das ist das was ich meine. Theoretisch könnte ich mir mein virtuelles Layer 2 Netz doch auch ohne Batman hochziehen?! Wenn batman-adv im WLAN aktiv ist, dann ok, es wird ja auch gemeshed, aber im VPN geh ich ja nicht über andere Hops sondern sowieso immer erst über das Gateway:

   Originator        last-seen (#/255) Nexthop           [outgoingIF]
 * 16:06:09:2e:c7:ff    4.440s   (250) f2:00:90:00:21:11 [  mesh-vpn]
 * 4e:40:d6:3d:e3:a3    0.090s   (250) f2:00:90:00:21:11 [  mesh-vpn]
 * aa:8c:87:da:af:bb    0.270s   (250) f2:00:90:00:21:11 [  mesh-vpn]
 * 5e:5c:9e:2c:a9:cb    0.090s   (246) f2:00:90:00:21:11 [  mesh-vpn]
 * ba:71:ef:7d:2d:63    0.490s   (203) f2:00:90:00:21:11 [  mesh-vpn]
 * 1a:39:ae:db:47:1b    0.700s   (249) f2:00:90:00:21:11 [  mesh-vpn]
 * 4e:6a:04:0b:dc:5b    2.220s   (250) f2:00:90:00:21:11 [  mesh-vpn]
 * ea:eb:09:74:ba:33    0.990s   (250) f2:00:90:00:21:11 [  mesh-vpn]
 * 6a:84:7b:4f:31:63    2.460s   (250) f2:00:90:00:21:11 [  mesh-vpn]
 * 3e:2f:ef:a3:3f:f3    2.830s   (248) f2:00:90:00:21:11 [  mesh-vpn]
 * 3a:83:4f:7f:34:13    1.930s   (235) f2:00:90:00:21:11 [  mesh-vpn]
 * 86:f2:74:7a:de:43    0.340s   (235) f2:00:90:00:21:11 [  mesh-vpn]
 * aa:4d:c6:7a:9f:27    5.050s   (250) f2:00:90:00:21:11 [  mesh-vpn]
 * 0a:b7:fa:0c:2f:c7    1.010s   (250) f2:00:90:00:21:11 [  mesh-vpn]
 * fe:79:5d:a2:f6:0b    0.180s   (193) f2:00:90:00:21:11 [  mesh-vpn]

Beispiel:
Ich zieh einen Wireguard-Tunnel zwischen meinem Router und einem Gateway auf, anschließend erstelle ich zwei Gretap-Interfaces, die über den VPN-Tunnel kommunizieren. Zu guter Letzt bridge ich noch die Gretap-Interfaces (von mir aus auch mit VLANS) mit meinen LAN-Ports (eth0) -> fertig ist der transparente Layer 2 Tunnel, der wie rein wie ein Switch fungiert.

Gruß
Markus

Der dann nur keinerlei Bewertung der Linkqualität (abgesehen von „da oder nicht da“) vornimmt.
Ausserdem ist OSPF noch schlechter bei 100+ Switchen skalierend als Batman.

Sprich: Ja, es gibt viele verschiedene L2-Meshprotokolle. Batman-advanced ist nur eines von vielen möglichen. Aber nach derzeitigem Stand eines, was trotz eines Zeroconf-Ansatzes wenig Bandbreiten-Overhead produziert und mit Loops/redundanten Links stark unterschiedlicher Qualität einigermaßen zurecht kommt.

1 Like

Ich weiß, dass das langsam off-topic wird, aber dauernd liest man soetwas und ich frage mich: Woher kommt diese Aussage? Worauf basiert sie? Und wer entscheidet das für „alle“ ?

Du hast die Frage etwas zu plump ignoriert, daher wiederhole ich sie:

Ersteres wohl von Entwicklern, die die Grenzen von batman-adv leid sind und neue dornige Chancen suchen. Letzteres die Entwickler in Form der normativen Kraft des Faktischens, sprich: Gluon v20xx.

@mm93 Ja, du hast grundsätzlich recht, denn Linux-Bridges „lernen“ an welchem Netzwerkdevice ein Teilnehmer mit einer bestimmten MAC-Adresse hängt wie ein vernünftiger Switch und nicht wie ein Hub. fastd lernt ebenfalls an welchem „peer“ eine MAC-Adresse hängt. Wenn du also nicht zusätzlich Meshverbindungen zwischen deinen Supernodes aufbauen möchtest (was du aber meistens möchtest, um das ganze Netz skalierbar zu machen und Redundanz einzuführen), kannst du also eine normale Bridge nutzen bzw. einfach forwarding bei fastd aktivieren.

Vielen Dank für die vielen Antworten!

Aber sehe ich das richtig, dass im Mesh-VPN nur noch zwischen den Supernodes gemeshed wird? Die normalen Gateways haben ja, wie man eben mit „batmanctl o“ sieht, immer nur das gleiche Gateway, welches sich im Fall der Fälle, z.B. bei einem Ausfall ändert?!

Wenn jemand aus Community X das sagt, meint er wohl Community X :grinning:.

2 Likes

Das ist dafür da, dass du Teilnehmer im Freifunknetz erreichst, die durch eine andere Supernode erreichbar sind. Das könnte man auch durch Routing erreichen, wenn sich nicht die Subnetze überschneiden würden. Denk immer daran, dass fast jede Community ein anderes Setup hat…

Im Freifunk Rheinland ist es häufig so, dass die Supernodes einer Community mit iBGP an das Rheinland-Backbone angeschlossen sind. D.h. alle Supernodes teilen sich ein /64-IPv6-Netzwerk. Die Clients sind sozusagen alle im selben Subnetz und jede Gateway kann den Traffic jedes Clients ins Internet routen. Das ist da keine Heim- oder Firmennetztechnik mit NAT usw. Das ist Teil eines autonomen Systems. Wenn du jetzt mit einem Client an einer anderen Supernode kommunzieren möchtest, müsstet ihr in verschiedenen Subnetzen sein (dann würde Roaming nicht mehr funktionieren), um das zu routen oder es müssten /128-Routen für jeden einzelnen Client gesetzt werden, die auf die korrekte Supernode zeigen (so macht es Babel). Im Fall von Layer 2-Batman-Netzen ist Batman das Routingprotokoll.

3 Likes