Freifunk-Gateway aufsetzen: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
(IPv6)
(Installation)
(61 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:
  
 
= Preface =
 
= Preface =
Für das Aufsetzen eines Freifunk-Gateway gibt es kein universelles Kochrezept. Auch erfahrene Admins erfahren bei der Installation kleinere und grössere Herausforderungen, die es zu überwinden gilt. Unterschiedliche Softwareinstallationen, Netzwerkkonfigurationen, Hoster und VPN Anbieter können Anpassungen zu der hier präsentierten Vorgehensweise notwendig werden lassen, z.B. indem Pakete nach installiert werden oder Netzwerkkonfigurationen angepasst werden müssen. Um dies zu erleichtern, versucht der Artikel nicht nur die Konfiguration darzulegen, die in diesem spezifischen Fall funktioniert hat ("Know-How"), sondern versucht auch kurz auf die Hintergründe einzugehen, um ggf. eine Anpassung zu erleichern ("Know-Why").
+
Für das Aufsetzen eines Freifunk-Gateway gibt es kein universelles Kochrezept. Auch erfahrene Admins erfahren bei der Installation kleinere und grössere Herausforderungen, die es zu überwinden gilt. Unterschiedliche Softwareinstallationen, Netzwerkkonfigurationen, Hoster und VPN Anbieter können Anpassungen zu der hier präsentierten Vorgehensweise notwendig werden lassen, z.B. indem Pakete nach installiert werden oder Netzwerkkonfigurationen angepasst werden müssen. Um dies zu erleichtern, versucht der Artikel nicht nur die Konfiguration darzulegen, die in diesem spezifischen Fall funktioniert hat ("Know-How"), sondern versucht auch kurz auf die Hintergründe einzugehen, um ggf. eine Anpassung zu erreichen ("Know-Why").
 +
 
 +
Die Anleitung dient dazu, den Einstig zu erleichtern.</br>
 +
Viele der Dinge können später auf die eigenen Bedürfnisse angepasst und zugeschnitten werden.
 +
 
 +
Die Anleitung hat keine Garantie auf Vollständigkeit und wird stetig verändert und verbessert.</br>
 +
Wenn du beim Installieren auf Probleme oder Fehler stößt: Der nächste freut sich, wenn er auf diesen Fehler nicht mehr stößt oder eine entsprechende Anmerkung im Wiki findet. :-)
  
 
Freifunk Franken ist "Development in Progress", d.h. eine Konfiguration die heute funktioniert, wird morgen durch eine andere und vielleicht sogar bessere abgelöst. Ein einmal aufgesetztes Gateway muss sich so der Entwicklung anpassen.
 
Freifunk Franken ist "Development in Progress", d.h. eine Konfiguration die heute funktioniert, wird morgen durch eine andere und vielleicht sogar bessere abgelöst. Ein einmal aufgesetztes Gateway muss sich so der Entwicklung anpassen.
Zeile 21: Zeile 27:
 
* Es gibt viele nette Leute im [[Kommunikation | IRC]], die immer gerne helfen, wenn die Motivation da ist, sich auch selbst mit dem Problem zu befassen.
 
* Es gibt viele nette Leute im [[Kommunikation | IRC]], die immer gerne helfen, wenn die Motivation da ist, sich auch selbst mit dem Problem zu befassen.
 
* Für die schnelle Abstimmung unter den GW Betreibern sollte sich jeder Betreiber auf der [[Mailinglisten#freifunk-gateway| freifunk-gateway]] Mailingliste setzen. Die "große" [[Mailinglisten#franken-freifunk| Liste]] und die [[Mailinglisten#freifunk-dev| dev-Liste]] sind ebenfalls hilfreich.
 
* Für die schnelle Abstimmung unter den GW Betreibern sollte sich jeder Betreiber auf der [[Mailinglisten#freifunk-gateway| freifunk-gateway]] Mailingliste setzen. Die "große" [[Mailinglisten#franken-freifunk| Liste]] und die [[Mailinglisten#freifunk-dev| dev-Liste]] sind ebenfalls hilfreich.
* Ohne Vorkenntnisse ist es schwierig aber ganz und gar nicht unmöglich ein Gateway aufzusetzen. Soweit es nicht bei dem Kenntnisstand bleiben soll, wird auch hier gerne geholfen.
+
* Ohne Vorkenntnisse ist es schwierig, aber ganz und gar nicht unmöglich ein Gateway aufzusetzen. Auch hier gilt wieder: Es wird gerne geholfen, wenn man sich mit Problemen einigermaßen selbstständig auseinandersetzt und konkrete Fragen stellt.
 
* Bereitschaft mitzuhelfen, das Wiki aktuell zu halten, damit die Ressourcenplanung (IPs!) funktioniert und für Notfälle die wichtigsten Infos und Ansprechpartner zu den Servern vorhanden sind. Die wichtigsten Seiten sind [[Server]], [[Portal:Netz]] und [[Portal:Netz/IPv6]].
 
* Bereitschaft mitzuhelfen, das Wiki aktuell zu halten, damit die Ressourcenplanung (IPs!) funktioniert und für Notfälle die wichtigsten Infos und Ansprechpartner zu den Servern vorhanden sind. Die wichtigsten Seiten sind [[Server]], [[Portal:Netz]] und [[Portal:Netz/IPv6]].
* Ein wenig Zeit - sowohl fürs Aneignen des Verständnisses als auch fürs Aufsetzen an sich. Gehe erstmal von ganz grob 5-20 Stunden Arbeitszeit aus, um von einem "nackten" Server zu einem voll funktionstüchtigen GW zu kommen, der ja doch aus recht vielen verschiedenen Diensten besteht. Nach der Ersteinrichtung sollte man regelmäßig ein wenig Zeit investieren, um zu schauen, ob alles in Ordnung ist, Updates zu fahren, Änderungen in der Infrastruktur nachzupflegen, sich tiefergend mit der Materie zu beschäftigen, etc.
+
* Ein wenig Zeit - sowohl fürs Aneignen des Verständnisses als auch fürs Aufsetzen an sich. Gehe erstmal von ganz grob 5-20 Stunden Arbeitszeit aus, um von einem "nackten" Server zu einem voll funktionstüchtigen GW zu kommen, das ja doch aus recht vielen verschiedenen Diensten besteht. Nach der Ersteinrichtung sollte man regelmäßig ein wenig Zeit investieren, um zu schauen, ob alles in Ordnung ist, Updates zu fahren, Änderungen in der Infrastruktur nachzupflegen, sich tiefergend mit der Materie zu beschäftigen, etc.
 
 
  
 
=== Was der Server können muss ===
 
=== Was der Server können muss ===
 
* Öffentliche IPv4 und IPv6 Adresse
 
* Öffentliche IPv4 und IPv6 Adresse
 +
** Leider aktuell noch zu viele IPv4 Anschlüsse, um IPv4 außen vor zu lassen. :-(
 +
** IPv6 ist pflicht.
 
* Kernelmodule laden (Bestimmte Virtualisierungslösungen wie OpenVZ sind daher nicht möglich)
 
* Kernelmodule laden (Bestimmte Virtualisierungslösungen wie OpenVZ sind daher nicht möglich)
 
* Nur relativ wenig CPU und RAM nötig
 
* Nur relativ wenig CPU und RAM nötig
Zeile 42: Zeile 49:
  
 
== Anbindung an andere Netze ==
 
== Anbindung an andere Netze ==
Neben unserem eigenen Freifunknetz gibt es weitere Netzwerke mit denen sich ein peering lohnt:
+
Neben unserem eigenen Freifunknetz gibt es weitere Netzwerke mit denen sich ein Peering lohnt:
  
 
* InterCity-VPN zwischen den meisten Freifunknetzen
 
* InterCity-VPN zwischen den meisten Freifunknetzen
 
** BGP
 
** BGP
 
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html
 
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html
** Mehr Infos http://wiki.freifunk.net/IC-VPN
+
** Mehr Infos: [[ICVPN]]
  
 
* DN42
 
* DN42
Zeile 60: Zeile 67:
 
== Server-Anbieter==
 
== Server-Anbieter==
  
=== Empfehlenswert ===
+
=== Hoster, bei denen gute Erfahrungen gemacht wurden ===
Der kleinste Hetzner Cloud Server kann derzeit empfohlen werden. Rechenleistung ist ausreichend und der Traffic ist angemessen.
+
Diese unvollständige, nicht abschließende Liste von Hostern dient nur der Orientierung.
 +
Solange ein Hoster die weiter oben genannten Voraussetzungen erfüllt, ist er für ein Freifunk Gateway geeignet.
  
Generell ist aber jeder Server, der die oben genannten Voraussetzungen erfüllt super geeignet. Umso mehr verschiedene Rechenzentren im Freifunknetz, umso besser.
+
Umso mehr verschiedene Hoster im Freifunknetz, umso besser.
  
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Nürnberg, Falkenstein, Helsinki)
+
* [https://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Nürnberg, Falkenstein, Helsinki)
 
** Cloud Server, 20TB Traffic 2,96€/Monat
 
** Cloud Server, 20TB Traffic 2,96€/Monat
 +
** Wird bedingt des vielen verfügbaren Traffics fürs Geld sehr viel genutzt
 +
** Hetzner-interner Traffic wird nicht berechnet
  
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)
+
* [https://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)
 
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.
 
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.
 +
 +
 +
=== Hoster mit bekannten Problemen ===
 +
 +
* [https://www.netcup.de/ netcup]
 +
** Aus einem bisher nicht abschließend geklärtem Grund funktioniert GRE über IPv6 bei den VMs nicht.
 +
** Techniker ist bisher _nicht_ informiert
  
 
= Installation =
 
= Installation =
Zeile 75: Zeile 92:
  
 
* Empfohlenes Betriebssystem: Debian
 
* Empfohlenes Betriebssystem: Debian
 +
** Die Anleitung basiert aktuell auf '''Debian 10 (Buster)'''. Für Einsteiger wird dringend empfohlen mit dieser Version anzufangen.
 
* Sicherheit
 
* Sicherheit
 
** SSH Login nur mit Keys, Login per Passwort abschalten (siehe [https://www.thomas-krenn.com/de/wiki/OpenSSH_Public_Key_Authentifizierung_unter_Ubuntu hier])
 
** SSH Login nur mit Keys, Login per Passwort abschalten (siehe [https://www.thomas-krenn.com/de/wiki/OpenSSH_Public_Key_Authentifizierung_unter_Ubuntu hier])
Zeile 85: Zeile 103:
 
Um Doppelbelegungen zu vermeiden, müssen diese auch im Wiki eingetragen werden.
 
Um Doppelbelegungen zu vermeiden, müssen diese auch im Wiki eingetragen werden.
  
An dieser Stelle sollte man sich unbedingt mit Subnetzen und der [https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR-Notation] vertraut machen, falls einem das (noch) Fremdworte sind.<br>
+
An dieser Stelle sollte man sich unbedingt mit Subnetzen und der [[CIDR|CIDR-Notation]] vertraut machen, falls einem das (noch) Fremdworte sind.<br>
Ein entsprechender IP-Rechner findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].
 
  
 
==== Private FFF IPs ====
 
==== Private FFF IPs ====
Zeile 101: Zeile 118:
  
 
==== Peering-IPs ====
 
==== Peering-IPs ====
Für die Peerings verwenden wir Adressen aus einem speziell dafür vorgesehenen [[Portal:Netz#10.83.252.0.2F22_.28Master_IPs.29|Bereich]].<br>
+
Für die Peerings verwenden wir Adressen aus einem speziell dafür vorgesehenen [[Portal:Netz#10.83.252.0.2F22_.28Master_IPs_for_use_as_.2F32_routed_IPs_withing_L3_network.29|Bereich]].<br>
 
Die Adressen werden mit einer /32 Netzmaske an die Peering-Interfaces gehängt, um die entsprechenden Routen kümmert sich dann babel. <br>
 
Die Adressen werden mit einer /32 Netzmaske an die Peering-Interfaces gehängt, um die entsprechenden Routen kümmert sich dann babel. <br>
 
So spart man sich ein paar IPv4 Adressen, da nicht immer ein /31 Subnetz für ein Peering drauf geht und (wenn auch unsauber) für jedes Peeringinterface die gleiche Adresse genutzt werden kann.<br>
 
So spart man sich ein paar IPv4 Adressen, da nicht immer ein /31 Subnetz für ein Peering drauf geht und (wenn auch unsauber) für jedes Peeringinterface die gleiche Adresse genutzt werden kann.<br>
Zeile 108: Zeile 125:
  
 
Möchte man auf seinem Gateway Dienste unabhängig von den Hoods anbieten, kann dafür die Peering-IP (für IPv6 ist daher ebenfalls ein [[Portal:Netz/IPv6#Transfer-IPs|Bereich]] dafür vorgesehen) gut verwendet werden.
 
Möchte man auf seinem Gateway Dienste unabhängig von den Hoods anbieten, kann dafür die Peering-IP (für IPv6 ist daher ebenfalls ein [[Portal:Netz/IPv6#Transfer-IPs|Bereich]] dafür vorgesehen) gut verwendet werden.
 +
 +
==== Öffentliche Adressen ====
 +
Damit das Internet erreicht werden kann, sind öffentliche IP Adressen nötig, die im Internet bekannt sind.
 +
 +
Diese können von verschiedenen Freifunkern bezogen werden, siehe [[IPv6]]
  
 
=== OS Settings ===
 
=== OS Settings ===
Zeile 146: Zeile 168:
  
 
Außerdem landen dann keine ICMP Pakete mit internen Adressen als Absender auf dem Uplink [dem Hoster].
 
Außerdem landen dann keine ICMP Pakete mit internen Adressen als Absender auf dem Uplink [dem Hoster].
 +
 +
Siehe auch [[MTU]]
  
 
==== Routing Tabelle für Freifunk ====
 
==== Routing Tabelle für Freifunk ====
Zeile 169: Zeile 193:
  
 
== Layer 3 ==
 
== Layer 3 ==
 +
=== Generelle Layer 3 Routing Regeln ===
 +
Damit Pakete vom Gateway selbst passend in das Freifunk Netz geroutet werden, sind einige Regeln nötig.
 +
 +
Diese können an die Debian Interfacekonfiguration des Loopback Interfaces hinzugefügt werden, damit sind sie direkt nach dem Boot des Servers verfügbar.
 +
 +
'''prio''' legt fest, in welcher Reihenfolge die Regeln abgearbeitet werden.
 +
Hier sollte sich zunächst an die im Wiki vorgegebene Reihenfolge gehalten werden, später kann man diese auf die eigenen Bedürfnisse anpassen.
 +
 +
Außerdem können auch FFF-interne IP Adressen (10.x.x.x, fd43:5602:29bd:ffff::xx) an das Loopback Interface gehängt werden.
 +
 +
<pre>
 +
iface lo inet static
 +
address 10.83.252.x/32
 +
 +
up ip -4 rule add to 10.0.0.0/8 prio 500 lookup fff
 +
down ip -4 rule del to 10.0.0.0/8 prio 500 lookup fff
 +
 +
        #DN42
 +
up ip -4 rule add to 172.20.0.0/14 prio 500 lookup fff
 +
down ip -4 rule del to 172.20.0.0/14 prio 500 lookup fff
 +
 +
iface lo inet6 static
 +
address fd43:5602:29bd:ffff::xx/128
 +
 +
up ip -6 rule add to fc00::/7 prio 500 lookup fff
 +
down ip -6 rule del to fc00::/7 prio 500 lookup fff
 +
</pre>
 +
 +
Für Pakete die auf Interfaces, welche für Freifunk verwendet werden (z.b. Clientnetz oder alle Babelverbindungen), ankommen muss auch expliziet in die fff table geguckt werden, dies muss für IPv4 und IPv6 gesetzt werden und sollte sinnvollerweise direkt an das entsprechende Interface geschrieben werden. Diese Regeln sollten eine möglich hohe Priorität haben (niedrige Zahl) damit Transit auf jeden Fall immer funktioniert.
 +
 +
<pre>
 +
[...]
 +
up ip -6 rule add iif $IFACE prio 10 table fff
 +
up ip rule add iif $IFACE prio 10 table fff
 +
[...]
 +
</pre>
  
 
=== Layer 3 Tunnelprotokolle ===
 
=== Layer 3 Tunnelprotokolle ===
Zeile 181: Zeile 241:
 
Es wird daher meist zwischen Servern in Rechenzentren eingesetzt. Der Traffic ist nicht verschlüsselt.
 
Es wird daher meist zwischen Servern in Rechenzentren eingesetzt. Der Traffic ist nicht verschlüsselt.
  
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/gre
+
[[Freifunk-Gateway_aufsetzen/gre]]
  
 
==== wireguard ====
 
==== wireguard ====
Zeile 189: Zeile 249:
 
Dennoch lassen sich je nach Hardware einige hundert MBit/s erreichen.
 
Dennoch lassen sich je nach Hardware einige hundert MBit/s erreichen.
  
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/wireguard
+
[[Freifunk-Gateway_aufsetzen/wireguard]]
  
 
=== Babel Routingprotokoll ===
 
=== Babel Routingprotokoll ===
Zeile 199: Zeile 259:
 
Babel tauscht die erreichbaren IP-Bereiche zwischen den Routern aus, sodass jeder Router weiß über welchen Weg er andere IP-Bereiche erreichen kann.
 
Babel tauscht die erreichbaren IP-Bereiche zwischen den Routern aus, sodass jeder Router weiß über welchen Weg er andere IP-Bereiche erreichen kann.
  
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Babel
+
[[Freifunk-Gateway_aufsetzen/Babel]]
  
 
=== Routing ins Internet ===
 
=== Routing ins Internet ===
Zeile 207: Zeile 267:
 
* Über einen VPN Anbieter ins Internet routen
 
* Über einen VPN Anbieter ins Internet routen
  
 +
[[Freifunk-Gateway_aufsetzen/Routing-ins-Internet]]
  
==== Über Babel an ein FFF-Exit-Gateway ====
+
== Layer 2 ==
 +
=== B.A.T.M.A.N. Advanced ===
 +
Zwischen den zentralen Knoten und dem dazugehörenden Gateway wird mithilfe von Tunneln und batman-adv ein großes Layer2 Netz aufgebaut. Dieses kann man sich vorstellen wie einen großen Switch zwischen dem Gateway und allen zentralen Knoten.
  
===== IPv4 =====
+
Für '''dezentrale Gateways''' ohne batman-adv gilt dennoch der "Konfigurationsabschnitt" von batman-adv für das Clientinterface, nur dass die batman-adv spezifischen Einstellungen weggelassen werden.
Babel trägt automatisch die von anderen Routern announcte "default-Route" in die 'fff' Tabelle ein.
 
  
Dadurch werden die Pakete, für die keine bessere ("more specific") Route gefunden wurde zu dem Server geleitet, der diese "default-Route" announct hat.
+
[[Freifunk-Gateway_aufsetzen/Batman-adv]]
  
Es sollte darauf geachtet werden, dass die Option net.ipv4.icmp_errors_use_inbound_ifaddr (siehe oben) gesetzt ist.
+
=== VPN für die Knoten ===
Ansonsten passieren lustige Dinge mit MTU, die dazu führen können, dass manche Seite nicht laden.
 
  
Außerdem sollte MSS Clamping aktiviert werden, damit auch Webseiten funktionieren, die ICMP Pakete blockieren (pfui!)
+
Um das batman-adv der Knoten mit dem des Gateways zu verbinden, sind Layer 2 Tunnel nötig.
TODO.
 
  
===== IPv6 =====
+
Dafür gibt es aktuell zwei verschiedene Möglichkeiten. Es wird in der aktuellen Firmware immer nur eine der beiden Varianten verwendet.
Bei IPv6 wird nicht wie bei IPv4 mit NAT gearbeitet. Daher sind öffentliche Adressen nötig, die dann auch passend geroutet werden müssen. (Nicht jeder Uplink lässt Pakete mit beliebigen Quelladressen durch).
+
Derzeit empfehlen wir aber trotz der deutlich langsameren Verbindungen fastd, da l2tp auf dem Server häufig instabil läuft.
  
Öffentliche IPv6 Adressen können hier bezogen werden: https://wiki.freifunk-franken.de/w/Portal:Layer3Peering#sonstiges
+
==== fastd ====
Auch für diese Adressen gilt: die passenden Routen werden im Freifunk announced, daher ist nichts weiter zu tun.
+
+ wird von fast allen Gateways eingesetzt</br>
 +
+ relativ einfach zu Konfigurieren</br>
 +
- Läuft im Userspace, daher recht performancehungrig</br>
  
.. Es können (und sollten, so die Möglichkeit besteht) natürlich auch eigene Adressen verwendet werden. :-)
+
[[Freifunk-Gateway_aufsetzen/VPN/fastd]]
  
 +
==== l2tp mit Tunneldigger ('''Nicht mehr unterstützt''') ====
 +
+ Läuft im Kernel, daher sehr schnell</br>
 +
- Läuft scheinbar instabil</br>
 +
- Aktuell kennen sich nur wenig Leute mit dieser Konfiguration aus</br>
  
==== Traffic direkt am Server ins Internet ausleiten ====
+
'''Achtung: Ab dem nächsten Firmware-Release (Stand: 07/2019) wird L2TP nicht mehr von der Router-Firmware unterstützt!'''
Bevor ihr "fremden" Traffic direkt ausleitet, solltet ihr euch unbedingt über die rechtlichen Konsequenzen informieren und euch mit eurem Provider oder Serververmieter in Verbindung setzen.
 
  
===== IPv4 =====
+
[[Freifunk-Gateway_aufsetzen/VPN/l2tp]]
  
Hierfür ist ein NAT nötig, dass die internen Adressen auf die passende öffentliche Adresse übersetzen kann.
+
=== B.A.T.M.A.N Gateway Selection ===
  
Weiterhin muss eine passende default Route in der 'fff' Tabelle angelegt werden:
+
Um zu steuern, von welchem der Gateways Clients Adressen und damit auch das Default-Gateway beziehen, setzen wir einen weiteren großen Pfusch ein: Die Batman Gatewayselection
  
<pre>
+
Diese filtert DHCP Offers von den Gateways und lässt nur die Offers eines bestimmten Gateways bis zum Client durch.
~$ ip route show tab main | grep default
 
default via 192.0.2.4 dev ens3
 
</pre>
 
  
<pre>
+
[[Freifunk-Gateway_aufsetzen/Batman-Gatewayselection]]
~$ ip route replace default via 192.0.2.4 dev ens3 proto static tab fff
 
</pre>
 
  
Das ganze muss dann noch Rebootfest gemacht werden. Dafür bietet es sich an, einen {pre-|post-}up Block in der Debian Interfacekonfiguration zu schreiben.
+
== Dienste ==
 +
=== SLAAC ===
 +
Bei IPv6 funktioniert die automatische Adresszuweisung über SLAAC.</br>
 +
Dafür ist ein Dienst nötig, der die Router Advertisements mit den passenden Subnetzen sendet.
  
Anschließend muss noch ein passendes NAT aktiviert werden.
+
[[Freifunk-Gateway_aufsetzen/radvd]]
  
<pre>
+
=== DHCP Server ===
iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
+
Die automatische Adresszuweisung funktioniert bei IPv4 mit DHCP.
</pre>
+
Es muss ein DHCP Server installiert werden, der die Adressen passend an die Clients verteilt.
  
Will man diese default Route auch anderen Routern zur Verfügung stellen, muss der Filter in '''/etc/babeld.conf''' angepasst werden:
+
[[Freifunk-Gateway_aufsetzen/DHCP]]
  
<pre>
+
=== DNS Server ===
redistribute ip 0.0.0.0/0 eq 0
+
Die Clients möchten Domains auflösen können, deshalb ist ein DNS-Server nötig.
</pre>
+
Zwar könnte einfach einer der öffentlichen {Google,Cloudflare,Quad9} DNS Server ausgeliefert werden, aber wir wollen die Anfragen ja nicht an große Unternehmen senden. :-)
Diese Zeile bedeutet: "Announce alle Routen aus der import-table, die innerhalb von 0.0.0.0/0 liegen und die Prefixlänge 0 haben."
 
  
===== IPv6 =====
+
Außerdem können mit einem eigenen (rekursiven) DNS-Server auch die IC-VPN DNS Server erreichbar gemacht werden.
(Achtung ungetestet!)
 
  
Hier wird ein freies /64 Netz für jede Hood benötigt. Das vorgehen ähnelt im Prinzip sehr den fd43 Adressen nur das im radvd eine Default Route mitgegeben wird. Natürlich muss dafür gesorgt werden, dass das Subnetz ins Internet kann bzw. aus dem Internet erreichbar ist.
+
Es kann entweder selbst ein DNS-Server betrieben werden, oder in DHCP und Router Advertisement auf einen (oder mehrere) der gemeinsam betriebenen DNS Server verwiesen werden.
  
Folgendes muss getan werden:
+
[[Freifunk-Gateway_aufsetzen/DNS]]
  
Aus dem Subnetz muss eine einzelne IP an das bat Interface:
+
=== http Server für Hoodfile ===
<pre>
+
Das Gateway muss ein aktuelles Hoodfile an Meshknoten ausliefern können. Dafür ist ein HTTP Server nötig.
[...]
 
post-up ip -6 addr add 2001:db8::1/64 dev $IFACE
 
[...]
 
</pre>
 
Eine Route muss in die fff Tabelle:
 
<pre>
 
[...]
 
post-up ip -6 route replace 2001:db8::1/64 dev $IFACE proto static table fff
 
[...]
 
</pre>
 
Im radvd muss eine default route announced werden dazu AdvDefaultLifetime nicht auf 0 setzen sondern erhöhen (z.b. 600). Weiterhin muss das Subnetz auch announced werden in /etc/radvd.conf:
 
<pre>
 
[...]
 
        prefix 2001:db98::/64 {
 
                AdvOnLink on;
 
                AdvAutonomous on;
 
        };
 
 
 
[...]
 
</pre>
 
 
 
==== VPN-Tunnel zu Anonymisierungsdienst ====
 
Nicht zu empfehlen, sollte nur im Notfall verwendet werden wenn keine andere Option vorhanden ist!
 
 
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/VPN-Exit
 
 
 
== Layer 2 ==
 
=== Batman-adv ===
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Batman-adv
 
  
=== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ===
+
Dies ist nur nötig, wenn der zentrale keyxchange verwendet wird.
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/interface
 
  
=== VPN für die Knoten ===
+
[[Freifunk-Gateway_aufsetzen/http]]
 
 
Es kann mit dem keyxchangev2 nun jedes VPN Protokoll einzeln verwendet werden. Fastd ist absofort nicht mehr verpflichtend es kann ein reines l2tp Gateway betrieben werden. Derzeit wird aber empfohlen (nur) fastd zu verwenden, weil l2tp auf dem Server instabil sein kann. l2tp hat als größten Vorteil die niedrigere CPU-Last und damit größeren Durchsatz v.a. auf den Routern, fastd hat als größten Vorteil neben der Stabilität die einfachere Konfiguration und bessere Verständlichkeit.
 
 
 
==== fastd ====
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/VPN/fastd
 
  
==== l2tp mit Tunneldigger ====
+
=== Alfred Master (Monitoring) ===
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/VPN/l2tp
+
Die Nodewatcher-Daten aller Knoten werden in einem Alfred Server gesammelt und am Gateway dann gemeinsam ans Monitoring übertragen.
  
=== B.A.T.M.A.N Gateway Selection ===
+
[[Freifunk-Gateway_aufsetzen/Alfred]]
  
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Batman-Gatewayselection
+
Für dezentrale Gateways kann der Zwischenschritt über Alfred ausgelassen und die Daten direkt ans Monitoring gesendet werden.
 +
Dafür muss noch eine Anleitung geschrieben werden.
  
== Dienste ==
 
 
=== ntp Server ===
 
=== ntp Server ===
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/ntp
+
Ein Dienst, der den Routern die aktuelle Uhrzeit bereitstellt.
(optional)
+
Ist nicht für jedes Gateway zwingend nötig, es kann auch der NTP eines anderen Gateways verwendet werden.
  
=== http Server für Hoodfile ===
+
[[Freifunk-Gateway_aufsetzen/ntp]]
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/http
 
 
 
=== Alfred Master aufsetzen (Monitoring) ===
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Alfred
 
  
 
=== gwinfo (optional, Gateway-Daten für Monitoring) ===
 
=== gwinfo (optional, Gateway-Daten für Monitoring) ===
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/gwinfo
+
gwinfo ist ein Zusätzliches Script, das Informationen vom Gateway sammelt und ebenfalls ans Monitoring sendet.
(optional)
+
Das ganze ist optional.
  
=== DNS Server ===
+
[[Freifunk-Gateway_aufsetzen/gwinfo]]
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/DNS
 
 
 
=== DHCP Server ===
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/DHCP
 
 
 
=== radvd ===
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/radvd
 
  
 
= Einbringen des Gateways in die Hood / Keyserver =
 
= Einbringen des Gateways in die Hood / Keyserver =
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[KeyXchange#fff-netmon2]].
+
Abschliessend kann das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[KeyXchange#fff-netmon2]]. Alternativ kann die Hood natürlich auch mit festen Hoodfiles betrieben werden
  
 
Bevor man das Gateway der Hood zuordnet, empfiehlt sich ein persönliches Review durch einen erfahrenen Gateway-Admin. Das neue Gateway kann auch versuchsweise zunächst einer Test-Hood zugeordnet werden, um es erstmal auf korrekte Funktion zu überprüfen.
 
Bevor man das Gateway der Hood zuordnet, empfiehlt sich ein persönliches Review durch einen erfahrenen Gateway-Admin. Das neue Gateway kann auch versuchsweise zunächst einer Test-Hood zugeordnet werden, um es erstmal auf korrekte Funktion zu überprüfen.
 
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)
 
<br>
 
  
 
= Optimierungen =
 
= Optimierungen =
 
* ARP Cache
 
* ARP Cache
 
* nf_conntrack
 
* nf_conntrack
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Optimierungen
+
[[Freifunk-Gateway_aufsetzen/Optimierungen]]
  
= Fehlersuche =
+
= Statistik =
* Was so alles in einem Layer 2 Netz passieren kann
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Fehlersuche
 
  
= Port Sperren =
+
== MRTG ==
Es empfiehlt sich folgende Ports / IPs zu sperren
+
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Statistik/mrtg
  
Ausgehend:
+
= Fehlersuche =
* tcp-25
+
Zum finden von Fehlern, die erst Auftreten, wenn die Konfiguration schon einmal funktioniert hat, kann folgende Seite hilfreich sein:
* tcp-137
 
* udp-137
 
* ip-10.0.0.0/8
 
* ip-172.16.0.0/12
 
* ip-192.168.0.0/16
 
* ip-100.64.0.0/10
 
* ip-169.254.0.0/16
 
* ip-192.0.0.0/24
 
* ip-192.0.2.0/24
 
* ip-198.18.0.0/15
 
* ip-198.51.100.0/24
 
* ip-203.0.113.0/24
 
* ip-0.0.0.0/8
 
 
 
 
 
Gateways, welche beim Hoster Hetzner stehen, sollte weitere Vorkehrungen treffen. Hetzner monitored den Traffic, den die Gateways verursachen. Sollten Verbindungsversuche zu nicht gerouteten IPs dabei sein, generiert Hetzner Abuse und schickt es (Achtung!) nicht an die hinterlegte Abuse-Adresse. Was man dagegen tun kann ist hier beschrieben: [[Hetzner]]
 
  
'''-> Nur nötig wenn Traffic direkt ins Internet geleitet wird!'''
+
[[Freifunk-Gateway_aufsetzen/Fehlersuche]]
  
 
= Einzelne IPs oder Services über anderen Server routen =
 
= Einzelne IPs oder Services über anderen Server routen =
Zeile 388: Zeile 382:
 
wird fast nie benötigt, war für mich aber immer ein schönes Nachschlagewerk deshalb lass ich das ganz unten stehen:
 
wird fast nie benötigt, war für mich aber immer ein schönes Nachschlagewerk deshalb lass ich das ganz unten stehen:
  
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/spezielles_routing
+
[[Freifunk-Gateway_aufsetzen/spezielles_routing]]
  
 
[[Kategorie:Technik]]
 
[[Kategorie:Technik]]
 
[[Kategorie:Hoods-V2]]
 
[[Kategorie:Hoods-V2]]
 
[[Kategorie:Gateways]]
 
[[Kategorie:Gateways]]

Version vom 5. Dezember 2019, 13:42 Uhr

Preface

Für das Aufsetzen eines Freifunk-Gateway gibt es kein universelles Kochrezept. Auch erfahrene Admins erfahren bei der Installation kleinere und grössere Herausforderungen, die es zu überwinden gilt. Unterschiedliche Softwareinstallationen, Netzwerkkonfigurationen, Hoster und VPN Anbieter können Anpassungen zu der hier präsentierten Vorgehensweise notwendig werden lassen, z.B. indem Pakete nach installiert werden oder Netzwerkkonfigurationen angepasst werden müssen. Um dies zu erleichtern, versucht der Artikel nicht nur die Konfiguration darzulegen, die in diesem spezifischen Fall funktioniert hat ("Know-How"), sondern versucht auch kurz auf die Hintergründe einzugehen, um ggf. eine Anpassung zu erreichen ("Know-Why").

Die Anleitung dient dazu, den Einstig zu erleichtern.
Viele der Dinge können später auf die eigenen Bedürfnisse angepasst und zugeschnitten werden.

Die Anleitung hat keine Garantie auf Vollständigkeit und wird stetig verändert und verbessert.
Wenn du beim Installieren auf Probleme oder Fehler stößt: Der nächste freut sich, wenn er auf diesen Fehler nicht mehr stößt oder eine entsprechende Anmerkung im Wiki findet. :-)

Freifunk Franken ist "Development in Progress", d.h. eine Konfiguration die heute funktioniert, wird morgen durch eine andere und vielleicht sogar bessere abgelöst. Ein einmal aufgesetztes Gateway muss sich so der Entwicklung anpassen.

Für Rat und Tat empfiehlt sich die Freifunk Franken Development und die Freifunk Franken Gateway Mailingliste.

Referenzen / Andere Freifunk HowTo's

Voraussetzungen

Was der Betreiber mitbringen sollte

  • Grundlegende Kenntnisse mit IP-Routing (IPv4 und IPv6)
  • Motivation, etwas [jede Menge] dazuzulernen und sich aktiv mit der Materie auseinanderzusetzen.
  • Das Freifunk Netz ist der optimale Ort, um sich in dieser Richtung neue Kenntnisse anzueignen - zumindest wenn man sich dann auch damit (und. v.a. mit den auftretenden Problemen) auseinandersetzt.
  • Es gibt viele nette Leute im IRC, die immer gerne helfen, wenn die Motivation da ist, sich auch selbst mit dem Problem zu befassen.
  • Für die schnelle Abstimmung unter den GW Betreibern sollte sich jeder Betreiber auf der freifunk-gateway Mailingliste setzen. Die "große" Liste und die dev-Liste sind ebenfalls hilfreich.
  • Ohne Vorkenntnisse ist es schwierig, aber ganz und gar nicht unmöglich ein Gateway aufzusetzen. Auch hier gilt wieder: Es wird gerne geholfen, wenn man sich mit Problemen einigermaßen selbstständig auseinandersetzt und konkrete Fragen stellt.
  • Bereitschaft mitzuhelfen, das Wiki aktuell zu halten, damit die Ressourcenplanung (IPs!) funktioniert und für Notfälle die wichtigsten Infos und Ansprechpartner zu den Servern vorhanden sind. Die wichtigsten Seiten sind Server, Portal:Netz und Portal:Netz/IPv6.
  • Ein wenig Zeit - sowohl fürs Aneignen des Verständnisses als auch fürs Aufsetzen an sich. Gehe erstmal von ganz grob 5-20 Stunden Arbeitszeit aus, um von einem "nackten" Server zu einem voll funktionstüchtigen GW zu kommen, das ja doch aus recht vielen verschiedenen Diensten besteht. Nach der Ersteinrichtung sollte man regelmäßig ein wenig Zeit investieren, um zu schauen, ob alles in Ordnung ist, Updates zu fahren, Änderungen in der Infrastruktur nachzupflegen, sich tiefergend mit der Materie zu beschäftigen, etc.

Was der Server können muss

  • Öffentliche IPv4 und IPv6 Adresse
    • Leider aktuell noch zu viele IPv4 Anschlüsse, um IPv4 außen vor zu lassen. :-(
    • IPv6 ist pflicht.
  • Kernelmodule laden (Bestimmte Virtualisierungslösungen wie OpenVZ sind daher nicht möglich)
  • Nur relativ wenig CPU und RAM nötig
  • dafür relativ viel Traffic (Je nach Größe und Anzahl der Hoods durchaus im ein- bis niedrigen zweistelligen TB Bereich)


  • fastd VPN
  • Batman (Compat15)
  • DHCP
  • Router Advertisements
  • Routing
  • Babel Routing Protokoll
  • Webserver für Hoodfiles

Anbindung an andere Netze

Neben unserem eigenen Freifunknetz gibt es weitere Netzwerke mit denen sich ein Peering lohnt:

  • DN42
    • BGP
    • Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™
  • ChaosVPN
    • Tinc
    • Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.


Server-Anbieter

Hoster, bei denen gute Erfahrungen gemacht wurden

Diese unvollständige, nicht abschließende Liste von Hostern dient nur der Orientierung. Solange ein Hoster die weiter oben genannten Voraussetzungen erfüllt, ist er für ein Freifunk Gateway geeignet.

Umso mehr verschiedene Hoster im Freifunknetz, umso besser.

  • Hetzner (Nürnberg, Falkenstein, Helsinki)
    • Cloud Server, 20TB Traffic 2,96€/Monat
    • Wird bedingt des vielen verfügbaren Traffics fürs Geld sehr viel genutzt
    • Hetzner-interner Traffic wird nicht berechnet
  • xirra (Core-Backbone, NBG)
    • KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.


Hoster mit bekannten Problemen

  • netcup
    • Aus einem bisher nicht abschließend geklärtem Grund funktioniert GRE über IPv6 bei den VMs nicht.
    • Techniker ist bisher _nicht_ informiert

Installation

Die Installation des Betriebssystems, Absicherung des Servers, Installieren von Updates usw. sind NICHT Gegenstand dieser Anleitung. Trotzdem kurz einige Hinweise:

  • Empfohlenes Betriebssystem: Debian
    • Die Anleitung basiert aktuell auf Debian 10 (Buster). Für Einsteiger wird dringend empfohlen mit dieser Version anzufangen.
  • Sicherheit
    • SSH Login nur mit Keys, Login per Passwort abschalten (siehe hier)
    • root-Login per SSH höchstens per Key, besser abschalten
    • Hier bekommst du weitere Tipps zur Absicherung eines Debian Servers

Vorbereitung

IP-Adressen und DHCP Range des Gateway

Um Doppelbelegungen zu vermeiden, müssen diese auch im Wiki eingetragen werden.

An dieser Stelle sollte man sich unbedingt mit Subnetzen und der CIDR-Notation vertraut machen, falls einem das (noch) Fremdworte sind.

Private FFF IPs

Für jede Hood reserviert man sich einen IPv4 bzw. IPv6 Adressbereich, mit welchem die Knoten und Clients versorgt werden.

Für die Hoods muss bei IPv4 noch ein Bereich festgelegt werden, aus dem dann später Adressen verteilt werden. Dieser muss:

  • innerhalb des Subnetzes der Hood liegen.
  • innerhalb der Hood eindeutig sein. (Darf sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten)
  • vollständig außerhalb des statischen Bereichs der Hood liegen.

Gleichzeitig teilt der DHCP-Server den Clients mit, welchen DNS-Server und welches Default-Gateway die Clients verwenden sollen. Die Gesamtgröße aller verwalteten DHCP-Bereiche des Servers hat so direkten Einfluss auf die Arbeitslast, die der den Clients zugeteilte DNS-Server und der zugeteilte Internet-Gateway später sehen.

Bei IPv6 wird nur Gateway, DNS-Server und Subnetz per Router Advertisement in der Hood bekannt gemacht, den Rest erledigen die Clients.

Peering-IPs

Für die Peerings verwenden wir Adressen aus einem speziell dafür vorgesehenen Bereich.
Die Adressen werden mit einer /32 Netzmaske an die Peering-Interfaces gehängt, um die entsprechenden Routen kümmert sich dann babel.
So spart man sich ein paar IPv4 Adressen, da nicht immer ein /31 Subnetz für ein Peering drauf geht und (wenn auch unsauber) für jedes Peeringinterface die gleiche Adresse genutzt werden kann.

Bei IPv6 genügen die Link-Local Adressen.

Möchte man auf seinem Gateway Dienste unabhängig von den Hoods anbieten, kann dafür die Peering-IP (für IPv6 ist daher ebenfalls ein Bereich dafür vorgesehen) gut verwendet werden.

Öffentliche Adressen

Damit das Internet erreicht werden kann, sind öffentliche IP Adressen nötig, die im Internet bekannt sind.

Diese können von verschiedenen Freifunkern bezogen werden, siehe IPv6

OS Settings

IP-Forwarding

Per default leitet Debian keine Pakete weiter, die unser Gateway erreichen. Deswegen muss IP-Forwarding aktiviert werden. :

Manuell (nur bis zum reboot aktiv):

echo "1" > /proc/sys/net/ipv4/ip_forward

echo "1" > /proc/sys/net/ipv6/conf/default/forwarding
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding


sysctl Einstellungen können in der Datei /etc/sysctl.conf dauerhaft eingestellt werden.

Dort gibt es für das Forwarding bereits die passenden Zeilen, die nur einkommentiert werden müssen:


# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1

ICMP Fehlerpakete für IPv4

Damit ICMP hinter unserem NAT korrekt funktioniert, müssen die ICMP Fehler passend geroutet werden, dass sie beim NAT-Server landen. Das kann in Linux mit der Option "net.ipv4.icmp_errors_use_inbound_ifaddr = 1" erreicht werden.

Analog zu oben sollte diese Einstellung in sysctl.conf eingetragen werden, damit sie rebootfest ist:

net.ipv4.icmp_errors_use_inbound_ifaddr = 1

Außerdem landen dann keine ICMP Pakete mit internen Adressen als Absender auf dem Uplink [dem Hoster].

Siehe auch MTU

Routing Tabelle für Freifunk

Für die Routen im Freifunk Franken Netz muss eine eigene Routingtabelle angelegt werden.

Damit die Tabelle auch mit Name aufrufbar ist, sollten Tabellennummer und Name in /etc/iproute2/rt_tables eingetragen werden:

10     fff

Der Inhalt der Routingtabelle kann später mit

ip route show table fff
bzw.
ip -6 route show tab fff

angezeigt werden.

Die Konfiguration wird exemplarisch für das Einrichten eines GW's in der Fürther Hood beschrieben, wobei erläutert wird, welche Anpassungen für nicht-Fürther Hoods gemacht werden müssen.

Layer 3

Generelle Layer 3 Routing Regeln

Damit Pakete vom Gateway selbst passend in das Freifunk Netz geroutet werden, sind einige Regeln nötig.

Diese können an die Debian Interfacekonfiguration des Loopback Interfaces hinzugefügt werden, damit sind sie direkt nach dem Boot des Servers verfügbar.

prio legt fest, in welcher Reihenfolge die Regeln abgearbeitet werden. Hier sollte sich zunächst an die im Wiki vorgegebene Reihenfolge gehalten werden, später kann man diese auf die eigenen Bedürfnisse anpassen.

Außerdem können auch FFF-interne IP Adressen (10.x.x.x, fd43:5602:29bd:ffff::xx) an das Loopback Interface gehängt werden.

iface lo inet static
	address 10.83.252.x/32

	up ip -4 rule add to 10.0.0.0/8 prio 500 lookup fff
	down ip -4 rule del to 10.0.0.0/8 prio 500 lookup fff

        #DN42
 	up ip -4 rule add to 172.20.0.0/14 prio 500 lookup fff
	down ip -4 rule del to 172.20.0.0/14 prio 500 lookup fff

iface lo inet6 static
	address fd43:5602:29bd:ffff::xx/128

	up ip -6 rule add to fc00::/7 prio 500 lookup fff
	down ip -6 rule del to fc00::/7 prio 500 lookup fff

Für Pakete die auf Interfaces, welche für Freifunk verwendet werden (z.b. Clientnetz oder alle Babelverbindungen), ankommen muss auch expliziet in die fff table geguckt werden, dies muss für IPv4 und IPv6 gesetzt werden und sollte sinnvollerweise direkt an das entsprechende Interface geschrieben werden. Diese Regeln sollten eine möglich hohe Priorität haben (niedrige Zahl) damit Transit auf jeden Fall immer funktioniert.

[...]
up ip -6 rule add iif $IFACE prio 10 table fff
up ip rule add iif $IFACE prio 10 table fff
[...]

Layer 3 Tunnelprotokolle

Für Babel ist eine direkte Verbindung mit dem Nachbar nötig (Ethernet, WiFi, ..). Wenn keine direkte Verbindung besteht, kann mithilfe eines Layer 3 Tunnels eine direkte Verbindung durch ein bestehendes Netzwerk (z.B. das Internet) hergestellt werden.

GRE

GRE benötigt an beiden Enden eine feste IP-Adresse, da die Konfiguration komplett statisch ist. Außerdem unterstützen viele NATs GRE nicht, ggf. muss bei IPv4 eine passende Portweiterleitung angelegt werden.

Dafür ist es ein sehr einfaches Protokoll, leicht zu debuggen, sehr leightgewichtig und dadurch extrem schnell.

Es wird daher meist zwischen Servern in Rechenzentren eingesetzt. Der Traffic ist nicht verschlüsselt.

Freifunk-Gateway_aufsetzen/gre

wireguard

Wireguard benötigt nur an einem Ende eine feste IP Adresse. Außerdem kann es leicht hinter NAT betrieben werden, da UDP verwendet wird.

Dafür ist das Protokoll etwas komplizierter (und verschlüsselt) und dadurch auch etwas langsamer. Dennoch lassen sich je nach Hardware einige hundert MBit/s erreichen.

Freifunk-Gateway_aufsetzen/wireguard

Babel Routingprotokoll

Zwischen den Routern werden Routen über ein Routingprotokoll ausgetauscht.

Bei Freifunk Franken verwenden wir dafür aktuell Babel.

Babel tauscht die erreichbaren IP-Bereiche zwischen den Routern aus, sodass jeder Router weiß über welchen Weg er andere IP-Bereiche erreichen kann.

Freifunk-Gateway_aufsetzen/Babel

Routing ins Internet

Es gibt verschiedene Möglichkeiten Traffic ins Internet zu routen.

  • Einen anderen Router ins Internet routen lassen und dessen angebotene Route nutzen.
  • Direkt am eigenen Server ins Internet routen
  • Über einen VPN Anbieter ins Internet routen

Freifunk-Gateway_aufsetzen/Routing-ins-Internet

Layer 2

B.A.T.M.A.N. Advanced

Zwischen den zentralen Knoten und dem dazugehörenden Gateway wird mithilfe von Tunneln und batman-adv ein großes Layer2 Netz aufgebaut. Dieses kann man sich vorstellen wie einen großen Switch zwischen dem Gateway und allen zentralen Knoten.

Für dezentrale Gateways ohne batman-adv gilt dennoch der "Konfigurationsabschnitt" von batman-adv für das Clientinterface, nur dass die batman-adv spezifischen Einstellungen weggelassen werden.

Freifunk-Gateway_aufsetzen/Batman-adv

VPN für die Knoten

Um das batman-adv der Knoten mit dem des Gateways zu verbinden, sind Layer 2 Tunnel nötig.

Dafür gibt es aktuell zwei verschiedene Möglichkeiten. Es wird in der aktuellen Firmware immer nur eine der beiden Varianten verwendet. Derzeit empfehlen wir aber trotz der deutlich langsameren Verbindungen fastd, da l2tp auf dem Server häufig instabil läuft.

fastd

+ wird von fast allen Gateways eingesetzt
+ relativ einfach zu Konfigurieren
- Läuft im Userspace, daher recht performancehungrig

Freifunk-Gateway_aufsetzen/VPN/fastd

l2tp mit Tunneldigger (Nicht mehr unterstützt)

+ Läuft im Kernel, daher sehr schnell
- Läuft scheinbar instabil
- Aktuell kennen sich nur wenig Leute mit dieser Konfiguration aus

Achtung: Ab dem nächsten Firmware-Release (Stand: 07/2019) wird L2TP nicht mehr von der Router-Firmware unterstützt!

Freifunk-Gateway_aufsetzen/VPN/l2tp

B.A.T.M.A.N Gateway Selection

Um zu steuern, von welchem der Gateways Clients Adressen und damit auch das Default-Gateway beziehen, setzen wir einen weiteren großen Pfusch ein: Die Batman Gatewayselection

Diese filtert DHCP Offers von den Gateways und lässt nur die Offers eines bestimmten Gateways bis zum Client durch.

Freifunk-Gateway_aufsetzen/Batman-Gatewayselection

Dienste

SLAAC

Bei IPv6 funktioniert die automatische Adresszuweisung über SLAAC.
Dafür ist ein Dienst nötig, der die Router Advertisements mit den passenden Subnetzen sendet.

Freifunk-Gateway_aufsetzen/radvd

DHCP Server

Die automatische Adresszuweisung funktioniert bei IPv4 mit DHCP. Es muss ein DHCP Server installiert werden, der die Adressen passend an die Clients verteilt.

Freifunk-Gateway_aufsetzen/DHCP

DNS Server

Die Clients möchten Domains auflösen können, deshalb ist ein DNS-Server nötig. Zwar könnte einfach einer der öffentlichen {Google,Cloudflare,Quad9} DNS Server ausgeliefert werden, aber wir wollen die Anfragen ja nicht an große Unternehmen senden. :-)

Außerdem können mit einem eigenen (rekursiven) DNS-Server auch die IC-VPN DNS Server erreichbar gemacht werden.

Es kann entweder selbst ein DNS-Server betrieben werden, oder in DHCP und Router Advertisement auf einen (oder mehrere) der gemeinsam betriebenen DNS Server verwiesen werden.

Freifunk-Gateway_aufsetzen/DNS

http Server für Hoodfile

Das Gateway muss ein aktuelles Hoodfile an Meshknoten ausliefern können. Dafür ist ein HTTP Server nötig.

Dies ist nur nötig, wenn der zentrale keyxchange verwendet wird.

Freifunk-Gateway_aufsetzen/http

Alfred Master (Monitoring)

Die Nodewatcher-Daten aller Knoten werden in einem Alfred Server gesammelt und am Gateway dann gemeinsam ans Monitoring übertragen.

Freifunk-Gateway_aufsetzen/Alfred

Für dezentrale Gateways kann der Zwischenschritt über Alfred ausgelassen und die Daten direkt ans Monitoring gesendet werden. Dafür muss noch eine Anleitung geschrieben werden.

ntp Server

Ein Dienst, der den Routern die aktuelle Uhrzeit bereitstellt. Ist nicht für jedes Gateway zwingend nötig, es kann auch der NTP eines anderen Gateways verwendet werden.

Freifunk-Gateway_aufsetzen/ntp

gwinfo (optional, Gateway-Daten für Monitoring)

gwinfo ist ein Zusätzliches Script, das Informationen vom Gateway sammelt und ebenfalls ans Monitoring sendet. Das ganze ist optional.

Freifunk-Gateway_aufsetzen/gwinfo

Einbringen des Gateways in die Hood / Keyserver

Abschliessend kann das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => KeyXchange#fff-netmon2. Alternativ kann die Hood natürlich auch mit festen Hoodfiles betrieben werden

Bevor man das Gateway der Hood zuordnet, empfiehlt sich ein persönliches Review durch einen erfahrenen Gateway-Admin. Das neue Gateway kann auch versuchsweise zunächst einer Test-Hood zugeordnet werden, um es erstmal auf korrekte Funktion zu überprüfen.

Optimierungen

  • ARP Cache
  • nf_conntrack

Freifunk-Gateway_aufsetzen/Optimierungen

Statistik

MRTG

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Statistik/mrtg

Fehlersuche

Zum finden von Fehlern, die erst Auftreten, wenn die Konfiguration schon einmal funktioniert hat, kann folgende Seite hilfreich sein:

Freifunk-Gateway_aufsetzen/Fehlersuche

Einzelne IPs oder Services über anderen Server routen

wird fast nie benötigt, war für mich aber immer ein schönes Nachschlagewerk deshalb lass ich das ganz unten stehen:

Freifunk-Gateway_aufsetzen/spezielles_routing