Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
anleitungen:spezielle_anpassungen [16.07.2016 - 18:57] – [Mesh on VLAN] albi | anleitungen:spezielle_anpassungen [17.11.2022 - 11:00] (aktuell) – [Mesh on VLAN] Adrian Reyer | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | <alert type=" | ||
+ | </ | ||
====== http auf WAN Port verfügbar machen | ====== http auf WAN Port verfügbar machen | ||
in / | in / | ||
Zeile 30: | Zeile 32: | ||
- | ====== LAN und WAN Port tauschen | + | ====== LAN und WAN Port tauschen ====== |
in / | in / | ||
* beim 3600/4300er TP-Link eth0 durch eth0.1 und eth1 durch eth0.2 ersetzen | * beim 3600/4300er TP-Link eth0 durch eth0.1 und eth1 durch eth0.2 ersetzen | ||
Zeile 119: | Zeile 121: | ||
====== Mesh on VLAN ====== | ====== Mesh on VLAN ====== | ||
- | Ich will meinen WAN Port normal für Mesh on VPN nutzen und gleichzeitig mit einem zweiten Router meshen, den ich aber nur über den WAN Port erreichen kann. | ||
- | Das ganze ist leider unterschiedlich je nach Router. | ||
+ | Ich will meinen WAN Port normal für Mesh on VPN nutzen und gleichzeitig mit einem zweiten Router meshen, den ich aber nur über den WAN Port erreichen kann. Dazu verwende ich VLAN 9 für das Meshing zwischen den Geräten. Solltet ihr einen Managbaren Switch dazwischen haben, müsst ihr an den Ports VLAN 9 konfigurieren, | ||
+ | Das ganze ist leider unterschiedlich je nach Router bzw Routerkonfig. | ||
+ | |||
+ | ==== Achtung: unsupported von Gluon, geht bei Updates kaputt, veraltete Info, Einträge in / | ||
=== TP Link 841N === | === TP Link 841N === | ||
* prüfe mit ''' | * prüfe mit ''' | ||
Zeile 148: | Zeile 152: | ||
option mesh ' | option mesh ' | ||
option proto ' | option proto ' | ||
+ | | ||
+ | ====== VPN zu den Gateways konfigurieren ======= | ||
+ | |||
+ | Bis zur Firmware 0.9 (gluon v2016.2.2) gab es in der Datei " | ||
+ | eine komplette Liste aller Gateway-Gruppen mit den zugehörigen Segmenten. | ||
+ | Zum Verbindungsaufbau wurden alle Einträge solange durchprobiert, | ||
+ | Hier konnten bei Bedarf bekannt ungültige oder ungewollte Kombinationen für einen bestimmten Node deaktiviert werden. | ||
+ | |||
+ | Mit der neuen Firmware 1.0 gibt es nur noch 10 Einträge, je einen pro Gateway-Gruppe. Diese Einträge entsprechen denen, | ||
+ | die es vor der Segmentierung im Frühjahr 2016 gegeben hatte und danach zum " | ||
+ | Heute nennen wir das " | ||
+ | automatisch registriert werden können (Onboarding-System). Die Einträge für die " | ||
+ | gibt es nicht mehr. | ||
+ | |||
+ | Wenn ein Node jetzt eingeschaltet oder neu gestartet wird, dann frägt | ||
+ | der Node seine eigene erweiterte Node-ID im DNS ab. Diese erweiterte | ||
+ | Node-ID lautet " | ||
+ | primäre MAC-Adresse (ohne die Doppelpunkte) und KKKKKKKKKKKK = erste 12 | ||
+ | Stellen des public Key. Ein Beispiel für eine DNS-Abfrage wäre " | ||
+ | ffs-60e327e79498-49a652c95984.segassign.freifunk-stuttgart.de**" | ||
+ | |||
+ | Bei einem neuem oder geänderten Node gibt es keine Antwort, und für den | ||
+ | Verbindungsaufbau wird die Liste in der Firmware (" | ||
+ | benutzt. Dort sind statt der Gateways jetzt die Onboarder hinterlegt | ||
+ | (derzeit ist nur gw07 ein aktiver Onboarder). Ein Onboarder kommuniziert | ||
+ | mit dem Node unabhängig von einer Registrierung und registriert ihn bei | ||
+ | Bedarf automatisch (trägt alle notwendigen Daten im Git ein und legt den | ||
+ | DNS-Eintrag an), falls er nicht schon bekannt ist. | ||
+ | |||
+ | Korrekt registrierte Nodes erhalten auf ihre DNS-Anfragen auch eine | ||
+ | Antwort. Diese Antwort ist eine IPv6-Adresse " | ||
+ | der Teil vor den **::** immer gleich ist und die Zahl hinter den **::** dem | ||
+ | Segment entspricht, für das der Node registriert ist. Mit dieser | ||
+ | Information modifiziert der Node seine eigene fastd-Konfiguration und | ||
+ | startet damit erneut den VPN-Verbindungsaufbau, | ||
+ | richtigen Gateways führt. Diese Modifikation erfolgt nur im | ||
+ | Hauptspeicher und wird *nicht* in den Flash-Speicher geschrieben, | ||
+ | die Datei " | ||
+ | jedem Neustart eines Nodes auch wieder die Ausgangssituation, | ||
+ | riskiert keine falsche Konfiguration im Flash. | ||
+ | |||
+ | Wenn man jetzt von Hand die fastd-Konfiguartion ändert, hat das für den | ||
+ | normalen Betrieb keine Bedeutung, weil die tatsächlich benutzte | ||
+ | Konfiguration ja aufgrund des DNS-Ergebnis im RAM neu erzeugt wird. Man | ||
+ | verbaut sich ggf. nur den Weg zum Onboarder, falls sich die | ||
+ | Konfiguration ändert und der Node neu registriert werden müsste. | ||
+ | |||
+ | Der komplette Ablauf im Node von der DNS-Abfrage bis zur Modifikation | ||
+ | der fastd-Konfiguration erfolgt im script " | ||
+ | das bei jedem Verbindungsversuch und regelmäßig einmal pro Minute | ||
+ | ausgeführt wird. Ändert sich das Segment in der DNS-Antwort, | ||
+ | Konfiguration im RAM angepasst, die bestehende VPN-Verbindung getrennt | ||
+ | und wieder neu aufgebaut. | ||
+ | |||
+ | Sollte es tatsächlich notwendig sein, eine eigene fixe Konfiguration | ||
+ | nutzen zu wollen/ | ||
+ | deaktiviert werden, so dass die eigenen Einträge in der Datei | ||
+ | " | ||
+ | folgende Befehle ein: | ||
+ | |||
+ | < | ||
+ | uci commit</ | ||
+ | |||
+ | Wird allerdings die Automatik deaktiviert, | ||
+ | Gateway-Konfiguration in der Datei " | ||
+ | kann sich der Node nicht mit dem Freifunknetz verbinden. Man sollte sich | ||
+ | also sehr genau überlegen, ob man wirklich auf den automatischen Betrieb | ||
+ | verzichten will. | ||
{{tag> | {{tag> | ||