Wir finden Freifunk toll und hatten die Idee mitzumachen.
Wir haben überlegt in unserer Firma Freifunk einzurichten mit all unseren Accesspoints. Dafür haben wir eine VM eingerichtet und die „gluon-ffac-2016.2.7-1-stable-x86-64-vmware.vmdk“ als Platte angebunden.
Die VM selbst hat zwei Netzwerkkarten im selben VLAN(30).
Die Karte für WAN(ETH0) soll eine statische IP haben und direkt zum Gateway(Einer Firewall mit Kabelanschluss) weitergeleitet werden.
Die andere Karte (ETH1) wird als Gateway für die Clients dienen die dahinter ins Netz kommen. Diese kommen über 5 Accesspoints direkt in das VLAN.
Nun haben wir folgendes bereits geschafft.
Die VM hat über ETH0 den WAN Anschluss. Sie kommt damit ins Internet und die Informationen für die Node erscheinen auch mit dem vorher definierten Namen auf der Freifunk Karte.
1 Client der in das VLAN kommt, bekommt eine IP-Adresse aus dem Freifunk Default Segment: 10.5.12.11 mit dem Gateway 10.5.0.4. Die IPv6 Adressen schreib ich hier nicht auf. Dieser Client taucht auch als Client auf der Karte unter dem Node auf.
Das Problem allerdings: Leider kann dieser aber nicht ins Internet. Er kann nicht mal eine Node pingen. Ich habe im Gluon-wan-dnsmasq sämtliche Default Supernodes und aus der Umgebung als DNS eingetragen.
Wir haben auch überlegt, das ganze etwas besser zu gestalten, indem wir die Netzwerkkarten auf unterschiedlichen VLANs aufsetzen. Sodass das eine nur die Clients und das andere nur die WAN Verbindung hat.
Ich würde vorschlagen, erstmal mit einem „einfachen“ Router zu üben.
Die Beschreibung des Fehlers hört sich jedoch mehr nach einer Störung im Freifunk-Netz/der Domain an. (Insbesondere dass DHCPv4 funktioniert, der Supernode aber nicht anpingbar ist.)
Wie üblich, auch in diesem Thread der allseits(?) bekannte Link ins Wiki.
Bitte arbeite doch mal diese Diagnose-Liste ab und schildere was dabei herauskommt:
VMware hat ein paar Fallstricke. So muss zum Beispiel der promiske (promiscuous) Modus aktiviert werden, weil sonst die Pakete beim Empfang geblockt werden, wenn sie mit einer fremden Ziel-Mac ankommen.
Die zweite Netzwerkkarte ist die WAN-Netzwerkkarte die ans Internet angebunden werden muss (per NAT reicht). An der ersten muss LAN-Mesch deaktiviert sein. Dann das entsprechende VLAN auf den WLAN-Kontroller legen.
Wichtig ist, dass hier auch IPV6 durchgelassen wird und nicht im DHCP interferiert wird.
Etwas unschön an eurer Lösung ist leider, dass man dann gar nicht vor Ort meschen kann, weil das die normalen, proprietären Accesspoints nicht können. Daher ist die Lösung mit einem Hardwarerouter meist schöner (aus Freifunk-Sicht) und auch erfahrungsgemäß weniger wartungsintensiv, weil die Dinger einfach laufen und sich nichts verstellt.
Alternativ kann man auch einen Außenrouter mit Freifunk installieren. Das ist aber natürlich etwas aufwändiger.
Der Knoten müsste ja dann eigentlich korrekt Funktionieren. Nur die Clients spinnen anscheinend.
Anhand der Diagnose-Liste kriegt ein Client die korrekten Adressen vom DHCP aber danach, sieht es so aus, als ob er nicht nach draußen findet. Pings und Tracerts zu sämtlichen Nodes laufen ins leere.
Als ob die Clients nicht wüssten, welches Gateway sie beziehen sollten.
Habe mir mal den günstigsten Router bestellt, der für Freifunk Software freigegeben ist. Mal schauen ob ich mich damit, das ganze besser verstehe. Die Idee bei einer VM wird dennoch bleiben. Das machte das ganze einfacher für die 5 APs die dahinter angesteckt sind.
Hallo,
wir haben auch immer Dienstags unseren Beratungstisch:
Wenn du Zeit hast können wir von dort aus mal gemeinsam remote auf die Sache drauf schauen. Wir haben auch ein paar andere Freifunker die es mit VMware ihren Knoten Betreiben.
Bei den VMware Images wird es demnächst noch einen Fallstrick bei den Autoupdates geben, daher empfiehlt es sich hier nicht die stable, sonder mindestens die beta zu verwenden. Die Image Größe wurde von openWRT erhöht, das ist auch sinnvoll, erfordert aber leider bei VMs eine Neuinstallation.
Vielen Dank, aber das wird nicht mehr nötig sein. Wir haben die Lösung gefunden. Wie MPW gesagt hat, musste der promiscuous Modus im vSwitch aktiviert sein. War er auch, aber nicht für das virtuelle Netz selber. Ein Knopfdruck und alle Clients feiern nun das Internet.
