Freifunk Paderborn/Gateway

Diese Informationen sind nicht mehr aktuell!

Hier sammeln wir Infos zum Gateway.

Unsere IP-Range: 10.132.0.0/16
Unsere IPv6-Range: fdca:ffee:ff12::/48

Server / Gateways

System	IPs intern	Standort	Ansprechpartner	Verwendung
gw01	10.132.16.1 fdca:ffee:ff12:132:16::1	VM im Hetzner RZ	HeJ / oscar	Gatewayserver 1 (aktuell zusätzlich noch für Services zuständig)
gw02	10.132.32.1 fdca:ffee:ff12:132:32::1	VM im Hetzner RZ	HeJ / oscar	Gatewayserver 2, IPv6 Uplink
gw03	10.132.24.1 fdca:ffee:ff12:132:24::1	VM	Barbarossa	Gatewayserver 3 im Aufbau
srv01	10.132.1.1 fdca:ffee:ff12:132:1::1	VM im Hetzner RZ	HeJ / oscar	Services (DNS-Master, ffpb-map, firmwareupdates), geplant

IPv4-Netzaufteilung

Netz	Benutzung
10.132.1.1 - 10.132.1.255	ffpb-Services
10.132.16.1 10.132.16.50 - 10.132.23.254	Gateway 1 DHCP-Bereich gw01
10.132.24.1 10.132.24.50 - 10.132.31.254	Gateway 3 DHCP-Bereich gw03
10.132.32.1 10.132.32.50 - 10.132.39.254	Gateway 2 DHCP-Bereich gw02

IPv6

Im Mesh wird aktuell das Präfix fdca:ffee:ff12:132::/64 von den Knoten announced. Zusätzlich verteilt gw02 das Präfix um eine Route ins Internet zu legen. Da intern Uniqe-Local-Adressen genutzt werden, findet auf dem gw02 Präfixtranslation für den Bereich fdca:ffee:ff12:132::/64 statt.

Routingprobleme auf den Knoten

Mit aufkommen der DS-Liteanschlüsse von Unitymedia (mittlerweile auch bei neusten Telekomanschlüssen) haben wir ein Problem beim Verbindungsaufbau von fastd festgestellt: Teilweise im Minutentakt bricht die Verbindung ab, und der Knoten verbindet sich neu. Das führt unweigerlich dazu, dass im Grunde über diesen Knoten nicht gearbeitet werden kann. Abhilfe schaffte die Umstellung auf IPv6. Gleichzeitig haben wir uns damit aber ein neues Problem eingefangen:

Gerade Knoten an Unitymedia-Fritzboxen haben beim booten nicht schnell genug eine IPv6-Adresse per RouterAdvertisment bekommen, was dazu führt, dass die Knoten zunächst per IPv4 verbinden. Da das Gateway über das Mesh eine Defaultroute für IPv6 announced, kann es passieren, dass diese anschließend vor der Route über die heimische Fritzbox in den Routingtabellen des Knoten auftaucht. Ein erneuter Verbindungsaufbau via IPv6 würd anschließend scheitern, da der Knoten den Defaultgateway über die nicht mehr existierende VPN-Verbindung suchen würde.

Abhilfe schaffte folgende Lösung: Die Knoten holen sich aktiv per dhcpv6 eine IP von der Fritzbox (warum Routersolicitation nicht tat ist uns noch unklar, theoretisch sollte auch Routeradvertisments bzw Routersolicitation tun). Der br-client wird gelichzeitig gesagt, dass sie defaultrouten ignorieren soll. Das führt dazu, dass der knoten selbst nur noch ins Netz ffca:ffee:ff12:132::/64 kommt, was für uns aber erstmal vertretbar ist. Alternativ kann noch eine zusätzliche Route ins komplette /48er ffpb-Netz gelegt werden.

Configänderungen in /etc/config/network:

Neu hinzu:

  config interface 'wan6'
       option ifname '@wan'
       option proto 'dhcpv6'
       option reqprefix 'no'

Geändert:

  config interface 'client'
       option ifname 'eth1 bat0'
       option type 'bridge'
       option proto 'dhcpv6'
       option reqprefix 'no'
       option defaultroute '0'   # Neu
       option macaddr '10:fe:ed:af:cf:90'
       option peerdns '1'

Quellen

	Kommentar
Funktionsweise eines Freifunk-Knotens	Gilt das auch noch für gluon?
Offizielle Gluon Doku	unvollständig
generelles technisches FAQ von den Lübeckern	tinc vs. fastd und Co.
Freifunk Lübeck Wiki	Bisher keine Infos zu gluon, trotzdem sehr interessant!
Hamburger Gateway-Config der alten Firmware
Lübecker Gateway-Config der alten Firmware