Idealerweise würde Gluon die Option bieten, ein zusätzliches privates (verschlüsseltes) Netz aufzumachen.
Dieses Netz sollte dann
a) einenen lokalen DHCP-Server bekommen für v4
b) Internet per WAN direkt ausleiten
c) Die „lokalen Dienste“ im Heimnetz zugänglich halten (NAS, Drucker-Scanner, Webradio, Chromecast etc)
d) Freifunk-Domain & ICPVN über Freifunk herausrouten
Dieses Netz sollte optional an den Lan-Buchsen und/oder auf dem privaten (verschlüsselten) Wlan anstehen.
Vorteil wäre, dass man so auch als Freifunker das Netz (und die derzeitigen kümmerlichen „internen Dienste“ im ICVPN) mit den eigenen Endgeräten nutzen könnte, ohne auf die Errungenschaften der Embedded-Heimvernetzung zu verzichten.
(Ja, man kann sagen: „Geräte, die nicht sicher genug für Freifunk sind, die sollte man abschaffen“. Nur habe ich bislang keinen Drucker/Scanner gesehen, der vertrauenserweckend mit dem Thema „Verschlüsselung“ umgeht.)
Willst du wirklich das alles mit in der Firmware unterbringen? Der Platz kann sinnvoller genutzt werden.
Wen so etwas wirklich braucht der soll sie eine pfSense hinstellen die Internet übers WAN leitet, Freifunk über das FreifunkClientnetz und wenn das eingebe WAN nicht geht ein Fallback über Freifunk.
„alles“ ist ja nicht viel. Das sind meiner optimistschen Meinung nach nur ein paar IPFW-Zeilen plus noch ein wenig für die config.wireless. (die bei privatem wlan sowieso anfallen).
Der dhcp-server ist auch schon mit an Bord. Und vielleicht kann man den auch überflüssig machen, wenn man nicht natted, sondern zum wan bridged und das ip-v4-Routing ins icvpn/die lokale FF-Domain mit einem ebtables-Hack hinbiegt.
Also für ein Private WLAN was über den WAN-Port raus geht gibt es schon ein Paket in Gluon
Das routet allerdings nicht sondern bridged dieses Wifi Netz über den Wan-Port.
Siehe: Private WLAN — Gluon 2015.1.2 documentation
(Das klappt allerdings nicht zusammen mit Mesh-On-Wan)
Routing ins IC-VPN/FF-Netz wird nicht funktionieren da die Nodes keine IPv4 Adressen im Mesh haben und via Ipv6 ginge es nur mit NAT66. (Allerdings ist NAT66 wirklich nur für ganz wenige Einzelfälle zu nutzen)
Das meinte ich damit. Das Paket dürfte doch bei den meisten sowieso schon mit drin sein.
Deshalb schrob ich:
Das impliziert ein Masq/NAT. (unter normalen Umständen)
Die Erwähnung eines möglichen EB-Table-Hacks bezog sich nur darauf, dass irgendwer sonst um die Ecke kommen könnte, das NAT für überflüssig zu erklären (in Richtung WAN) , eben wegen der Möglichkeit, da ein Proxy-Gateway hineinzuschummeln, um eine Routing-Bridge zu bauen, die nur FF-Ziele nettes. (Oder alles umgekehrt, dann jedoch hakeliger wird mit der Sicherheit für das WAN)
Wie gesagt: ich wünsche mir das nicht. aber wer’s bauen mag, der soll’s tun. Ein privates-NAT-Subnetz mit Routing auf brwan und icvpn würde mir reichen. Und zumindest im Rahmen meiner Fähigkeiten (Und jetzt bitte nichts zu IPv6, das habe ich absichtlich ausgespart, um das Posting nicht noch unübersichtlicher zu machen. V6 Routen wird man auch announcen müssen. )
Achso, ich dachte damit meinst du einen zweiten Access Point.
Was V4 Zugang zum Mesh angeht: Dies wird auch mit Ebtables nicht funktionieren sofern die Nodes keine Mesh-weit erreichbare IPv4 Adresse haben. Irgendwie müssen die Pakete ja zurück kommen ob NAT oder nicht.
Evtl ist es möglich wenn die Nodes selbst DHCP und Gateway Funktionen bereitstellen (Distributed DHCP).
Natürlich könnte man auch Gluon beibringen sich selbst per DHCP eine IPv4 Adresse über das Mesh zu holen. Jedoch befürchte ich das sich das mit dem dnsmasq Setup beißen würde, das ist ja auch nur mit Tricks möglich das z.b. Fastd oder Tunneldigger den DNS Server des Wan-Ports nutzen.
Also als Fazit: Es ist möglich, allerdings nicht ohne größeren Aufwand bei der Entwicklung. Daher würde ich eher warten bis Distributed DHCP fertig ist ;). Dann lässt sich das Paket garantiert einfacher umsetzen da der Router dann schon eine IPv4 Adresse benötigt.
Solange sollte man die Private-Wifi Funktion nutzen, ich denke auch das dies für die meisten Leute ausreichend ist
So werden wir aber nie „Freifunk-Dienste“ ans Laufen bekommen. Wenn alle Freifunkenden daheim kein Freifunk benutzen wollen, weil sie ja dann nicht an "ihre Geräte"™ herankämen mit den Wish-Apps.
Andere Möglichkeit für Leute mit einem nicht völlig kastrierten Provider-Bundlerouter („Zwangsrouter“ war gestern):
Statische Route im BundleRouter eintragen für 10.0.0.0/8 eintragen mit Ziel WAN-IP des FF-Plasterouters.
Und dem FF-Plasterouter sagen, vom WAN her ins FF-Netz zu NATten.
Eine Config-Option dafür wäre praktisch, damit es auch diejenigen hinbekommen, die iptables nicht per Du&Du sind.
ob NAT oder nicht.