Ich möchte einem Rechner in meinem Heimnetz (kein Vlan Tagging) ein Bein/einen Weg ins Freifunk-Netz geben. Der Rechner hat nur einen Netzwerkport, ich kann ihn also nicht einfach mit einem zweiten Kabel an den Freifunkrouter stecken, und er soll auch im Heimnetz verfügbar bleiben. Da wäre also irgendwie Policy-routing zu machen, das sollte ich hinbekommen.
Im Heimnetz wohnen zwei Freifunk-router, ein abgängiger 841 und ein DAP-X1860 mit ebenfalls nur einem Netzwerkport. Auf dem Heimnetzrechner kann ich auch ne Menge schweinereien machen, docker oder Virtualisierung ist möglich.
Was wäre aus eurer Sicht die einfachste Variante das zu realisieren?
Was heißt »in meinem Heimnetz (kein Vlan Tagging)«, daß Du in Deinem Netz keine VLAN-fähigen Switche hast oder daß Du derlei bislang nicht nutzt?
Wenn Du weder ein zweites Interface noch Switche hast, die das Freifunk-Netz als VLAN 815 Deinem Rechner im Heimnetz darbieten können, müßtest Du Heim- und Freifunknetz direkt verbinden, damit Dein Rechner im Heimnetz (auch) ins Freifunknetz kann. Hiesse im Umkehrschluß aber auch, daß jedermensch in betreffenden Freifunkmesh durch entsprechendes Routing in Dein Heimnetz gelangen kann und daß Deine ZeroConf-Geräte im betreffenden Mesh ihre Präsenz artikulieren.
Definitiv USB-Ethernetadapter, daran das LAN eines Freifunk-Knotens. Alternativ: Gluon-VM auf dem Rechner im Heimnetz, über virbr0 (libvirt-»default«-Netzwerk) geht die VM ins Internet, über br0 hängt der Rechner im Heimnetz im Freifunk-Netz.
Danke. Mittlerweile habe ich unter grossen Schmerzen eine Lösung hinbekommen.
Unser generic image habe ich in eine kvm gesperrt und mit br-wan in meinem Heimnetz und br-client in einem seperaten Netz. Auf demselben Host habe ich einen docker Container der ein bein im br-client hat und sich per DHCP eine IP geben lässt.
Zumindest habe ich etwas über docker, netze und unser Freifunk-Setup gelernt.
Klar, »viel Spaß am Gerät« und so, aber wäre ein USB-Ethernet an 841-Gelbport nicht einfacher gewesen? Bzw., wenn der Rechner ins Freifunk-Netz soll, warum läßt Du nicht dhclient auf der hostseitigen br-client-Bridge – virbr0 ist IIRC die KVM-Standard-Bridge, also br-wan in der VM, das br0-IF wäre in der VM dann in br-client, oder? – laufen statt des Umwegs über den Container? Aber solange es das tut, was es soll:
Ich muss an dieser Stelle auch zurückrudern, derzeit tut es noch nicht vollständig was es soll.
Ich finde auch keine vernünftige Doku um einen Offloader aufzusetzen, das rumprobieren hat mich sicherlich einige Stunden gekostet. Alleine zu verstehen in welchem Verhältnis eth0, eth1, dummy0, br-client, br-wan, local-port@local-node, local-node@local-port, bat0. primary0 und mesh-vpn zueinander stehen ist ein brainf*ck.
Wo es nun immer noch hakt ist alle Player (Host, VM und Container) so zu konfigurieren das die, die miteinander reden können müssen, das auch tun, und dabei auch keine Kolleteralschäden produzieren.
Zu deiner Anmerkung: klar wäre es einfacher den Host über eine weitere Netzwerkkarte zu gehen, aber das habe ich grad nicht da. Deine restlichen Anmerkungen verstehe ich gerade nicht.
Offloader ist an sich simpel: das 1. VM-Interface wird zu eth0 der VM und landet landet als LAN-Port in br-client in Gluon, man fügt ein 2. Interface der VM hinzu, eth1, das ist WAN in Gluon und landet entsprechend in br-setup bzw. im Freifunk-Modus in br-wan. Tricky: dies muß AFAIK vor dem ersten Start der Gluon-VM geschehen sein, da beim sog. first-boot die Interfacekonfiguration ein für alle Mal erstellt wird (Ausnahme mögen USB-WAN-/-WWAN-Packages sein),
Schnipsel aus der XML einer meiner VMs — finde leider die virt-manager-Screenshots nicht wieder
<source network='default'/> steht hier für virtbr0, die NATende Standardbridge bei KVM; könnte man entsprechend auch direkt angeben wie br0 in der Definition darüber (dann natürlich als bridge und nicht network, falls man das XML selbst schreibt).
Auf dem KVM-Host sieht das dann z. B. so aus:
root@cohen:~# brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.8a058cb92655 yes vnet4
vnet6
root@cohen:~# brctl show virbr0
bridge name bridge id STP enabled interfaces
virbr0 8000.525400f717f8 yes vnet41
vnet44
vnet48
vnet5
vnet56
vnet7
Auf (u. a.) br0 liegt bei mir das (ein) FF-Netz an, wenn ich dhclient drauf losliesse auch mit IPv4 und ggf. Defaultroute …
root@cohen:~# ip addr show br0
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 8a:05:8c:b9:26:55 brd ff:ff:ff:ff:ff:ff
inet6 2001:bf7:1310:28:8805:8cff:feb9:2655/64 scope global dynamic mngtmpaddr
valid_lft 86381sec preferred_lft 14381sec
inet6 fd10:ca1:28:0:8805:8cff:feb9:2655/64 scope global dynamic mngtmpaddr
valid_lft 86316sec preferred_lft 14316sec
inet6 fe80::8805:8cff:feb9:2655/64 scope link
valid_lft forever preferred_lft forever
That said: 4830.org-Gluon-Offloader ist eigentlich simpel:
VM mit 2x Ethernet vorbereiten, 1. Interface kommt auf Bridge, auf der FF-LAN weiterverteilt werden kann, 2. Interface kommt auf Bridge, an der WAN mit DHCP vorhanden ist (normalerweise virbr0/Default Network)
Auf der Bridge des 1. Interfaces oben liegt FF-LAN an
Was intern in der Gluon-VM passiert, muß Dich nicht interessieren, das ist alles plug’n’play, ›links‹ kommt WAN rein, ›rechts‹ Freifunk raus, wie beim 841er mit ›links‹ gleich ›blau‹ und ›rechts‹ gleich ›gelb‹.
Wenn es Dich interessiert, be my guest, aber das ist ein anderes Thema. (OpenWrts Networking und Gluons Config-Framework oben drüber ist keine leichte Kost, IMHO. Das beginnt schon mit WAN und WAN6, diese künstliche Trennung bekomme ich regelmäßig nicht in mein Hirn rein … Und Gluon hat die Besonderheit, daß eine IPv4 und/oder IPv6-Adresse auf allen Knoten identisch ist und mittels Klimmzügen nur für lokale Clients gangbar gemacht wird. Spezialwissen, was man nie mehr braucht, so wie die Berechnung des cos phi ;-))
