Gluon ohne VPN benutzen


#1

Hi,

ich bin in der Domäne Albufer vom Freifunk Rheinland aktiv und wir benutzen eine sehr gering angepasste Firmware direkt aus den Gluon und OpenWRT Git.
Unsere site.conf findet man hier.

Ich betreibe einen Bullet M mit TL-ANT2415D und leuchte damit einen gesamten Marktplatz in Karlsruhe aus. An diesem sind mindestens 2 Nodes ohne direkten Uplink angeschlossen, Internet kommt also nur über meinen Bullet M.

Mein Ziel: möchte gern den Traffic direkt aus meinem heimischen Anschluss heraus leiten, ohne die VPN Verbindung zu unseren Supernodes zu benutzen. Dazu sollte jedoch Alfred noch funktionieren, sodass Freifunk Nutzer den Node auch auf der Karte finden und man im Graphen auch weiterhin die Infos des Nodes findet. Als Bonus wäre es praktisch, wenn auch weiterhin das IC-VPN funktioniert, aber das ist kein Muss, es wird quasi gar nicht benutzt.
Auch die angeschlossenen Nodes sollen keine VPN Verbindung mehr herstellen.
Zu Hause steht mir eine Fritzbox 6360 Cable zur Verfügung in der ich /16 für DHCP reservieren kann. Ich habe bei KabelBW/UnityMedia ein “richtigen” Dual Stack, erhalte neben einer festen IPv4 auch ein /56 IPv6 Subnet.

Ich habe gehört, dass dies in manchen Communities schon realisiert wurde, nur finde ich keinen Ansatz.

Kann mir jemand einen Tipp geben wie ich hier am besten vorgehe?

Hinweis: Ich möchte keine Debatte darüber wieso das Setup so sein soll, es gibt Gründe die ich zu verantworten weiß und will.

Grüße,
coacx


#2

Tuen sie sowieso nicht


#3

Als ersten Gedanken würde ich die VPN Verbindung weiter bestehen lassen, damit die mesh Funktionalität erhalten bleibt. ZB IC vpn sprachst du ja selbst an.

Angepasst werden müsste also lediglich ein routing auf dem gluon AP.

Wer weiß folgendes:
Kann man in gluon auf das lokale LAN und damit den lokalen Router umleiten und parallel den FF Vpn am Leben halten?

Interessehalber: Wie sieht dein rechtliches Konstrukt hinter diesem setup aus?


#4

Rechteinhaber die Verstöße verfolgen wollen erhalten bei Anfragen dann meine Daten, nicht die des Freifunk Rheinland. Das ist so gewollt.

Den Gedanken hatte ich auch schon, hier komme ich aber mit der Umsetzung nicht weiter.

Insgesamt wäre es mir genau so am liebsten, wie du es dir auch vorstellst.

Ok, ich ging bisher davon aus, dass diese Ihre eigene Verbindung zum Supernode aufbauen und nicht die des Nodes mit benutzen der direkt am Internet angeschlossen ist.


#5

Ich würde ohne VPN anfangen und dann später nur IC-VPN dazubauen.

Für BATMAN-Supernode ist es der Befehl: batctl gw server
Dann musst du nur noch die Schnittstellen sortieren und du brauchst NAT und DHCP. Keine Ahnung wie du das machst, oder ob deine Kabelbox das richtig kann.


#6

Dann ist der Freifunk Ansatz aber auf Internet Hotspot beschnitten, oder? Bisher hatte ich bei der SSID Freifunk auch immer das VPN mesh dahinter erwartet. Sollte das IC VPN das ff netz mit beinhalten (?) ist meine Vermutung natürlich falsch.


#7

Es ist halt Freifunk-Classic, da gab es nur lokales Luft-Mesh und IC-VPN (darüber sollte man zu den rechtlichen FFKa-Knoten kommen) und Internet


#8

Ganz ehrlich, ich bin ziemlich sauer ob der Diskussion hier.

Der TS stellt eine technische Frage.
Und statt einer teschnischen Antwort (hint: Wir sind hier in “Technik/Gluon” nicht in Community oder Meta.)
bekommt er eine Grundsatzdiskussion über Störerhaftung und Freifunk-Classic an die Backe.

Wenn es nicht Gejaule geben würde, würde ich die Offtopic-Antworten abtrennen…

Leider vermag ich die Frage nicht zu beanworten.
http://gluon-gateway-doku.readthedocs.org/de/latest/configuration/basics.html
hilft zumindest mir nicht in der Fragestellung. Wäre aber vermutlich der richtige Ausgangspunkt, das Routing zu drehen.


#9

p.s.
Herausforderungen bei “Traffic local ausleiten” ist:

  • Der lokale DHCP-Server und die lokalen IPv6-Routen dürfen nicht ins restliche Netz ausstrahlen… oder doch? Aber wie weit dann? Könnte ja sein, dass man “dort” mehrere Router im Haus hat, die alle lokal herausgehen sollen.
  • ICVPN und public IPv6 wird damit dann nicht ganz trivial.

#10

Ich habe 11 Beiträge in ein neues Thema verschoben: Gluon-Basteleien im Live-Netz / Sandkasten-Domain


#11

Was ist das “restliche Netz”? Ganz albufer oder nur das lokale WLAN-Adhoc-Netz?
Er will ja die restliche lokale Umgebung damit versorgen, er muss halt darauf achten, dass das DHCP nicht ins IC-VPN geht, aber das ist auch bei einem “offizellen” Supernode zu beachten.


#12

Das ist die Frage!
Den Traffic für nur einen Router auszuleiten wird kein Problem sein.
Den DHCP-Server (und die v6-Routen) für mehrere Nodes zu ändern wird Änderungen an jedem dieser Knoten erfordern (gehe ich davon aus).


#14

Am einfachsten wäre es vermutlich, mit dem Admin-Team deiner Domäne zusammenzuarbeiten und einen Supernode an deinem Internetanschluss zu betreiben. Dort kannst du dann den Verkehr normal über deine Internetleitung ohne VPN ausleiten, und außerdem Verkehr in das ICVPN leiten.
Dafür brauchst du jedoch einen IP-Bereich aus deiner Domäne, da du ja unabhängig von allen anderen Supernodes IP-Adressen verteilen musst, die nicht in Konflikt mit den anderen IPs der Domäne stehen, um Roaming zu ermöglichen. Daher die Zusammenarbeit mit den Domänen-Admins.

In Aachen haben wir bald eine ähnliche Installation, nur wird bei uns der Supernode mit den anderen in Verbindung stehen, um die Daten weiterzureichen. Das dürfte aber optional sein, kann es dir aber nicht sicher sagen, da ich im Projekt nicht involviert bin.

Wenn du nicht zusammenarbeiten möchtest, dann kannst du auch z.B. eine Meshkitfirmware verwenden. Dann bist du nämlich vermutlichc sowieso mit dem Rest der Domäne inkompatibel (außer du kriegst das DHCP-Problem anders gelöst, BATMAN-adv hat das afaik was für eingebaut).


#15

Gluon ist auch nur ein Openwrt mit bissl einfacher Confighilfe oben drauf.
Es wäre schön wenn man lokalen Traffic ins Internet gleich per Default rausrouten könnte um den VPN FOO zu sparen.


#16

Das Thema Traffic direkt aus dem lokalen Anschluss zu routen wurde auch schon auf Github gesprochen: Share local internet connection · Issue #119 · freifunk-gluon/gluon · GitHub
Mit Gluon gibt es wohl erstmal nur die oben angesprochene Möglichkeit d.h. einen eigenen Gateway aufzusetzten.


#17

Hi,

danke für die vielen hilfreichen Antworten mit verschiedenen Herangehensweisen.
Ich werde einen eigenen Supernode in Betrieb nehmen und mir ein /22 für IPv4 und ein /56 für IPv6 reservieren lassen.

IPv6 (öffentlich) ist über diesen Weg auch kein Problem, da reicht es schon ein /64 aus meinem vom ISP zugewiesenen /56 zuzuweisen welches dann einzelne Adressen an die Clients verteilt. Das konnte ich schon erfolgreich testen. Dem ordentlichen Routing und der direkten Erreichbarkeit der Clients steht mit der Lösung Mittels eines Supernodes nichts im Wege.

@CHRlS: Dein Vergleich hinkt gewaltig. Wegen derartigen Kommentaren haben viele, wie ich, keine Lust sich in Foren (Und vor allem der Kultur darin) zu betätigen, was mich auch dazu bringt, dass das hier meine erste und letzte Anfrage war, da ich wahrscheinlich immer mit derart “hilfreichen” Antworten rechnen darf. Wie schon erwähnt wurde, ist es auch nur ein OpenWRT, und bei dem ist solch ein Szenario umsetzbar. Ich hoffe für deine Community nur, dass du auf Anfragen von Interessierten und Anfragen, die etwas vom Standard abweichen, anders und offener reagierst.

Vielen Dank für eure Denkanstöße.


Gluon-Basteleien im Live-Netz / Sandkasten-Domain
Gluon-Basteleien im Live-Netz / Sandkasten-Domain
#18

Du machst mit dem dann eine eigene Collisionsdomain auf?
Ansonsten besteht das problem, dass Du ggf. “ins restliche Netz” ausstrahlst, wenn Du nicht einen Haufen ebtables-Magie in Stellung bringst, um die Announces an den richtigen Stellen abzublocken.


#19

Ich habe nicht genau verstanden, was du jetzt genau beabsichtigst, aber ich glaube dir ist ein Problem noch nicht ganz klar geworden, auf das @CHRlS wohl auch hinaus wollte.

Das Problem ist, dass beim Gluon-Meshing ein großes Layer-2-Netz unter den einzelnen Freifunkknoten entsteht. Und so wie du das jetzt umsetzen willst, bist du eigentlich ein Rogue DHCP, der bei Herstellung eines erfolgeichen Meshes das Netz stören wird, weil innerhalb eines Layer-2-Netzes verschiedene Layer-3-Netze (eins von Freifunk Ruhrgebiet, eins von deinem ISP) vergeben werden!

Du musst also dringend mit den Admins der Domäne mit der du meshen willst kooperieren, damit das nicht passiert.

Wenn du das nicht möchtest, und wirklich deine eigenen IPs vergeben willst, dann darfst du nicht mit den Gluon-Knoten in deiner Umgebung meshen. Und in diesem Fall ist dir tatsächlich eine Nicht-Gluon-Firmware besser angeraten, z.B. Meshkit. Oder einfach gar nicht meshen und nur eine SSID “Freifunk” ohne Verschlüsselung aufmachen. Das geht dann natürlich sogar mit der Standardfirmware vom Hersteller.

Darauf wollte @CHRlS vermutlich hinaus, wobei ich zustimmen kann, dass das ein Außensteher so wie es rübergebracht wurde natürlich nicht erschnuppern kann, was er will :wink:


Gluon-Basteleien im Live-Netz / Sandkasten-Domain
#20

Zusammenfassend dürfte wohl eine eigene Mikro-Community mit lokalem Gateway am einfachsten sein. Bei einer kleinen Wolke könnte das vermutlich dann auch auf einem Router liegen.


#21

Gibt auch das ALT-ESC Package, das allerdings noch nicht an 2018.x angepasst ist: