"Mesh over WAN" (ethernet) und simultan Internet/Supernode-Uplink

Problemstellung:
Unser Netz aus 4 Routern im gleichen Haus zerfällt häufig in eine Eimerkette, wobei es dann leider mehrheitlich über einen Middlenode „eth-internet“ geht.
Eigentlich schön, da die Clients sich auch einheitlich verteilen, sind ja 3 Router mit Internet.

Nur: die hängen alle am gleichen LAN. Aus Gründen der Performanz für „Zugriffe innerhalb des Hauses“ wäre es meines Erachtens effektiver, wenn die untereinander per Ethernet meshen würden.
Wenn ich es jedoch richtig verstanden habe, dann schliesst sich zumindest in der Webconfig das aus. Einer der Router verliert sogar gelegentlich komplett den Link zu seinen Nachbarn und steht dann (trotz nur 15m Luftlinie) funktechnisch auf einer Insel.

Daher die Frage
a) geht Mesh-via-WAN und VPN-Uplink gleichzeitig?
b) wenn ja, was gehört in die welche config-files?

Hängen die denn mit dem WAN Port alle im selben Layer2 Segment???

zu a) das soll laut der Entwickler problemlos möglich sein, sowohl VPN als auch Mesh-on-Wan zeitgleich zu nutzen

zu b) in der SSH Shell folgendes ausführen:

uci set network.mesh_wan.auto=1
uci commit

Damit ist es auch möglich die CPU Last des fastd zu offloaden. Kleiner Linux PC, der die fastd Tunnel aufbaut und auf der internen Netzwerkkarte batman aktiviert hat, dann die gluon nodes alle mit aktiviertem Mesh-on-Wan ohne eigene Tunnel dahinter.

Mesh-on-Wan ist übrigens auch offiziell supported und dort dokumentiert:

http://gluon.readthedocs.org/en/latest/features/mesh-on-wan.html

Das hatte ich auch gefunden. Nur machte mich stutzig, dass der Weboberfläche im config-Mode steht, dass man nicht VPN-Uplink und Mesh-On-Wan gleichzeitig aktivieren solle. „Würde keinen Sinn ergeben“ (muss ich nochmal nachschauen, habe gerade keinen freien Router hier zur Hand)

Ich denke mal das liegt daran das man Mesh-On-Wan eher dafür benutzt an einem großen VPN-Gateway mehrere Nodes per Kabel anzuschließen. Damit kann man mehr Bandbreite zur Verfügung stellen da man dort evtl. bessere Hardware hat die das VPN-Bridging übernimmt.

Naja, daran sollte es nicht scheitern, neben der Fritzbox steht da noch ein ein headless Ubuntu unter Xen, welches sich eigentlich ziemlich langweilt.
Nur die Internetanbindung ist halt „mal dünne“, also 16/0,8 MBit/s da Versatel und DTAG dort kein VDSL anbieten und Unitymedia nur mit unverständlichen Knebel-Bundles aufwartet, die nichtmal die eigenen Mitarbeiter verstehen (Routerzwang, 10MBit Upstream nur wenn man auch Telefonanschluss mit diversen Flatrates und Komfort-Optionen abschliesst)
Ach ja, und fixe IP ist mal auch nicht… als Exitnode taugt es also wahrlich nicht.

Hallo „Ingrid“:
Jetzt habe ich gefunden, was klemmt:

"Private WLAN" und „Mesh on WAN“ schließen sich aus.
Zumindest wird das private Wlan dadurch disfunktional.
Ob man das mit irgendeinem vlan-tagging lösen könnte: Übersteigt meine Kenntnisse.

http://gluon.readthedocs.org/en/latest/features/private-wlan.html
http://gluon.readthedocs.org/en/latest/features/mesh-on-wan.html

Brauchst Du denn da auch noch privates WLAN drauf?

Wenn’s „mesh on wan“ sinnvoll ist, dann würde ich gff. noch für das private WLAN den miesen Funk der alten Firtzbox wieder anschalten und den Buffalo-AP wieder in Betrieb nehmen. (ich hatte nur gehofft, mir den Strom sparen zu können.)

Warum privates Wlan? Weil da z.B. Drucker sind, die ihre Daten (weder Config, noch Druckdaten) verschlüsseln. Das muss ich nicht öffentlich durch die Gegend blasen.

Oder nen nas oder sonst was, das man nicht ins Internet stellen moechte

Naja man braucht keine 10Mbit Upstream und eine fixe IP auch nicht :slight_smile: Ich habe einen DS-Lite Anschluss bei Unitymedia und bin vollends zufrieden. Um die die Fritzbox von UM zu bekommen habe ich Telefon Plus gebucht, den fünfer im Monat verkrafte ich.
Was den Routerzwang angeht ist es natürlich ärgerlich aber auch verständlich. Bei DOCSIS liegen alle Geräte in einer Kollisionsdomäne und somit könnten bei modifizierten Kabel-Modems alle Frames der anderen Kunden mitgelesen werden. Es gibt noch andere Gründe die mir gerade entfallen :smile:

VPN & Co läuft bei mir über IPv6 (Außer Fastd von der Freifunk-Node, das läuft noch über IPv4), IPv4 ist einfach kaputt und sollte auch nirgens mehr bevorzugt verwendet werden. Es ist aus Provider sicht End-of-Life und wird für den Übergang zu purem IPv6 bei vielen Providern nur als DS-Lite für die Kunden bereitgestellt.

1 Like

Richtig cyrusfox

Endlich mal nen Forum mit normalen Leuten :slight_smile:

1 Like

Das meinte ich mit „Unitymedia baut nur völlig verzwickte Bundle“: „TR.069 ist Feindesland“, also WAN, d.h. alles was so eine „geschenkte Fritzbox“ bietet rühre ich nicht an, weil da jemand einen Zweitschlüssel hat. Aber ohne die MAC der Fritzbox kann ich den UM-Account gar nicht nutzen. Also könnte ich die FB nur auf Passthrough schalten (und könnte selbst den eingebauten Anrufbeantworter nicht nutzen, bräuchte also noch eine zweite FB mit DECT, ISDN etc)
Umgekehrt bekomme ich 10MBit/s Upstream nur mit besagter Telefonie. Und wenn man Telefonie hat bekommt man die Fritzbox, ob man will oder nicht. Gar keine Chance auf ein Modem (oder „DSlite-Router“).

Ich wage zu unterstellen, dass es UM mit seinen Angeboten gelungen ist, das „Magische Dreieck der Optimierung“ so zu optimieren, dass man nur zwischen den Ecken springen kann und die Fläche und Kanten komplett gesperrt sind. Man darf sich also bei 3 Kriterien immer zwei aussuchen, die im Angebot überhaupt nicht passen.

Aber zurück zum Thema: Wenn ein lokaler fastd irgendwie sinnvoll ist (und nicht nach außen erscheint bei NutzerInnen-Requests), dann würde ich den natürlich aufsetzen.

Kabelmodems funktionieren fundamental anders als DSL-Modems. Die Geräte müssen per Standard ihre Konfiguration vom Hersteller beziehen. Darunter fallen z.b. :

  • Down und Upstream Kanäle sowie die dazugehörige Bandbreitenkonfiguration
  • Betriebsmodus (DS-Lite oder DS-Full bzw nur IPv4 Stack bei alten Anschlüssen)
  • Telefonkonfiguration (Heute VOIP daher eher optional, früher eine Art enkapsulierter ISDN Kanal welcher natürlich sonst nicht genutzt werden konnte)

Die Settings können aus gutem Grund nicht auf der Kundenseite geändert werden da sonst der Kunde z.b. seine Down- und Upstreamraten selber definieren könnte oder die bereitgestellte IP Konfiguration selber vornehmen welches das ganze Netz stören kann.

Ein Kabelmodem ist letztendlich nur eine Ethernet-Bridge zum Carrier-Netzwerk und daher sind gewisse Einschränkungen notwendig um den störungsfreien Betrieb zu gewährleisten. Ähnlich wie beim Freifunk wo wir gewisse Pakete beim Übergang Node → VPN filtern müssen (Um was es sich handelt kann man im Source-Code nachlesen, ich werde aber noch mal einen Post dazu verfassen).

TR 069 hingegen ist ein Standard für DSL-Anschlüsse und wird bei Kabelmodems nicht verwendet. Der Support hat ausschließlich auf den Part des Modems Zugriff wo die Leitungswerte ermittelt werden, aber selbst das lässt sich abschalten und wird auf den Modems sogar geloggt ;). Natürlich kann Niemand garantieren das es nicht trotzdem irgendwie möglich ist, was aber theoretisch auch bei normalen DSL-Modems der Fall sein könnte oder hast du da Zugriff auf die Firmware? :wink:

Ich verstehe deine Bedenken gut und bin sicher auch nicht 100% damit zufrieden aber Backdoors können wirklich überall stecken und ab einem gewissen Grad müsste man ja nur noch den Kopf in den Sand stecken :smile:

DS-Lite ist wie oben beschrieben ein Betriebsmodus für die IP-Adressierung des Modems. Es steht für Dual Stack Lite. Sprich man hat einen vollwertigen IPv6 fähigen Anschluss und bezieht IPv4 über IPv6 durch einen so genannten AFTR Gateway, dies ist ein Tunnelserver der eine NAT-IP bereitstellt. Ergo man hat kein echte IPv4 Adresse und kann auch keine Ports von außen öffnen für Ipv4 Dienste. Dies ist aufgrund der Adressknappheit leider notwendig da die kleineren Provider keine IPv4 Adressen mehr übrig haben. Größere Provider wie die Telekom haben damals natürlich verdammt große IP-Blöcke bekommen und haben noch einige zu vergeben.

DS-Full wäre hingegen die Variante wo man IPv6 sowie IPv4 nativ vom Provider bezieht, also eine echte IPv4 und keine NAT-Ipv4 .

Ich hoffe das konnte ein wenig Licht ins Dunkel bringen :wink:

1 Like

Wenn ich dies setze, ist dann Zugriff WLAN->LAN moeglich? Also koennen die Leute ueber den Router in mein LAN gelangen? Da haette ich schon etwas dagegen, da ich auf jedem Rechner einen SSHd mindestens laufen habe + Tahoe-LAFS mit privaten Dateien.

Ne das heißt ja nur das Router auch über Kabel Mashen können. Normalerweise geht das nur über WLAN.

Prinzipiell ist es bei einem ISP so das der Router dein Bastionshost darstellt der dein Internes (Privates) Netz von dem öffentlichen Netz abgrenzt.
Bei FF ist es so das du ein großes Privates Netz siehst (IPv4) wo alles FF Teilnehmer gleichberechtigt miteinander kommunizieren. Auf IPv6 Ebene haste sogar offizielle IPs sodass du schon jeden einzelnen Host einzeln absichern musst.
Letzteres zählt natürlich auch für IPv4

Gruß
Thomas

äh ich brauche mal ein konkretes Beispiel, da Mesh on Wan auch für mich neu ist.
Korrigiert mich bitte wenn ich etwas falsches Ausspreche:

Ich baue ab Montag 2 Nanos und eine Pico aufs Dach…unten kommt dann ein switch und ein WDR3600 zum Einsatz.

Mein Gedanke war: Die Geräte oben übers Kabel meshen zu lassen. Den WDR3600 als fastd Internetpunkt zu verwenden

Verstehe ich das dann richtig, dass die Geräte vom Dach erst nach unten in den Switch kommen und von dort aus ein Kabel zum WDR3600 geht?

Dieser WDR3600 würde dann auch Internet zur Verfügung stellen

oder denke ich jetzt falsch?!
Ist das sinnvoll?
2., jedoch nicht so wichtige, Frage: wie könnte ich fastd auslagern?

Indem nur der 3600 fastd Tunnel aufbaut, batman auf den LAN Ports aktiviert wird und bei den Routern dahinter das Mesh on WAN aktiviert wird…

Exaxt so.
Auf den kleinen Geräten „mesh on wan“ ANschalten in der Expert-config. (speichern nicht vergessen)
Und „mesh vpn“ ABschalten auf der Hauptconfig-Seite.

Beim großen WR3900 alles ANschalten. (mesh on VPN, mesh on WAN)
Dem evtl. sogar die Wlan-Antennen wegnehmen, damit er gar nicht erst versucht, irgendwas via WLAN zu machen…
(sollte er aber auch so nicht.)

Ach ja, ohne RICHTIG manuelle Netzwerkkonfig kann das derzeitige Gluon auf Ethernet nur auf dem WAN-Port meschen, NICHT auf den LAN-Ports.

Ach ja, ohne RICHTIG manuelle Netzwerkkonfig kann das derzeitige Gluon auf Ethernet nur auf dem WAN-Port meschen, NICHT auf den LAN-Ports.

deshalb ja wohl der zusätzliche Switch.

das Einstellen geht per ssh?
was genau heisst „Geräte dahinter“? Sind nicht alle Geräte am switch angeschlossen?

also Mesh on wan + mesh vpn?