Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| infrastruktur:gateway:babel-gateway [22.11.2017 13:03] – [Was braucht man noch ringsrum?] christf | infrastruktur:gateway:babel-gateway [10.06.2021 12:25] (aktuell) – igor | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | ====== Gateway für das Freifunk-Babel Netz ====== | ||
| + | <WRAP center round todo 60%> | ||
| + | Diese Seite ist veraltet da FFFFM aktuell kein Babel Netz betreibt. | ||
| + | </ | ||
| + | |||
| + | |||
| Gateways für das Freifunk-Babel-Netz orientieren sich am Setup für Batman-Gateways. | Gateways für das Freifunk-Babel-Netz orientieren sich am Setup für Batman-Gateways. | ||
| Der Server nimmt fastd-Verbindungen von Freifunk-Routern mit der Babel-Firmware an und verteilt Informationen zur Infrastruktur des Netzes (früher: IP-Adressen & Routen, mittlerweile lediglich Routen, wobei das streng genommen optional ist), damit das Gesamtnetz funktionieren kann. | Der Server nimmt fastd-Verbindungen von Freifunk-Routern mit der Babel-Firmware an und verteilt Informationen zur Infrastruktur des Netzes (früher: IP-Adressen & Routen, mittlerweile lediglich Routen, wobei das streng genommen optional ist), damit das Gesamtnetz funktionieren kann. | ||
| Es gibt ein paar Unterschiede zu Batman-Gateways: | Es gibt ein paar Unterschiede zu Batman-Gateways: | ||
| - | * es ist kein dhcp-Server erforderlich | + | * es ist kein dhcp-Server erforderlich |
| - | * es ist kein radvd erforderlich | + | * es ist kein radvd auf den Gateways |
| * Batman wird nicht installiert | * Batman wird nicht installiert | ||
| * Es müssen zusätzliche Komponenten (mmfd, l3roamd) ausgeführt werden | * Es müssen zusätzliche Komponenten (mmfd, l3roamd) ausgeführt werden | ||
| * Über fastd wird das babel mesh-Protokoll gesprochen. Dadurch ist eine theoretische minimale MTU von 1288 möglich (1280 minimale IPv6-Größe + ein UDP-Header für mmfd-Pakete, | * Über fastd wird das babel mesh-Protokoll gesprochen. Dadurch ist eine theoretische minimale MTU von 1288 möglich (1280 minimale IPv6-Größe + ein UDP-Header für mmfd-Pakete, | ||
| + | |||
| + | |||
| + | Das Setup ist bereits in salt abgebildet: https:// | ||
| + | |||
| Zeile 50: | Zeile 60: | ||
| [Service] | [Service] | ||
| Type=simple | Type=simple | ||
| - | ExecStart=/ | + | ExecStart=/ |
| KillMode=process | KillMode=process | ||
| ExecStartPost=/ | ExecStartPost=/ | ||
| Zeile 60: | Zeile 70: | ||
| WantedBy=multi-user.target | WantedBy=multi-user.target | ||
| - | Die Bridge br-client muss per / | ||
| - | iface br-client inet static | ||
| - | address 192.0.2.1 | ||
| - | netmask 255.255.255.0 | ||
| - | bridge_ports none | ||
| Die hinzugefügte Route macht, dass Pakete mit einem Ziel im Freifunk-Client-Netz aber mit unbekannter echter Route an den l3roamd übergeben werden. Dieser kann dann die Route ermitteln. | Die hinzugefügte Route macht, dass Pakete mit einem Ziel im Freifunk-Client-Netz aber mit unbekannter echter Route an den l3roamd übergeben werden. Dieser kann dann die Route ermitteln. | ||
| - | Der l3roamd wird angepasst, sodass br-client nicht mehr zwingend erforderlich sein wird, denn auf Gateways ist sie nicht vorhanden und auch nicht sinnvoll. | ||
| - | |||
| ===== Routing ===== | ===== Routing ===== | ||
| Tabelle 10 wird fürs Routing genutzt. Wir haben auf dne GAteways folgende ip -6 rules: | Tabelle 10 wird fürs Routing genutzt. Wir haben auf dne GAteways folgende ip -6 rules: | ||
| Zeile 88: | Zeile 91: | ||
| - | in Tabelle 12 kann man routen rein schreiben, von denen man möchte, dass sie von babeld noch verteilt werden sollen, Tabelle 10 enthält die Routen, die für das Freifunk-Netz gelten, in TAbelle | + | in Tabelle 12 kann man routen rein schreiben, von denen man möchte, dass sie von babeld noch verteilt werden sollen, Tabelle 10 enthält die Routen, die für das Freifunk-Netz gelten, in Tabelle |
| Die default-route für den uplink muss in Tabelle 10 und 12 eingetragen werden (ggf reicht Tabelle 10). Diese Route muss, damit sie mit dem prefixd kompatibel als src-filter das client-Netz gesetzt haben. | Die default-route für den uplink muss in Tabelle 10 und 12 eingetragen werden (ggf reicht Tabelle 10). Diese Route muss, damit sie mit dem prefixd kompatibel als src-filter das client-Netz gesetzt haben. | ||
| Zeile 129: | Zeile 132: | ||
| WantedBy=multi-user.target | WantedBy=multi-user.target | ||
| - | Und so wird er konfiguriert: | + | Und so wird er in / |
| ipv6-subtrees true | ipv6-subtrees true | ||
| reflect-kernel-metric true | reflect-kernel-metric true | ||
| Zeile 146: | Zeile 149: | ||
| redistribute ip 2a06: | redistribute ip 2a06: | ||
| redistribute ip 2a06: | redistribute ip 2a06: | ||
| - | redistribute src-ip 2a06: | + | redistribute src-ip 2a06: |
| - | redistribute ip ::/0 allow | + | |
| - | + | ||
| - | Die Interfaces sind natürlich an die Gegebenheiten so anzupassen, dass alle mesh-interfaces dabei sind. Das beinhaltet ausschließlich dann den Uplink, sofern auf dem babel gesprochen wird. Routen für die next-node-IP (bei unserem Netz 2a06: | + | |
| - | + | ||
| - | + | ||
| - | TODO: In dem Moment in dem ich das schreibe, habe ich den Eindruck, dass | + | |
| + | Die Interfaces sind natürlich an die Gegebenheiten so anzupassen, dass alle mesh-interfaces dabei sind. Das beinhaltet ausschließlich dann den Uplink, sofern auf dem babel gesprochen wird. Routen für die next-node-IP (bei unserem Netz 2a06: | ||
| ===== Yanic ===== | ===== Yanic ===== | ||
| Zeile 160: | Zeile 159: | ||
| ===== Was braucht man noch ringsrum? ===== | ===== Was braucht man noch ringsrum? ===== | ||
| - | * Das Netz ist IPv6-Only, also benötigt man einen NAT64 und entsprechenden DNS für den Zugriff auf das IPv4-Internet. | + | |