Hallo.
Ich habe hier ein seltsames Phänomen beobachtet, welches ich mir nicht erklären kann.
Zum Setup:
Wir haben hier ein kleines Mesh aus Routern, die per NS5 verbunden sind. Die NS5 (mit orig. Firmware) hängen jeweils am Mesh-on-LAN.
Drei Router bauen dabei lokal eine eigene VPN-Verbindung auf.
Das Problem:
Wenn die Router untereinander nicht per MoL verbunden sind, benutzt jeder seine eigene VPN-Verbindung (logisch).
Sobald die Router per MoL verbunden werden, fangen einzelne an, ihren gesamten Clientverkehr über einen entfernten Router abzuladen, obwohl laut batctl die eigene VPN-Verbindung als Gateway ausgewählt ist.
Wie man sieht, ist mesh-vpn als Gateway ausgewählt. Wenn ich mir aber den tatsächlichen Datenverkehr an den Ports anschaue (per Trafficmonitor auf dem WAN-Router bzw. der Nanostation) sehe ich, dass in Wirklichkeit der Verkehr über eth1, d.h. MoL, raus geht!
Wenn ich das entsprechende Kabel für MoL am Router ziehe, geht nach ein paar Sekunden der Verkehr wieder über mesh-vpn. Stecke ich ihn wieder rein, gehen die Daten über MoL raus.
Warum? Kann mit das jmd erklären?
Laut batctl ist IMMER primär mesh-vpn ausgewählt, in Wirklichkeit geht alles über MoL raus. Sogar lokal am Router eingebuchte Clients werden umgeleitet. Auf dem Vpn-Port ist nur noch das Grundrauschen zu sehen.
Ganz so ist es nicht, ich versuche das mal an einem Schaubild zu verdeutlichen.
Wir haben zwei Standorte (4900er und Filip) die sind je per Mesh VPN an einen der beiden Fichtenfunk Supernodes angebunden und untereinander per Mesh ( hier Mesh on lan über eine WLAN Strecke mit Ubiquiti Software).
Szenario 1
Endgerät verbindet sich mit dem 4900er bekommt eine IPv4 per DHCP und als Gateway die IPv4 Adresse von Fichtenfunk 01 (10.224.8.1) da der 4900er mit diesem verbunden ist. Der Traffic fließt den blauen Pfad im Schaubild.
Szenario 2
Endgerät verbindet sich mit einem Router, das als Gateway Fichtenfunk 02 nutzt, z.b. Filip, dann bekommt es als Gateway die Adresse von Fichtenfunk 02 eingetragen (10.224.16.1).
Nun wechselt das Gerät an einen Knoten der mit Fichtenfunk 01 verbunden ist (4900) doch hat weiterhin Fichtenfunk 02 als Gateway, dadurch wird der Traffic nicht von Fichtenfunk 01 direkt ins Internet/FFRL Backbone geleitet sondern geht ersteinmal über die Fastd Backbone Links zwischen den Supernodes zu Fichtenfunk 02. Dieses Problem haben wir schon eine Weile im Auge, da dadurch eine Menge unnötiger Traffic auf Tap1 zwischen den Supernodes entsteht (bei uns aktuell 1TB im Monat).
Szenario 3
Wie bei Szenario 2 nur, ist jetzt der 4900er per MeshOnLan mit Filip verbunden und es gibt einen weiteren Weg zu Fichtenfunk 02 im Schaubild Rot dargestellt. Aus welchen Gründen auch immer bevorzugt Batman diese Route, auch wenn sie langsamer ist als der eigene VPN Tunnel und der anschließende Sprung zwischen den Servern.
Zu Szenario 3:
Auf euren Supernodes wird ja eine gewisse Hop Penalty gesetzt sein. Hintergrund ist, dass, wenn es möglich ist, der Traffic ja im (W)LAN-Mesh bleiben soll und nur wenn es nicht anders geht, soll er über VPN gehen.
