Freifunk-Gateway aufsetzen/DHCP

Funktion

Ein DHCP Server wird benötigt damit IPv4 Adressen in der Hood vergeben werden können. Es können hier verschiedene Systeme verwendet werden. Aus gründen der Datensparsamkeit sollte man das logging soweit wie möglich abstellen und nur wirklich techn. zwingende Daten speichern.

Der DHCP Server muss auf das Batman Interface arbeiten, falls eine Bridge verwendet wird auf der Bridge. IP Adressen müssen hier https://wiki.freifunk-franken.de/w/Portal:Netz reserviert werden.

Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als vorletzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus. Daher hier bitte acht geben!

dnsmasq

Installation

Einfach aus den Paketquellen installieren z.b.

apt-get install dnsmasq

Konfiguration

zuerst die default systemd Unit deaktivieren

systemctl stop dnsmasq
systemctl disable dnsmasq

Globale Optionen

Danach kann man einige globale Optionen in /etc/dnsmasq.d/dhcp.conf

quiet-dhcp
bind-interfaces
dhcp-authoritative
dhcp-option=6,10.83.252.11,10.83.252.31,10.50.252.0
domain=fff.community

quiet-dhcp stellt das Logging ab. dhcp-option=6,.. setzt die DNS-Server, die an den Client gesendet werden.

DNS-Funktionalität abschalten

Außerdem sollte die DNS-Funktionalität in /etc/dnsmasq.d/disable-dns.conf vollständig abgeschaltet werden.

port=0

Hoodspezifische Einstellungen

Nun kann für jede Hood noch eine systemd Service angelegt werden.

/etc/systemd/system/nuernberg-dhcp.service

[Unit]
Requires=network.target
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=20

ExecStart=/usr/sbin/dnsmasq -k --conf-dir=/etc/dnsmasq.d,*.conf --interface bat-nuernberg --dhcp-range=10.83.xx.1,10.83.xx.127,255.255.xxx.0,20m --pid-file=/var/run/dhcp-bat-nuernberg.pid --dhcp-leasefile=/var/lib/misc/bat-nuernberg.leases

[Install]
WantedBy=multi-user.target

• -k behält dnsmasq im Vordergrund, was für systemd bequemer ist (in Kombination mit Type=simple)
• --interface setzt das Interface, auf dem der DHCP-Server laufen soll.
• --dhcp-range setzt die DHCP-Range. Die Angabe erfolgt in <von>,<bis>,<Netzmaske>,<Leasetime>
  • Bei neueren Batman-adv Versionen wird die Netzmaske automatisch ermittelt, wenn die Option weggelassen wird
  • Bei älteren Versionen ist ein Bug, daher fällt dnsmasq auf den Standard für die IP-Range (255.0.0.0 bei 10.0.0.0/8) zurück.
• pid-file und dhcp-leasefile müssen für jede Hood eindeutig sein

Anschließend den neuen Service registrieren und starten:

systemctl daemon-reload
systemctl enable dnsmasqbat0.service
systemctl start dnsmasqbat0.service 

Voteile gegenüber ISC-DHCP

+ schlanker
+ lässt sich besser per Script konfigurieren
+ Loggt deutlich weniger Kram per Default mit
+ Logging von Leases lässt sich leicht abschalten
+ Man kann sehr schön pro Hood eine eigene Instanz laufen lassen und muss so bei Änderung nicht immer das komplette DHCP neu starten.

Nicht Freifunk Adressen

ACHTUNG

Die folgende Beschreibung sollte keinesfalls ohne Rücksprache mit der Community bei dem zentralen Keyxchange umgesetzt werden, da es dort zu unvorhersehbaren Problemen kommen kann

Für große Hoods macht es u.U. Sinn per DHCP Adressen zu vergeben die nicht im Freifunk verwendet werden (z.b. aus dem 192.168.0.0/16 oder 100.64.0.0/10 Netz). Um diese Adressen auf das Freifunk zu routen ist SNAT nötig. Folgende iptables rule ist hilfreich:

iptables -t nat -A POSTROUTING -s 192.168.16.0/20 -j SNAT --to-source 10.83.252.xx

wobei nach -s(ource) die Adressen die per DHCP vergeben werden angegeben werden und bei --to-source die Adresse des Servers verwendet werden muss welche im Freifunk korrekt geroutet wird.

Achtung Freifunkprinzipien

Stellt bitte sicher das hier zumindest für IPv6 die Freifunkprinzipien aufrecht erhalten werden. Ein Client sollte zumindest über IPv6 dann aus dem gesamten Freifunknetz erreichbar sein.

ISC-DHCP-Server

Es ist sehr schwierig, bei diesem Server das Logging der Mac Adressen abzuschalten. Daher wird dessen Einsatz nicht empfohlen

In isc-dhcp-server definieren wir ... vi /etc/default/isc-dhcp-server

... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:

.
.

INTERFACES="bat0"
.
.

Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers... /etc/init.d/isc-dhcp-server restart ...aktiviert werden.

Die Konfiguration wird in dhcpd.conf vorgenommen: vi /etc/dhcp/dhcpd.conf

und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:

.
.
.
### Freifunk Franken
#option domain-name "fff.community";
#option domain-name-servers 10.50.16.1;
#authoritative;
### Fuerth
#shared-network fff-fuerth {
#    subnet 10.50.32.0 netmask 255.255.248.0 {                  # Netzwerk und Netzmaske der Fuerther Hood
#        range 10.50.38.0 10.50.39.254;                     # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet 
#        option routers 10.50.32.5;                         # Default-Gateway, dass Clients mitgeteilt wird 
#        option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden
#    }
#}

Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".

Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter Portal:Netz reserviert.

Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in Portal:Netz reserviert wurde, verwendet.

Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in Portal:Netz, sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.