Freifunk-Gateway aufsetzen: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
(radvd)
(Installation)
(200 dazwischenliegende Versionen von 11 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{|cellpadding="4" cellspacing="8" style="font-size:100%; background: #FF4000; color: #ffffff; text-align: center; width:100%;"
 
|'''Achtung:''' Die Seite wird aktuell für den KeyxchangeV2 umgebaut.<br>Daher könnte sie zeitweise Inkonsistenzen enthalten und wird sich inhaltlich stark verändern. Den letzten V1-Stand gibt es [[Special:PermanentLink/11209|hier]]
 
|}
 
 
 
__TOC__
 
__TOC__
 
[[Kategorie:Technik]]
 
[[Kategorie:Technik]]
  
 
= 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 13: Zeile 15:
 
Für Rat und Tat empfiehlt sich die Freifunk Franken Development und die Freifunk Franken Gateway Mailingliste.
 
Für Rat und Tat empfiehlt sich die Freifunk Franken Development und die Freifunk Franken Gateway Mailingliste.
  
Zum den Änderungen vom KeyxchangeV1 zum KeyxchangeV2 Gateway geht's hier: https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/keyxchangev2
+
'''Referenzen / Andere Freifunk HowTo's'''
 
 
 
 
 
 
= Referenzen / Andere Freifunk HowTo's =
 
 
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway  
 
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway  
 
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway
 
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway
  
 
+
== Voraussetzungen ==
 
 
= Voraussetzungen =
 
=== Was der Server können muss ===
 
* Öffentliche IPv4 und IPv6 Adresse
 
* Kernelmodule laden
 
* 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)
 
  
 
=== Was der Betreiber mitbringen sollte ===
 
=== Was der Betreiber mitbringen sollte ===
Zeile 36: 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 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 ===
 +
* Ö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)
 +
 
  
=== Was das Gateway können muss ===
 
 
* fastd VPN
 
* fastd VPN
 
* Batman ''(Compat15)''
 
* Batman ''(Compat15)''
Zeile 48: Zeile 47:
 
* Babel Routing Protokoll
 
* Babel Routing Protokoll
 
* Webserver für Hoodfiles
 
* Webserver für Hoodfiles
 
Näheres ist unter [[#Dienste|Dienste]] beschrieben.
 
 
=== Anonymisierung (Störerhaftung) ===
 
Sofern der Server nicht über einen Uplink verfügt, wo es egal ist was durchgeht (unseriöse Bulletproof-Hoster), möchte man vermutlich den Traffic aus dem Freifunk-Netz durch ein VPN ins Internet schieben.
 
 
Auf längere Sicht, wäre es natürlich wünschenswert, wenn die Problematik der Störerhaftung in ihrer derzeitigen Form wegfällt um beispielsweise eine dezentralere Infrastruktur zu erlauben.
 
 
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:
 
 
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)
 
** Bis zu drei gleichzeitige Verbindungen
 
** Kann man anonym mit Bitcoin bezahlen
 
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration
 
*** Server in den Niederlanden sind abends oft stark ausgelastet
 
**(Gute Erfahrungen in Lübeck)
 
 
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)
 
** Drittes Oktett durch Auswahl des normalerweise per round.robin-dns ausgewählten OpenVPN-Servers bestimmbar, das letzte Oktett ist immer gleich. Somit muss man sich keine dynamisch vergebenen IP-Adressen mit anderen teilen. Verbindungen daher durch die Anzahl der OpenVPN-Server (derzeit 3; unterschiedliche Ports nicht ausprobiert) beschränkt.
 
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™
 
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.
 
**Blockiert Port 25 derzeit nicht.
 
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.
 
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert
 
 
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)
 
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)
 
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.
 
** Möchten bald auch IPv6 anbieten.
 
** Angeblich Reseller von relakks
 
 
* Cyberghost
 
** blockt alle SMTP Ports!!
 
 
* Perfect Privacy
 
 
* AzireVPN
 
 
 
Ungetestet:
 
* [https://www.anonine.com/en Anonine VPN] (Portlane)
 
* [https://privacy.io/ privacy.io] (Portlane)
 
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)
 
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)
 
  
 
== Anbindung an andere Netze ==
 
== Anbindung an andere Netze ==
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu  verbinden:
+
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
 
** BGP
 
** BGP
 
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™
 
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™
** Hat Routen ins ChaosVPN und IC-VPN, <strike>wer faul ist bei der Konfiguration deckt damit also alles™</strike> ab nicht alle Routen vom IC-VPN oder ChaosVPN werden im DN42 verteilt, ob man das will kann ggf nochmal besprechen.
 
  
 
* ChaosVPN
 
* ChaosVPN
Zeile 111: Zeile 65:
 
<br>
 
<br>
  
== Server-Anbieter die empfehlenswert sind ==
+
== Server-Anbieter==
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)
 
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.
 
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)
 
** Bezahlbarer Extratraffic 1,19 €/TB, KVM
 
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)
 
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)
 
** Achtung: Nur Xen oder Xen HVM funktionieren
 
* [http://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.
 
* [http://buyvm.net/ BuyVM]
 
** Begrenztes Angebot, das in Stößen rausgegeben wird. 2.50$/TB Extratraffic. Nur KVM ist brauchbar für diesen Zweck. USA Ost- und Südküste. TOS sagt, dass man da theoretisch kein weiteres VPN ins Netz brauchen würde.
 
* [http://webhod.de webhod]
 
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]
 
<br>
 
  
== Server-Anbieter die '''nicht''' empfehlenswert sind ==
+
=== Hoster, bei denen gute Erfahrungen gemacht wurden ===
* [http://www.wrzhost.com/ WRZhost]
+
Diese unvollständige, nicht abschließende Liste von Hostern dient nur der Orientierung.
** Aktivierung des V-Servers erst auf mehrfache Nachfrage, anschließend falsches Betriebssystem. Außerdem nur OpenVZ und somit nicht für FreiFunk nutzbar. Für andere Zwecke sicher brauchbar, da gut angebunden und offshore.
+
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.
  
 +
* [https://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix 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
  
= Dienste =
+
* [https://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)
== B.A.T.M.A.N. ==
+
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.
B.A.T.M.A.M. wird bei uns als Layer2 Routing-Protokoll (Ja, klingt kaputt. Ist es auch) eingesetzt, um WLAN-Mesh zu ermöglichen.
 
Für Linux gibt es dafür das B.A.T.M.A.N. Advanced Kernel-Modul.
 
  
Die Version, die beim Kernel von Debian Stretch mit dabei ist (v2016.4) ist Compat15, was die aktuell verwendete Compat-Version ist. (siehe [https://www.open-mesh.org/projects/batman-adv/wiki/Compatversion hier])
 
  
Wenn man möchte, kann man sich die aktuellste Version aus dem Open-Mesh Git kompilieren und installieren.
+
=== Hoster mit bekannten Problemen ===
  
'''Hinweis''': Wird der Kernel aktualisiert, müssen alle selbstkompilierten Kernelmodule erneut gegen die aktualisierte Kernelversion gebaut und danach installiert werden! Folglich muss ein selbstkompiliertes batman_adv nach jedem Kernelupdate neu gebaut und installiert werden. Für den Anfang empfiehlt es sich, mit dem mitgelieferten batman_adv zu arbeiten.
+
* [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
  
Das Kernel-Modul kann testweise mit folgendem Befehl geladen werden:
+
= Installation =
<code>
+
Die Installation des Betriebssystems, Absicherung des Servers, Installieren von Updates usw. sind '''NICHT''' Gegenstand dieser Anleitung. Trotzdem kurz einige Hinweise:
modprobe batman-adv
 
</code>
 
  
Im Kernel Log sollte das Laden protokolliert werden:
+
* Empfohlenes Betriebssystem: Debian
<pre>
+
** Die Anleitung basiert aktuell auf '''Debian 10 (Buster)'''. Für Einsteiger wird dringend empfohlen mit dieser Version anzufangen.
~# dmesg | grep batman_adv
+
* Sicherheit
batman_adv: B.A.T.M.A.N. advanced 2018.0 (compatibility version 15) loaded
+
** SSH Login nur mit Keys, Login per Passwort abschalten (siehe [https://www.thomas-krenn.com/de/wiki/OpenSSH_Public_Key_Authentifizierung_unter_Ubuntu hier])
</pre>
+
** root-Login per SSH höchstens per Key, besser abschalten
 +
** Hier bekommst du weitere Tipps zur [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers Absicherung eines Debian Servers]
  
 +
== Vorbereitung ==
 +
=== IP-Adressen und DHCP Range des Gateway ===
  
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules der Eintrag "batman-adv" hinzugefügt wird:
+
Um Doppelbelegungen zu vermeiden, müssen diese auch im Wiki eingetragen werden.
  
<pre>
+
An dieser Stelle sollte man sich unbedingt mit Subnetzen und der [[CIDR|CIDR-Notation]] vertraut machen, falls einem das (noch) Fremdworte sind.<br>
batman-adv
 
</pre>
 
  
 +
==== Private FFF IPs ====
 +
Für jede Hood reserviert man sich einen [[Portal:Netz|IPv4]] bzw. [[Portal:Netz/IPv6|IPv6]] Adressbereich, mit welchem die Knoten und Clients versorgt werden.
  
B.A.T.M.A.N. Advanced wird mit dem Tool batctl gesteuert. Das muss entsprechend installiert werden. Hier kann ebenfalls die Version aus den Debian Paketquellen oder die selbstkompilierte verwendet 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.
  
<code>
+
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.
apt install batctl
 
</code>
 
  
<br>
+
Bei IPv6 wird nur Gateway, DNS-Server und Subnetz per Router Advertisement in der Hood bekannt gemacht, den Rest erledigen die Clients.
  
== FastD ==
+
==== Peering-IPs ====
Die Verbindung zwischen Gateway und zentralen Routern wird über einen fastd-Tunnel realisiert.
+
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>
 +
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>
  
Die fastd-Version aus den Stretch Paketquellen ist aktuell und kann (und sollte) verwendet werden.
+
Bei IPv6 genügen die Link-Local Adressen.
  
<code>
+
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.
apt install fastd
 
</code>
 
  
== l2tp Tunneldigger ==
+
==== Öffentliche Adressen ====
 +
Damit das Internet erreicht werden kann, sind öffentliche IP Adressen nötig, die im Internet bekannt sind.
  
Die Verbindung zwischen Gateway und zentralen Routern kann auch über einen l2tp Tunnel hergestellt werden.
+
Diese können von verschiedenen Freifunkern bezogen werden, siehe [[IPv6]]
  
Installation und Konfiguration des Tunneldigger-Brokers: [[L2TP und Tunneldigger]]
+
=== OS Settings ===
 +
==== IP-Forwarding ====
 +
Per default leitet Debian keine Pakete weiter, die unser Gateway erreichen. Deswegen muss IP-Forwarding aktiviert werden. :
  
== Babel ==
+
Manuell (nur bis zum reboot aktiv):
Innerhalb von Freifunk Franken wird Babel als IP-Routingprotokoll verwendet. Damit sind alle Gateways und damit alle Hoods miteinander verbunden.
 
Das ist für hoodübergreifenden Traffic, DNS-Verkehr, wenn kein eigener bzw. nur ein Stub eingerichtet wird, für Verbindungen ins IC-VPN etc. wichtig.
 
 
 
Für Linux kann babeld aus den Stretch Paketquellen als Daemon für Babel verwendet werden.
 
<code>
 
apt install babeld
 
</code>
 
 
 
Auch hier gilt wieder: Die Version aus den Debian Paketquellen ist nicht super aktuell, in babeld-1.8.0 gab es einige Änderungen.<br>
 
Auch babeld kann selbst kompiliert werden. Sourcen gibts [https://github.com/jech/babeld hier]
 
 
 
babeld importiert und exportiert alle Routen in/aus einer Routingtabelle. Es bietet sich an, für fff eine neue Tabelle anzulegen und zu benennen. Dazu Tabellennummer und Name in /etc/iproute2/rt_tables eintragen:
 
 
<pre>
 
<pre>
10 fff
 
</pre>
 
 
== Tunnel für den Backbone ==
 
TODO
 
 
 
 
= Grundinstallation des Servers =
 
Die Installation des Betriebssystems, Absicherung des Servers, Installieren von Updates usw. sind '''NICHT''' Gegenstand dieser Anleitung. Trotzdem kurz einige Hinweise.
 
 
=== Folgendes sollte unbedingt beachtet werden ===
 
* Betriebssystem aktuell halten. Bei Linux wird dafür für gewöhnlich eine Paketverwaltung verwendet
 
** Bei Debian ist das apt
 
** ''apt update'' aktualisiert die Paketquellen
 
** ''apt upgrade'' aktualisiert die Pakete
 
* 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]
 
** root-Login per SSH höchstens per Key, besser abschalten
 
** Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für weitere Hinweise.
 
 
=== IP-Forwarding ===
 
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden.
 
 
Manuell geht dies über:
 
<code>
 
 
echo "1" > /proc/sys/net/ipv4/ip_forward
 
echo "1" > /proc/sys/net/ipv4/ip_forward
  
 
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding
 
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding
 
 
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
 
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
 +
</pre>
  
# Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y...
 
# https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
 
echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr
 
</code>
 
  
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:
+
sysctl Einstellungen können in der Datei '''/etc/sysctl.conf''' dauerhaft eingestellt werden.
<code>
 
vi /etc/sysctl.conf
 
</code>
 
  
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:
+
Dort gibt es für das Forwarding bereits die passenden Zeilen, die nur einkommentiert werden müssen:
 
<pre>
 
<pre>
.
+
 
.
 
.
 
 
# Uncomment the next line to enable packet forwarding for IPv4
 
# Uncomment the next line to enable packet forwarding for IPv4
 
net.ipv4.ip_forward=1
 
net.ipv4.ip_forward=1
Zeile 254: Zeile 156:
 
#  based on Router Advertisements for this host
 
#  based on Router Advertisements for this host
 
net.ipv6.conf.all.forwarding=1
 
net.ipv6.conf.all.forwarding=1
.
+
 
.
 
.
 
 
</pre>
 
</pre>
<br>
 
  
Um ICMP-Fehlerpakete auf eth0 zu vermeiden, die als src-IP 10.50.x.y haben (böseböse!) dann noch
+
==== 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:
 
<pre>
 
<pre>
# Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y...
 
# https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
 
 
net.ipv4.icmp_errors_use_inbound_ifaddr = 1
 
net.ipv4.icmp_errors_use_inbound_ifaddr = 1
 
</pre>
 
</pre>
  
einfügen
+
Außerdem landen dann keine ICMP Pakete mit internen Adressen als Absender auf dem Uplink [dem Hoster].
 
 
= Konfigurieren des Freifunk-Gateways =
 
Nachdem nun die erforderlichen Softwarepakete auf dem Gateway installiert wurden, kann man das Gateway als solches einrichten. 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. 
 
<br>
 
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==
 
Das Gateway benötigt eine IP aus jedem verbundenen Layer-2 Netz.
 
 
 
Für jede Hoods sucht man sich dafür unter [[Portal:Netz]] bzw. [[Portal:Netz/IPv6]] eine IPv4 bzw. IPv6 Adresse (bei IPv4 aus dem statischen Bereich) der Hood aus.<br>
 
Damit es keine Doppelbelegungen gibt, muss diese auch gleich "'''reserviert'''" werden, indem das Wiki entsprechend editiert wird.
 
  
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>
+
Siehe auch [[MTU]]
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.<br>
 
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 [[Portal:Netz/IPv6#Transfer-IPs|Bereich]] dafür vorgesehen) gut verwendet werden.
+
==== Routing Tabelle für Freifunk ====
 +
Für die Routen im Freifunk Franken Netz muss eine eigene Routingtabelle angelegt 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>
+
Damit die Tabelle auch mit Name aufrufbar ist, sollten Tabellennummer und Name in /etc/iproute2/rt_tables eingetragen werden:
Ein entsprechender IP-Rechner findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].
 
 
 
 
 
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.
 
 
 
== Routing Tabelle für Freifunk ==
 
Für die Routen im Freifunk Franken Netz sollte eine eigene Routingtabelle deklariert werden.
 
 
 
Dazu Tabellennummer und Name in /etc/iproute2/rt_tables eintragen:
 
  
 
<pre>
 
<pre>
Zeile 308: Zeile 181:
  
 
Der Inhalt der Routingtabelle kann später mit
 
Der Inhalt der Routingtabelle kann später mit
<code>
+
<pre>
 
ip route show table fff
 
ip route show table fff
</code>
+
bzw.
 +
ip -6 route show tab fff
 +
</pre>
 
angezeigt werden.
 
angezeigt werden.
 
<br>
 
<br>
  
== fastd ==
+
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.   
 
 
fastd wird komplett anders als früher konfiguriert.
 
Das früher nötige Verwaltungsscript darf '''KEINESFALLS(!!)''' ausgeführt werden, auch der Cronjob ist nicht mehr nötig. Falls die IP noch im alten KeyXchange eingetragen ist, sollte sie hieraus unbedingt entfernt werden (KeyXchange Admin fragen) Bitte nur noch folgende Anleitung folgen:
 
 
 
/etc/fastd/ffffuerthVPN/fastd.conf
 
<pre>
 
# Log errors to stderr
 
log level error;
 
 
 
# Log warnings to a log file
 
log to syslog as "ffffuerthVPN" level warn;
 
 
 
# Set the interface name
 
interface "ffffuerthVPN";
 
 
 
# Disable encryption
 
method "null";
 
 
 
# Bind to a fixed port, IPv4 only
 
bind any:10004;
 
 
 
# fastd need a key but we don't use them: generate by "fastd --generate-key"
 
secret "c00a286249ef5dc5506945f8a3b413c0928850214661aab866715203b4f2e86a";
 
 
 
# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)
 
# (see MTU selection documentation)
 
mtu 1426;
 
 
 
on up "/etc/fastd/up.sh";
 
on down "/etc/fastd/down.sh";
 
 
 
secure handshakes no;
 
 
 
on verify "/etc/fastd/verify.sh";
 
</pre>
 
 
 
 
 
/etc/fastd/down.sh
 
<pre>
 
#!/bin/sh
 
/sbin/ifdown $INTERFACE
 
</pre>
 
 
 
 
 
/etc/fastd/up.sh
 
<pre>
 
#!/bin/sh
 
/sbin/ifup $INTERFACE
 
</pre>
 
 
 
 
 
/etc/fastd/verify.sh
 
<pre>
 
#!/bin/sh
 
return 0
 
</pre>
 
 
 
 
 
danach:
 
 
 
Scripte ausführbar machen:
 
<pre>
 
chmod +x /etc/fastd/*.sh
 
</pre>
 
Dienst aktivieren und starten
 
<pre>
 
systemctl enable fastd
 
systemctl start fastd
 
</pre>
 
 
 
 
 
=== Gateways untereinander verbinden ===
 
Die Gateways sollten sich im Hood-Layer2 auch noch untereinander verbinden, das ist aktuell noch nicht umgesetzt.
 
''Eventuell ist dies doch nicht nötig''
 
 
 
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==
 
<del>'''Hinweis:''' Wenn man für einige nette Dinge um das B.A.T.M.A.N Netzwerk-Interface eine Bridge haben möchte gibt es unter [[Freifunk-Gateway aufsetzen/Batman bridge]] eine entsprechende Anleitung.</del>
 
 
 
In der Datei /etc/network/interfaces ...
 
 
 
<code>
 
vi /etc/network/interfaces
 
</code>
 
 
 
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:
 
 
 
<pre>
 
.
 
.
 
.
 
# device: bat0
 
iface bat0 inet manual
 
    post-up ip link set dev $IFACE up
 
    ##Einschalten post-up:
 
    # IP des Gateways am B.A.T.M.A.N interface:
 
    post-up ip addr add 10.50.32.5/21 dev $IFACE
 
    # Regeln, wann die fff Routing-Tabelle benutzt werden soll:
 
    post-up ip rule add iif $IFACE table fff
 
    post-up ip rule add from 10.0.0.0/8 table fff
 
    post-up ip rule add to 10.0.0.0/8  table fff
 
    # Route in die Fuerther Hood:
 
    post-up ip route replace 10.50.32.0/21 dev $IFACE proto static table fff
 
    # Start des DHCP Servers:
 
    post-up invoke-rc.d isc-dhcp-server restart
 
 
 
    ##Ausschalten post-down:
 
    # Loeschen von oben definieren Routen, Regeln und Interface:
 
    post-down ip route del 10.50.32.0/21 dev $IFACE table fff
 
    post-down ip rule del from 10.0.0.0/8 table fff
 
    post-down ip rule del to 10.0.0.0/8 table fff
 
    post-down ip rule del iif $IFACE table fff
 
    post-down ip link set dev $IFACE down
 
 
 
iface bat0 inet6 static
 
    address fd43:5602:29bd:x::1/64
 
 
 
    # zusätzliche Link Local für Hoodfile und Default-Gateway
 
    post-up ip -6 addr add fe80::1/64 dev $IFACE nodad
 
    post-up ip -6 addr add fe80::IRGENDWAS/64 dev $IFACE
 
 
 
    post-up ip -6 rule add iif $IFACE table fff
 
    post-down ip -6 rule del iif $IFACE table fff
 
 
 
    # "catchall"
 
    post-up ip -6 rule add from all iif $IFACE lookup fff
 
 
 
    # ip route   
 
    post-up ip -6 route replace fd43:5602:29bd:x::/64 dev $IFACE proto static table fff
 
    post-down ip -6 route del fd43:5602:29bd:x::/64 dev $IFACE proto static table fff
 
    post-up invoke-rc.d radvd restart
 
 
 
 
 
# VPN Verbindung in die Fuerther Hood
 
iface ffffuerthVPN inet manual
 
    post-up batctl -m bat0 if add $IFACE
 
    post-up ifconfig $IFACE up
 
    post-up ifup bat0
 
    post-down ifdown bat0
 
    post-down ifconfig $IFACE down
 
</pre>
 
 
 
In diesem Beispiel sind:
 
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21
 
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.
 
Diese müssen gegen die oben reservierte IP/Netzmaske des Gateways der Hood und gegen die Netzwerk-IP/Netzmaske der Hood, in die das neue Gateway soll, ausgetauscht werden.
 
 
 
Der Eintrag "ip route add 10.50.32.0/21 dev $IFACE table fff" fügt in der fff Routingtabelle eine Route in das Netzwerk "Fürther Hood" ein. Für Hassberge müsste dieser Eintrag z.B. in 10.50.56.0/22 geändert und für die IP-Adresse des Gateways eine aus dem statischen Bereich der Hassberger Hood reserviert und verwendet werden (s.o.).
 
 
 
Die Regeln definieren, das Traffic der
 
* aus dem Netzwerk 10.0.0.0/8 kommt
 
* das Netzwerk 10.0.0.0/8 zum Ziel hat
 
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird
 
von der fff Routingtabelle behandelt wird. Die Einträge sind so allgemein formuliert, dass sie für das gesamte Freifunk Franken Netz Gültigkeit haben sollten.
 
 
 
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.
 
 
 
<i>Hinweis:</i> Die MTU darf nicht verstellt (vergrößert) werden, diesbezügliche Laufzeitmeldungen von batman_adv bitte ignorieren!
 
<br>
 
 
 
Beim loopback device bitte noch
 
<pre>
 
iface lo inet loopback
 
up ip rule add to 10.0.0.0/8 lookup fff
 
 
 
up ip -6 rule add to fc00::/7 lookup fff
 
 
 
## Möglicherweise möchte man die gleichen rules auch nochmal als Destination-rules (from statt to) anfügen.
 
 
 
eintragen, damit der Gateway weiß, dass die Freifunk-IPs durch die fff Routingtabelle durchgehen
 
</pre>
 
 
 
== Testen von B.A.T.M.A.N, fastd und Autostart ==
 
<del>Hierfür booten wir das Gateway am besten erst mal neu:
 
<code>
 
reboot & exit
 
</code>
 
<del>
 
und starten das fast.d Startskript manuell:
 
<code></del>
 
/etc/fastd/fff_beispiel_fastd.sh &
 
</code></del>
 
<del>
 
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.</del>
 
 
 
Danach sollte der Aufruf von...
 
<code>
 
pgrep fastd
 
</code>
 
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.
 
 
 
 
 
Ein Aufruf von ifconfig:
 
<code>
 
ifconfig
 
</code>
 
 
 
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.
 
Exemplarisch und als Auszug:
 
<pre>
 
bat0      Link encap:Ethernet  HWaddr ea:95:50:07:f7:27 
 
          inet addr:10.50.32.5  Bcast:0.0.0.0  Mask:255.255.248.0
 
          inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link
 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
          RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0
 
          TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0
 
          collisions:0 txqueuelen:0
 
          RX bytes:141311612 (134.7 MiB)  TX bytes:1052934594 (1004.1 MiB)
 
 
 
.
 
.
 
.
 
ffffuerthVPN Link encap:Ethernet  HWaddr e6:3b:f3:b7:fc:db 
 
          inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link
 
          UP BROADCAST RUNNING MULTICAST  MTU:1426  Metric:1
 
          RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0
 
          TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0
 
          collisions:0 txqueuelen:500
 
          RX bytes:4193328694 (3.9 GiB)  TX bytes:1384843740 (1.2 GiB)
 
.
 
.
 
.
 
</pre>
 
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen. + IPv6
 
 
 
 
 
Die Abfrage der IP-Regeln:
 
<code>
 
ip rule
 
</code>
 
 
 
sollte die oben definierten Regeln wieder spiegeln (fff Tabelle für Traffic, der entweder über bat0 oder 10.0.0.0/8 rein- oder rausgeht):
 
<pre>
 
32757: from all to 10.0.0.0/8 lookup fff
 
32758: from 10.0.0.0/8 lookup fff
 
32759: from all iif bat0 lookup fff
 
</pre>
 
 
 
Eine Abfrage der fff-Routing Tabelle
 
<code>
 
ip route show table fff
 
</code>
 
 
 
sollte die B.A.T.M.A.N Route (Device bat0) in das Netzwerk der eingerichtete Hood ergeben. In diesem Beispiel ist es die Fürther Hood:
 
<pre>
 
10.50.32.0/21 dev bat0  scope link
 
</pre>
 
 
 
''ganze IPv6 Zeug fehlt noch''
 
 
 
Ein Aufruf von "batctl o"
 
<code>
 
batctl o
 
</code>
 
 
 
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:
 
<pre>
 
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]
 
  Originator      last-seen (#/255)          Nexthop [outgoingIF]:  Potential nexthops ...
 
96:43:c4:2e:73:68    0.004s  (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)
 
.
 
.
 
.
 
</pre>
 
''Auf neues Batman updaten (Versionsanzeiger)''
 
 
 
<del>Hat soweit alles geklappt, kann das Startscript /etc/fastd/fff_beispiel_fastd.sh bei jedem Systemstart ausgeführt werden, indem es z.B. in /etc/rc.local eingetragen wird:
 
<code>
 
vi /etc/rc.local
 
</code></del>
 
<del>
 
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:
 
<pre>
 
# launch fastd with 10 seconds delay
 
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &
 
</pre></del>
 
<del>
 
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:
 
<code>
 
crontab -e
 
</code></del>
 
<del>
 
Nun folgendes eingeben:
 
<pre>
 
*/5 * * * * sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh
 
</pre></del>
 
<del>
 
und
 
<del>
 
<code>
 
/etc/init.d/cron restart
 
</code>
 
<br></del>
 
 
 
== radvd ==
 
 
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/radvd
 
 
 
== ntp Server ==
 
 
 
Es werden routbare v6 Adressen aus den ULA Bereich verwendet. Jede Hood kann, muss aber nicht einen eigenen ntp Server bereit stellen. Aktuell sind folgende NTP Server in Betrieb und können verwendet werden:
 
* fd43:5602:29bd:ffff::1
 
* fd43:5602:29bd:7d::2
 
* fd43:5602:29bd:ffff::42
 
 
 
== http Server für Hoodfile ==
 
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/http
 
 
 
== Alfred Master aufsetzen ==
 
Die Nodewatcher Daten aus dem Alfred werden nicht mehr von einer zentralen VM ans Monitoring geschickt. Das übernehmen jetzt die Gateways.
 
 
 
==== Alfred ====
 
Das Gateway muss die Daten zuerst als sogenannter Alfred-Master sammeln. Dazu muss "alfred" installiert werden. (Entweder aus den Distributionsquellen oder selbst kompilieren, funktioniert analog zum batman-adv (siehe oben))
 
 
 
Dann muss pro bedienter Hood (also für jedes batX Interface) ein Alfred master gestartet werden (beispielsweise mit in die Interfacekonfiguration oder wie unten als systemd-Service ...):
 
<pre>
 
~# cat /etc/systemd/system/alfred-bayreuth.service
 
[Unit]
 
Description=Alfred Master
 
After=network-online.target
 
 
 
[Service]
 
Type=simple
 
ExecStart=/usr/sbin/alfred -m -i br-bayreuth -b bat2 -u /var/run/alfred-bayreuth.sock
 
WorkingDirectory=/tmp
 
RestartSec=10
 
Restart=always
 
 
 
[Install]
 
WantedBy=multi-user.target
 
</pre>
 
 
 
bitte die Parameter -i und -b entsprechend anpassen
 
 
 
<pre>
 
  -i, --interface                    specify the interface (or comma separated list of interfaces) to listen on
 
  -b                                  specify the batman-adv interface
 
                                      configured on the system (default: bat0)
 
                                      use 'none' to disable the batman-adv
 
                                      based best server selection
 
</pre>
 
Hinweis: Wenn in der eigenen Konfiguration keine separate Bridge verwendet wird, muss beim Parameter -i das bat-Interface angegeben werden; also bei -i und -b das selbe Interface.
 
 
 
==== Alfred Monitoring Proxy ====
 
Die gesammelten Daten müssen nun noch periodisch an das Monitoring gesendet werden.
 
 
 
Dazu kann alfred-json von kratz00 (https://github.com/kratz00/alfred-json) in Kombination mit einem passenden curl-Skript verwenden werden. Zunächst muss alfred-json kompiliert werden (siehe README).
 
 
 
Danach noch das curl-Script anlegen (auf eigenes Zeug anpassen! Pfade der inneren for-loop über die Sockets prüfen!):
 
 
 
<pre>
 
~# cat /usr/local/sbin/alfred-monitoring-proxy
 
</pre>
 
<pre>
 
#!/bin/bash
 
 
 
api_url="https://monitoring.freifunk-franken.de/api/alfred"
 
fetch_ids="64"
 
 
 
for fetch_id in $fetch_ids
 
do
 
for socket in /var/run/alfred-*.sock
 
do
 
tmp=$(mktemp)
 
 
 
echo "{\"$fetch_id\": " > $tmp
 
/usr/local/bin/alfred-json -r "$fetch_id" -s "$socket" >> $tmp
 
echo "}" >> $tmp
 
 
 
if [ "$zip" = "1" ]; then
 
gzip $tmp
 
tmp="$tmp.gz"
 
HEADER='-H "Content-Encoding: gzip" --compressed'
 
fi
 
 
 
curl -v -H "Content-type: application/json; charset=UTF-8" $HEADER --data-binary @$tmp $api_url
 
 
 
rm "$tmp"
 
done
 
done
 
</pre>
 
 
 
 
 
Und einen passenden Cronjob dafür anlegen:
 
<pre>
 
1-59/5 * * * *  sleep 9; /usr/local/sbin/alfred-monitoring-proxy
 
</pre>
 
 
 
'''WICHTIG:''' Bitte im nächsten Abschnitt den optimalen Zeitpunkt für das senden bestimmen!
 
 
 
==== Wahl des korrekten Delays (sleep) ====
 
 
 
Das Zusammenspiel zwischen nodewatcher, Alfred und Monitoring ist komplex. Entsprechend gibt es mehr und weniger sinnvolle Zeiten, wann der Alfred Master seine Daten an das Monitoring sendet. Die folgende Tabelle soll bei der Wahl eines geeigneten Delays behilflich sein.
 
 
 
Anstatt eines fixen Delays ist auch eine Variante mit random möglich. Die Grenzen sollten dabei die angegebenen Bereiche nicht verlassen!
 
 
 
WICHTIG: '''Sind mehrere Alfred Master in einer Hood sollten diese ihre Daten nie gleichzeitig schicken! (Empfohlener Abstand min. 5 sec.)'''
 
 
 
 
 
{|
 
! !! Wartezeit nach Erreichen von */5 !! Kommentar
 
|-
 
| || style="color:#ff0000;text-align:center" | '''0 - 50 sec.'''
 
|| '''Reservierter Zeitslot (nodewatcher)'''
 
* In dieser Zeit generiert der nodewatcher die Daten und verschickt diese per Alfred.
 
* Findet die Anfrage in diesem Zeitraum statt, werden die Daten von 5 Minuten zuvor verwendet.
 
|-
 
| || style="color:#00b259;text-align:center" | '''50 - 85 sec.'''
 
|| '''Empfohlener Zeitslot'''
 
* Optimal zwischen 65 und 80 sec.
 
|-
 
| ||  style="color:#ff0000;text-align:center" | '''85 - 120 sec.'''
 
|| '''Reservierter Zeitslot (Netmon-VM)'''
 
* Bei einer anderen Anfrage sollten keine Fehler auftreten, aber die Last wird unnötig erhöht
 
|-
 
| || style="color:#ffbf00;text-align:center" | '''120 - 175 sec.'''
 
|| '''Möglicher Zeitslot'''
 
* Die Daten werden noch rechtzeitig für die Statistiken geliefert
 
* Die Routerdaten selbst sind weniger aktuell im Vergleich zum empfohlenen Slot
 
|-
 
| || style="color:#ff0000;text-align:center" | '''175 - 185 sec.'''
 
|| '''Reservierter Zeitslot (Erstellung der Statistiken)'''
 
* Findet hier eine Anfrage statt kann es gelegentlich zu Fehlern kommen
 
|-
 
| || style="color:#ffbf00;text-align:center" | '''185 - 300 sec.'''
 
|| '''Freier Zeitslot'''
 
* Die Daten werden NACH Erstellung der Statistiken geliefert und müssen entsprechend lange warten
 
*'''''Optimal ist dieser Zeitslot für den zweiten Alfred Master einer Hood, sodass der Abstand zwischen den Anfragen etwa gleich ist (=> effektives Update alle 2.5 Minuten)'''''
 
* Ein Setzen auf nahe 300 Sekunden sollte vermieden werden
 
|}
 
 
 
'''Tipps:'''
 
 
 
Handelt es sich um mehr als eine Minute Delay, kann die Cron Syntax ausgenutzt werden:
 
 
 
<pre>
 
1-59/5 * * * * Befehl
 
</pre>
 
 
 
 
 
Das löst dann 00:01, 00:06, 00:11 usw. aus, also im beginnend bei 1 bis 59 in 5-er Schritten
 
 
 
<pre>
 
2-59/5 * * * * Befehl
 
</pre>
 
 
 
 
 
Das löst dann 00:02, 00:07, 00:12 usw. aus, also im beginnend bei 2 bis 59 in 5-er Schritten.
 
In Kombination mit sleep gibt es also für 130 Sekunden folgende Lösungen:
 
 
 
<pre>
 
*/5 * * * * sleep 130; Befehl
 
</pre>
 
 
 
 
 
oder besser:
 
 
 
<pre>
 
2-59/5 * * * * sleep 10; Befehl
 
</pre>
 
 
 
Zwei Minuten plus 10 Sekunden sind 130 Sekunden, aber man vermeidet den langen Sleep.
 
 
 
== OpenVPN-Tunnel einrichten ==
 
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren.
 
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.
 
<br>
 
=== Mullvad ===
 
 
 
Unter https://mullvad.net/download/config/  Reiter "Other platforms" kann man sich die mullvadconfig_xx.zip runterladen.
 
 
 
Mullvad liefert in dieser Datei, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.
 
 
 
Man kopiert nun die zip-Datei auf das Gateway, entpackt sié und kopiert das Kundenummern-Verzeichnis mit dem Dateien ca.crt, crl.pem, mullvad.crt, mullvad.key, mullvad_linux.conf nach /etc/openvpn:
 
 
 
Von dem lokalen Rechner kopieren wir die zip Datei per scp für [http://ged.msu.edu/angus/tutorials/using-putty-on-windows.html Windows] oder [http://www.hypexr.org/linux_scp_help.php Linux] auf das Gateway.
 
 
 
Als unverbindliche Richtschnur für Linux:
 
<code>
 
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root
 
</code>
 
 
 
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):
 
<code>
 
ssh root@<ipv4 des Gateways>
 
 
 
unzip mullvadconfig.zip
 
 
 
cd <Kundennummernverzeichnis>
 
 
 
cp * /etc/openvpn
 
</code>
 
 
 
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:
 
<pre>
 
ca.crt crl.pem  mullvad.crt  mullvad.key  mullvad_linux.conf  mullvad_windows.conf.ovpn  update-resolv-conf
 
</pre>
 
 
 
'''Wichtiger Hinweis''': Wer sich nicht von seinem Gateway aussperren möchte, sollte so lange den Rechner nicht neu starten, wie die openvpn Konfiguration nicht wie unten angepasst wurde. Wenn es doch passiert, ist evtl. noch ein Zugriff auf das Gateway über die hoster-Konsole möglich.
 
 
 
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:
 
<code>
 
vi /etc/openvpn/mullvad-up
 
</code>
 
 
 
und füllen sie mit folgendem Inhalt:
 
<pre>
 
#!/bin/bash
 
logger -t OPENVPN VPN Gateway: /sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
 
/sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
 
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE
 
</pre>
 
Das Skript definiert in der fff-Routingtabelle zunächst den VPN Anbieter als Standard-Gateway ("/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff"). D.h. Traffic, der über das Freifunk-Netz hereinkommt (Definiert über die fff IP rules) und für den keine anderweitigen Routinginformationen bekannt sind (z.B. Internet Traffic), wird pauschal in Richtung des VPN Gateways geschickt (IP ${route_vpn_gateway}, Device ${dev}). Das Default-Gateway für Traffic, der nicht freifunkbezogen ist, bleibt unangetastet, um sich nicht selber auszusperren.
 
Da wir Anfragen vieler Clients (verschiedene IPs) über eine VPN IP schieben, müssen wir darüber hinaus "Network Adress Translation" (NAT) betreiben ("iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE"). Dies ist auch erforderlich, da der Freifunk IPv4 Adressbereich 10.0.0.0/8 für lokale Netze reserviert ist und nicht im Internet geroutet wird.
 
 
 
Das Skript mullvad-up muss ferner ausführbar sein:
 
<code>
 
chmod +x /etc/openvpn/mullvad-up
 
</code>
 
 
 
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:
 
<code>
 
vi /etc/openvpn/mullvad_linux.conf
 
</code>
 
 
 
und hier die Konfiguration entsprechend geändert werden:
 
<pre>
 
.
 
.
 
.
 
# Allow calling of built-in executables and user-defined scripts.
 
script-security 2
 
 
 
# Parses DHCP options from openvpn to update resolv.conf
 
#up /etc/openvpn/update-resolv-conf
 
#down /etc/openvpn/update-resolv-conf
 
 
 
# Enable Freifunk specific Routing
 
route-noexec
 
route-delay 3
 
route-up    /etc/openvpn/mullvad-up
 
.
 
.
 
.
 
</pre>
 
Script security muss auf "2" stehen, damit benutzerspezifische Skripte ausgeführt werden dürfen. Unser Freifunk spezifisches Routing wird über "route-up /etc/openvpn/mullvad-up" ausgeführt, wobei wir vorher openvpn mit "route-noexec" verbieten, automatisch selber Routen anzulegen. Aus Sicherheitsgründen führen wir einen kleinen Zeitpuffer von 3 Sekunden ein ("route-delay 3"). Vorhandene Start/Stop-Skripte (up/down) sollten auskommentiert werden.
 
 
 
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).
 
 
 
Der openvpn Tunnel kann nun testweise gestartet werden:
 
<code>
 
cd /etc/openvpn
 
 
 
/usr/sbin/openvpn mullvad_linux.conf  &
 
</code>
 
 
 
und sollte exemplarisch und im Auszug folgendes zurück liefern:
 
<pre>
 
Sun Sep  6 12:45:20 2015 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
 
Sun Sep  6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
 
Sun Sep  6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
 
.
 
.
 
.
 
Sun Sep  6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500
 
Sun Sep  6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255
 
Sun Sep  6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0
 
Sun Sep  6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init
 
Sun Sep  6 12:45:23 2015 Initialization Sequence Completed
 
</pre>
 
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.
 
 
 
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:
 
<code>
 
ip route show table fff | grep default
 
</code>
 
 
 
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:
 
<pre>
 
default via 10.114.0.1 dev tun0
 
</pre>
 
 
 
Auch ein ifconfig Eintrag für das Tunnel Device...
 
<code>
 
ifconfig
 
</code>
 
 
 
...sollte jetzt existieren (Exemplarisch und im Auszug):
 
<pre>
 
.
 
.
 
.
 
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
 
          inet addr:10.114.0.76  P-t-P:10.114.0.76  Mask:255.255.0.0
 
          inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global
 
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
 
          RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0
 
          TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0
 
          collisions:0 txqueuelen:100
 
          RX bytes:1250196616 (1.1 GiB)  TX bytes:84979294 (81.0 MiB)
 
.
 
.
 
.
 
</pre>
 
 
 
 
 
Wenn alles geklappt hat, kann man (sofern openvpn nicht korrekt beim Systemstart geladen wird), den openvpn Tunnel in der /etc/rc.local bei jedem Systemstart laden:
 
<code>
 
vi /etc/rc.local
 
</code>
 
 
 
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:
 
<pre>
 
# launch vpn with 5 seconds delay
 
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &
 
</pre>
 
 
<br>
 
<br>
  
=== NordVPN ===
+
== Layer 3 ==
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.
+
=== Generelle Layer 3 Routing Regeln ===
 
+
Damit Pakete vom Gateway selbst passend in das Freifunk Netz geroutet werden, sind einige Regeln nötig.
'''Hinweis:''' Auch hier gilt - Wer sich nicht ungewollt von seinem Gateway aussperren möchte, muss vor dem Starten von OpenVPN und vor einem neuen Reboot die Konfigurationsdatei anpassen.
 
 
 
Von dem lokalen Rechner kopieren wir die zip Datei per scp für [http://ged.msu.edu/angus/tutorials/using-putty-on-windows.html Windows] oder [http://www.hypexr.org/linux_scp_help.php Linux] auf das Gateway.
 
 
 
Als unverbindliche Richtschnur für Linux:
 
<code>
 
scp config.zip root@<ipv4 des Gateways>:/root
 
</code>
 
 
 
Und entpacken diese auf dem Gateway:
 
<code>
 
cd ~
 
 
 
mkdir nordvpn-configs
 
 
 
mv config.zip nordvpn-configs
 
 
 
cd nordvpn-configs
 
 
 
unzip config.zip
 
</code>
 
 
 
Danach wählen wir einen VPN Server aus, z.B. unter dem Gesichtspunkt das er wenige Hops vom Gateway entfernt ist und/oder in einem Land unserer Wahl steht.
 
 
 
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):
 
 
 
<code>
 
vi se1.nordvpn.com.udp1194.ovpn
 
</code>
 
 
 
Änhlich wie bei Mullvad, bestimmen wir dass wir das Routing mit einem eigenen Skript festlegen wollen (/etc/openvpn/nordvpn-up) und openvpn die Route nicht selber definieren soll. Zusätzlich geben wir eine Datei an, in die wir später Password und Benutzername des NordVPN Zugangs (/etc/openvpn/nordvpn-pw) ablegen:
 
<pre>
 
.
 
.
 
.
 
# Provide Username and Password
 
auth-user-pass /etc/openvpn/nordvpn-pw
 
.
 
.
 
.
 
# Allow calling of built-in executables and user-defined scripts.
 
script-security 2
 
 
 
# Enable Freifunk specific Routing
 
route-noexec
 
route-delay 3
 
route-up    /etc/openvpn/nordvpn-up
 
.
 
.
 
.
 
</pre>
 
 
 
Die angepasste Datei (im Beispiel  se1.nordvpn.com.udp1194.ovpn) kopieren wir nach /etc/openvpn und spendieren Ihr gleichzeitig die Endung .conf, damit der Autostart Mechanismus die Konfigurationsdatei als solche erkennt:
 
<code>
 
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf
 
</code>
 
 
 
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:
 
<code>
 
touch /etc/openvpn/nordvpn-up
 
 
 
touch /etc/openvpn/nordvpn-pw
 
 
 
chmod +x /etc/openvpn/nordvpn-up
 
</code>
 
  
Man öffnet nordvpn-up...
+
Diese können an die Debian Interfacekonfiguration des Loopback Interfaces hinzugefügt werden, damit sind sie direkt nach dem Boot des Servers verfügbar.
<code>
 
vi /etc/openvpn/nordvpn-up
 
</code>
 
  
und füllt die Datei mit identischem Inhalt wie mullvad-up. Bei Interesse stehen weitere Hinweise bei mullvad (Network Adress Translation, Default Gateway für Freifunk Traffic):
+
'''prio''' legt fest, in welcher Reihenfolge die Regeln abgearbeitet werden.
<pre>
+
Hier sollte sich zunächst an die im Wiki vorgegebene Reihenfolge gehalten werden, später kann man diese auf die eigenen Bedürfnisse anpassen.
#!/bin/bash
 
logger -t OPENVPN VPN Gateway: /sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
 
/sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
 
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE
 
</pre>
 
  
Nun öffnet man nordvpn-pw:
+
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.
<code>
 
vi /etc/openvpn/nordvpn-pw
 
</code>
 
  
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:
 
 
<pre>
 
<pre>
(Username bei NordVPN)
+
iface lo inet static
(Password bei NordVPN)
+
address 10.83.252.x/32
</pre>
 
  
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)
+
up ip -4 rule add to 10.0.0.0/8 prio 500 lookup fff
<code>
+
down ip -4 rule del to 10.0.0.0/8 prio 500 lookup fff
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &
 
</code>
 
  
Und sollte aufgebaut werden:
+
        #DN42
<pre>
+
up ip -4 rule add to 172.20.0.0/14 prio 500 lookup fff
Sun Sep 27 09:07:13 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec  1 2014
+
down ip -4 rule del to 172.20.0.0/14 prio 500 lookup fff
.
 
.
 
.
 
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500
 
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225
 
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed
 
</pre>
 
  
Wenn alles geklappt hat, kann man (sofern openvpn nicht korrekt beim Systemstart geladen wird), den openvpn Tunnel in der /etc/rc.local bei jedem Systemstart laden:
+
iface lo inet6 static
<code>
+
address fd43:5602:29bd:ffff::xx/128
vi /etc/rc.local
 
</code>
 
  
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:
+
up ip -6 rule add to fc00::/7 prio 500 lookup fff
<pre>
+
down ip -6 rule del to fc00::/7 prio 500 lookup fff
# launch vpn with 5 seconds delay
 
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &
 
 
</pre>
 
</pre>
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.
 
<br>
 
 
== DNS Server ==
 
In der einfachsten Konfiguration betreiben wir den DNS Server als Caching Nameserver, d.h. alle Anfragen Domainnames in IP Adressen zu wandeln, die schon mal durch den Server gelaufen sind, werden selber beantwortet. Ansonsten wird ein anderer DNS-Server aus dem Freifunk-Netz oder dem Internet angefragt.
 
 
----
 
 
'''ACHTUNG! Freifunk Franken hat nun sein eigenes DNS System. Damit dies von überall funktioniert bitte [https://wiki.freifunk-franken.de/w/DNS#Funktionsf.C3.A4higkeit_auf_allen_GWs diese Seite] beachten.'''
 
  
----
+
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.
  
Hierfür editieren wir die Datei named.conf.options...
 
<code>
 
vi /etc/bind/named.conf.options
 
</code>
 
 
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:
 
 
<pre>
 
<pre>
.
+
[...]
.
+
up ip -6 rule add iif $IFACE prio 10 table fff
.
+
up ip rule add iif $IFACE prio 10 table fff
forwarders  {
+
[...]
              10.83.252.11;
 
              10.50.252.0;
 
            };
 
allow-query {
 
              127.0.0.1/8;
 
              10.0.0.0/8;
 
            };
 
.
 
.
 
.
 
 
</pre>
 
</pre>
Darüber hinaus ist es sinnvoll, nur Anfragen zu beantworten, die das Gateway selber stellt (localhost; 127.0.0.1/8) oder die aus dem Freifunk Netz kommen (10.0.0.0/8). Der zugehörige Parameter heißt "allow-query".
 
 
Neustart des DNS-Servers mit der neuen Konfiguration:
 
<code>
 
/etc/init.d/bind9 restart
 
</code>
 
 
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen.
 
  
Ein DNS Resolve für freifunk-franken.de ...
+
=== Layer 3 Tunnelprotokolle ===
<code>
+
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.
dig @127.0.0.1 freifunk-franken.de
 
</code>
 
 
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:
 
<pre>
 
;; global options: +cmd
 
  
;; Got answer:
+
==== 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.
  
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819
+
Dafür ist es ein sehr einfaches Protokoll, leicht zu debuggen, sehr leightgewichtig und dadurch extrem schnell.
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
 
; EDNS: version: 0, flags:; udp: 4096
 
  
;; QUESTION SECTION:
+
Es wird daher meist zwischen Servern in Rechenzentren eingesetzt. Der Traffic ist nicht verschlüsselt.
;freifunk-franken.de. IN A
 
;; ANSWER SECTION:
 
freifunk-franken.de. 3599 IN A 31.172.113.113
 
.
 
.
 
.
 
;; Query time: 117 msec
 
;; SERVER: 127.0.0.1#53(127.0.0.1)
 
;; WHEN: Tue Sep 08 14:16:32 EEST 2015
 
;; MSG SIZE  rcvd: 275
 
</pre>
 
<br>
 
  
== B.A.T.M.A.N Gateway Selection ==
+
[[Freifunk-Gateway_aufsetzen/gre]]
  
'''ACHTUNG: Dieses Script sollte erst aktiviert werden wenn sicher feststeht das:'''
+
==== wireguard ====
* Babel alle Routen übertragen hat, "ip r s table fff" gibt viele routen zu 10.x.x.x und 172.x.x.x aus
+
Wireguard benötigt nur an einem Ende eine feste IP Adresse. Außerdem kann es leicht hinter NAT betrieben werden, da UDP verwendet wird.
* Der Server als Gateway in den KeyXchange eingetragen ist (muss man wissen, falls unbekannt bitte an die dev Liste fragen oder einen KeyXChange Admin)
 
* Ein funktionierender DHCP Server läuft
 
  
'''Man sich also prinzipiell sicher ist, das der Server komplett fertig ist. Dies sollte der allerletzte Schritt sein wenn der Server eigentlich schon Online ist.
+
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.
  
Wird das Script vorher aktiviert, announced man sich im Batman als Gateway obwohl man keine IPs vergibt (oder nicht richtig routet). Dies führt dazu das Clients keine IPs oder kein Routing ins Freifunknetz bekommen was sehr unschön ist.
+
[[Freifunk-Gateway_aufsetzen/wireguard]]
  
Ab Version 0.5.1 der Router Firmware ist die [http://www.open-mesh.org/projects/batman-adv/wiki/Gateways B.A.T.M.A.N Gateway Selection] aktiviert worden. Der Router wählt sein bevorzugtes Gateway anhand der Verbindungsqualität und dessen noch verfügbaren Bandbreite aus und selektiert das GW für die Clients vor.
+
=== Babel Routingprotokoll ===
  
Die noch verfügbare Bandbreite muss vom Gateway an die Router annonciert werden. Hierfür muss man vorab die maximal zur Verfügung stehende Up- und Downloadkapazität des Gateways festlegen. Dies kann z.B. unter folgenden Gesichtspunkten geschehen:
+
Zwischen den Routern werden Routen über ein Routingprotokoll ausgetauscht.
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)
 
* Freier Traffic des Hosters (z.B.: 5 TByte/Monat, entspricht einer Grundlast von 15 Mbit/sec, z.B. gesplittet in 5 Mbit/sec down, 10 Mbit/sec up)
 
* Erfahrungswerten / eigenes Ermessen
 
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist
 
  
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:
+
Bei Freifunk Franken verwenden wir dafür aktuell '''Babel'''.
<code>
 
apt-get install bc
 
</code>
 
  
Wir sollten nur die Bandbreite annoncieren, die tatsächlich noch frei ist: Also unsere Gesamtkapazität abzüglich der verwendeten Bandbreite. Hierfür kann man ein Skript verwenden, dass die aktuell verwendete (zeitlich gemittelte) Bandbreite vom Gateway ausliest, mit der Gesamtkapazität vergleicht und die noch freie Bandbreite an die GW Selection weitergibt.
+
Babel tauscht die erreichbaren IP-Bereiche zwischen den Routern aus, sodass jeder Router weiß über welchen Weg er andere IP-Bereiche erreichen kann.
  
Importieren des Skripts aus einer Vorlage:
+
[[Freifunk-Gateway_aufsetzen/Babel]]
<code>
 
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/
 
</code>
 
  
Alternativ kann das Skript auch als leere Datei erstellt werden:
+
=== Routing ins Internet ===
<code>
+
Es gibt verschiedene Möglichkeiten Traffic ins Internet zu routen.
touch /usr/local/bin/dyn_announce_gw_bw.sh
+
* Einen anderen Router ins Internet routen lassen und dessen angebotene Route nutzen.
</code>
+
* Direkt am eigenen Server ins Internet routen
 +
* Über einen VPN Anbieter ins Internet routen
  
Wir machen das Skript ausführbar und öffnen die Datei:
+
[[Freifunk-Gateway_aufsetzen/Routing-ins-Internet]]
<code>
 
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh
 
  
vi /usr/local/bin/dyn_announce_gw_bw.sh
+
== Layer 2 ==
</code>
+
=== 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.
  
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:
+
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.
<pre>
 
#!/bin/bash
 
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings
 
  
if [ -z "$1" ]; then
+
[[Freifunk-Gateway_aufsetzen/Batman-adv]]
        echo
 
        echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"
 
        echo
 
        echo "e.g. $0 eth0 60 10 10"
 
        echo
 
        exit
 
fi
 
  
while true
+
=== VPN für die Knoten ===
do
 
    if [ ! -e ${gwsel_lockfile} ]; then    # lockfile not present
 
        # Bandwidth currently used (time averaged)
 
        R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")
 
        T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")
 
        sleep "$2"
 
        R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")
 
        T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")
 
        TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)
 
        RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)
 
#        echo "BW used      -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"
 
  
        # Remaining bandwidth available; cut-off negative values
+
Um das batman-adv der Knoten mit dem des Gateways zu verbinden, sind Layer 2 Tunnel nötig.
        Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)
 
        Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)
 
#        echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"
 
    else                                    # lockfile present
 
        Tavail_kbitPS=0
 
        Ravail_kbitPS=0
 
        sleep "$2"
 
    fi
 
  
    if [ `pidof dhcpd` != "" ]; then
+
Dafür gibt es aktuell zwei verschiedene Möglichkeiten. Es wird in der aktuellen Firmware immer nur eine der beiden Varianten verwendet.
        for bat in /sys/class/net/bat*; do
+
Derzeit empfehlen wir aber trotz der deutlich langsameren Verbindungen fastd, da l2tp auf dem Server häufig instabil läuft.
            iface=${bat##*/}
 
            batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit"
 
        done
 
    else
 
        for bat in /sys/class/net/bat*; do
 
            iface=${bat##*/}
 
            batctl -m $iface gw_mode off
 
        done
 
        rm /var/run/dhcpd.pid >/dev/null 2>&1
 
        /etc/init.d/isc-dhcp-server restart
 
    fi
 
done
 
</pre>
 
  
''Achtung'':
+
==== fastd ====
Wenn man ein bat Interface hat, das nicht Gateway ist muss man dies aus der letzten Schleife ausschließen da sonst dort ebenfalls die Gatewayselection aktiviert wird und man eine Bandbreite announced.
+
+ wird von fast allen Gateways eingesetzt</br>
 +
+ relativ einfach zu Konfigurieren</br>
 +
- Läuft im Userspace, daher recht performancehungrig</br>
  
Das Skript übernimmt als Parameter:
+
[[Freifunk-Gateway_aufsetzen/VPN/fastd]]
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)
 
* Updateintervall in Sekunden, in denen ein neuer Wert durch die B.A.T.M.A.N GW Selection annonciert wird (Um nicht allzu volatil auf Kurzzeitschwankungen im Durchsatz zu reagieren empfiehlt sich ein Mittelungsintervall zwischen 30 und 120 Sekunden)
 
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)
 
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)
 
  
Bei Existenz des oben definierten Lockfiles "/tmp/gwsel_lockfile", annonciert das Gateway nur noch eine minimale Bandbreite. Dies dient dazu, möglichst keine neuen Clients zu akquirieren, z.B. weil gerade der VPN Tunnel ausgefallen ist und nur noch eine Babel Defaultroute mit geringer Bandbreite verfügbar ist.
+
==== 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>
  
Ein Aufruf für eth0 als Interface, ein Update alle 5 Minuten, 12 Mbit/sec maximaler Upload und 10 Mbit/sec maximaler Download wäre z.B.:
+
'''Achtung: Ab dem nächsten Firmware-Release (Stand: 07/2019) wird L2TP nicht mehr von der Router-Firmware unterstützt!'''
<code>
 
/usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10
 
</code>
 
  
Bei Debian 9 muss das Interface angepasst werden.
+
[[Freifunk-Gateway_aufsetzen/VPN/l2tp]]
Als Beispiel:
 
<code>
 
/usr/local/bin/dyn_announce_gw_bw.sh ens18 300 12 10
 
</code>
 
  
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:
+
=== B.A.T.M.A.N Gateway Selection ===
<code>
 
vi /etc/rc.local
 
</code>
 
  
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:
+
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>
 
.
 
.
 
.
 
#enable batman GW selection with 15 seconds delay
 
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) &
 
.
 
.
 
.
 
</pre>
 
  
 +
Diese filtert DHCP Offers von den Gateways und lässt nur die Offers eines bestimmten Gateways bis zum Client durch.
  
auf den Routern kann der vorselektierte Gateway mit
+
[[Freifunk-Gateway_aufsetzen/Batman-Gatewayselection]]
  
<code>
+
== Dienste ==
batctl gwl
+
=== SLAAC ===
</code>
+
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.
angeguckt werden.
 
  
=== Gatewayselection abschalten wenn Lease voll ===
+
[[Freifunk-Gateway_aufsetzen/radvd]]
  
Wenn man mit den dhcp Leases am Limit ist, sollte das Script angepasst werden das es die Gatewayselection abschaltet wenn nur noch wenige Leases offen sind. Dazu muss vor den letzten "done" folgender Teil hinzugefügt werden, Beispiel für Hood Erlangen auf nue2-gw1. Das grep muss auf die entsprechende IP Range angepasst werden und der IF Vergleich auf die maximale Menge an Leases, man sollte dabei noch einen Puffer offen halten.
+
=== 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.
  
<pre>
+
[[Freifunk-Gateway_aufsetzen/DHCP]]
# Erlangen schalten wir die Gatewayselection zur Sicherheit bei 450 leases ab, damit noch etwas Puffer nach oben ist!
 
leasecount=$(/usr/sbin/dhcp-lease-list --parsable --lease /var/lib/dhcp/dhcpd.leases 2>&1 | grep "10.50.6" | wc -l)
 
if [ $leasecount -gt 450 ]  
 
then
 
batctl -m bat1 gw_mode off
 
fi
 
</pre>
 
  
== DHCP Server ==
+
=== 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. :-)
  
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/DHCP
+
Außerdem können mit einem eigenen (rekursiven) DNS-Server auch die IC-VPN DNS Server erreichbar gemacht werden.
  
== GRE-Tunnel zu anderen Gateways ==
+
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.
Um die einzelnen Hoods miteinander zu verbinden, werden die jeweiligen Gateways über GRE-Tunnel miteinander verbunden. Es reicht dabei nicht, den GRE Tunnel nur auf einem Gateway einzurichten, vielmehr müssen beide zu verbindende Gateways konfiguriert werden. Hierfür muss man mit dem Admin des jeweiligen Tunnelpartners in Kontakt treten => [[Server]].
 
  
Der GRE-Tunnel wird in /etc/network/interfaces...
+
[[Freifunk-Gateway_aufsetzen/DNS]]
<code>
 
vi /etc/network/interfaces
 
</code>
 
  
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:
+
=== 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.
auto <tunnel>
 
iface <tunnel> inet static
 
address <Eigene IPv4 (Freifunk Netz)>
 
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255
 
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255
 
  
up ifconfig $IFACE multicast
+
Dies ist nur nötig, wenn der zentrale keyxchange verwendet wird.
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)>
 
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu
 
post-up ip rule add iif $IFACE table fff
 
post-up ip -6 rule add iif $IFACE table fff
 
post-up ip rule add from 10.50.0.0/16 table fff
 
post-up ip rule add to 10.50.0.0/16 table fff
 
post-down ip rule del iif $IFACE table fff
 
post-down ip -6 rule del iif $IFACE table fff
 
post-down ip rule del from 10.50.0.0/16 table fff
 
post-down ip rule del to 10.50.0.0/16 table fff
 
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu
 
post-down ip tunnel del $IFACE
 
</pre>
 
  
Der Tunnelname, die Internetadresse beider Tunnelpartner und die Freifunkadresse beider Tunnelpartner  müssen hierbei eingefügt werden. Für GRE-Tunnel wurde der Adressbereich 10.50.252.0/22 in [[Portal:Netz]] reserviert, in denen beiden Tunnelpartnern eine dezidierte IPv4 zugewiesen wird. Das Vorgehen wurde gewählt, um auch Hood-übergreifend Tunnel erstellen zu können. Hier verwendete IP-Adressen '''müssen''' in die Tabelle eingetragen werden und so als belegt gekennzeichnet werden.
+
[[Freifunk-Gateway_aufsetzen/http]]
  
'''Beispiel:'''
+
=== Alfred Master (Monitoring) ===
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:
+
Die Nodewatcher-Daten aller Knoten werden in einem Alfred Server gesammelt und am Gateway dann gemeinsam ans Monitoring übertragen.
<pre>
 
<tunnel>                                  ro1
 
<Eigene IPv4 (Freifunk Netz)>            fff-nue1      10.50.252.1
 
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1          10.50.252.0
 
<Eigene IPv4 (Internet)>                  fff-nue1      31.172.33.99
 
<IPv4 des Tunnelpartners (Internet)>      ro1          176.126.221.7
 
</pre>
 
  
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:
+
[[Freifunk-Gateway_aufsetzen/Alfred]]
<pre>
 
<tunnel>                                  fff-nue1
 
<Eigene IPv4 (Freifunk Netz)>            ro1          10.50.252.0
 
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1      10.50.252.1
 
<Eigene IPv4 (Internet)>                  ro1          176.126.221.7
 
<IPv4 des Tunnelpartners (Internet)>      fff-nue1      31.172.33.99       
 
</pre>
 
  
Der Tunnel kann über den Aufruf von
+
Für dezentrale Gateways kann der Zwischenschritt über Alfred ausgelassen und die Daten direkt ans Monitoring gesendet werden.
<code>
+
Dafür muss noch eine Anleitung geschrieben werden.
ifup <tunnel>
 
</code>
 
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)
 
  
Nach Aufruf von ifconfig..
+
=== ntp Server ===
<code>
+
Ein Dienst, der den Routern die aktuelle Uhrzeit bereitstellt.
ifconfig
+
Ist nicht für jedes Gateway zwingend nötig, es kann auch der NTP eines anderen Gateways verwendet werden.
</code>
 
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:
 
<pre>
 
.
 
.
 
.
 
ro1      Link encap:UNSPEC  HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 
 
          inet addr:10.50.252.1  P-t-P:10.50.252.0  Mask:255.255.255.255
 
          inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link
 
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
 
          RX packets:160913 errors:0 dropped:0 overruns:0 frame:0
 
          TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0
 
          collisions:0 txqueuelen:0
 
          RX bytes:66984353 (63.8 MiB)  TX bytes:10675001 (10.1 MiB)
 
.
 
.
 
.
 
</pre>
 
<br>
 
  
== Babel ==
+
[[Freifunk-Gateway_aufsetzen/ntp]]
Die Einrichtung von Babel wird unter https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Babel erklärt.
 
  
== Gatewayinfos an das Monitoring senden ==
+
=== gwinfo (optional, Gateway-Daten für Monitoring) ===
Damit das Monitoring weiß, wie es dem Gateway geht bitte
+
gwinfo ist ein Zusätzliches Script, das Informationen vom Gateway sammelt und ebenfalls ans Monitoring sendet.
https://github.com/adrianschmutzler/fff-monitoring/blob/master/gwinfo/sendgwinfo.sh nach /usr/local/bin/sendgwinfo.sh herunterladen und chmod +x setzen.
+
Das ganze ist optional.
  
Danach noch einen neuen crontab Eintrag mit
+
[[Freifunk-Gateway_aufsetzen/gwinfo]]
<pre>
 
*/5 *  * * *  root    /usr/local/bin/sendgwinfo.sh
 
</pre>
 
setzen
 
  
 
= 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 => [[Server]].
+
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.)
+
= Optimierungen =
<br>
+
* ARP Cache
 +
* nf_conntrack
 +
[[Freifunk-Gateway_aufsetzen/Optimierungen]]
  
= Einzelne IPs oder Services über anderen Server routen =
+
= Statistik =
  
Manchmal möchte man einzelne Clients oder bestimmte Services (Achtung Netzneutralität!) über einen anderen Server ins Internet routen. Dies ist folgendermaßen möglich. In meinen Beispiel route ich auf [https://wiki.freifunk-franken.de/w/Server#Gateway_Server_.22fff-gw-cd1.22 fff-gw-cd1] den kompletten Internettraffic von nbgland über fff-pi-cd1 ins Internet um den Mullvad auf [https://wiki.freifunk-franken.de/w/Server#Gateway_Server_.22fff-gw-cd1.22 fff-gw-cd1] zu entlasten (nbgland hat ein hohes Trafficaufkommen).
+
== MRTG ==
 +
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Statistik/mrtg
  
== Routingtabelle anlegen ==
+
= Fehlersuche =
Zuerst brauchen wir eine weitere Routingtabelle:
+
Zum finden von Fehlern, die erst Auftreten, wenn die Konfiguration schon einmal funktioniert hat, kann folgende Seite hilfreich sein:
<pre>
 
vi /etc/iproute2/rt_tables
 
</pre>
 
und fügen dort hinzu:
 
<pre>
 
12 nbgland
 
</pre>
 
Diese Routingtabelle füllen wir mit einem neuen default
 
<pre>
 
ip route add default via 10.50.252.251 dev fff-pi-cd1 table nbgland
 
</pre>
 
  
== Routing erstellen ==
+
[[Freifunk-Gateway_aufsetzen/Fehlersuche]]
  
Anschließend können wir alle Pakete mit Iptables markieren und für diese markierten Pakete in die neue Routingtabelle gucken, in unserem Beispiel:
+
= Einzelne IPs oder Services über anderen Server routen =
<pre>
 
iptables -A PREROUTING -t mangle -s 10.50.88.0/21 ! -d 10.0.0.0/8 -j MARK --set-mark 3
 
ip rule add fwmark 3 table nbgland
 
</pre>
 
Das heißt:
 
Markiere alle Pakete mit dem "Marker 3" die von dem IP Bereich 10.50.88.0/21 hereinkommen und nicht als Ziel 10.0.0.0/8 haben (damit wird Freifunkinterner Traffic von der Regel ausgenommen). Mit dem ip rule Regel sagen wir das für alle Pakete mit dem Marker 3 in die neue Routingtabelle nbgland geguckt werden soll wo der neue default fff-pi-cd1 drinnen steht.
 
Da mit Iptables sehr viele möglichkeiten bestehen ist man über diesen Weg extrem flexibel, man könnte z.b. alle Torrentpakete markieren (Achtung Netzteutralität!) und über einen "Müllserver" ausleiten.
 
  
== Problem wenn Server offline ==
+
wird fast nie benötigt, war für mich aber immer ein schönes Nachschlagewerk deshalb lass ich das ganz unten stehen:
  
Ein Problem bleibt noch, was passiert wenn fff-pi-cd1 offline ist? Genau da dies ganze am Olsr "vorbei" läuft stehen alle markierten Pakete dann ohne Exit (in unseren Fall ganz nbgland ohne Internet) da. Dazu hab ich das [https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen#OpenVPN_Start.2FStop_Automatik OpenVPN Start/Stop Automatik] von [[Benutzer:Green|Green]] ein wenig vereinfacht und angepasst für unsere bedürfnisse:
+
[[Freifunk-Gateway_aufsetzen/spezielles_routing]]
  
<pre>
+
[[Kategorie:Technik]]
#!/bin/bash
+
[[Kategorie:Hoods-V2]]
ping1 () {
+
[[Kategorie:Gateways]]
    ping -c 3 -i 5 8.8.8.8 -I fff-pi-cd1
 
    ping1_ExitCode=$?
 
    echo "$(date): Exit Status: ${ping1_ExitCode}"
 
}
 
 
 
 
 
while true
 
do
 
    ping1
 
    # check if ping successful
 
    if ([[ ${ping1_ExitCode} -eq 0 ]]); then
 
        sleep 10;
 
                echo "Ping success";
 
    else
 
                echo "Ping fault";
 
                iptables -D PREROUTING -t mangle -s 10.50.88.0/21 ! -d 10.0.0.0/8 -j MARK --set-mark 3
 
    fi
 
done
 
</pre>
 
 
 
Das Script wird gestartet und läuft in einer Endlosschleife. Es wird regelmäßig versucht über fff-pi-cd1 8.8.8.8 zu pingen und falls dies nicht mehr gelingt wird die iptables Regel mit -D entfernt, somit werden die Pakete nicht mehr markiert und Olsr hat wieder die Kontrolle über den Traffic. Ein automatisches reaktivieren findet aktuell nicht statt, dies müsste ich nach beheben des Problems manuell anstoßen.
 
Diese Konstellation läuft jetzt schon seit 6. Januar problemlos, es gab keine beschwerden und das Script musste noch nicht einmal eingreifen.
 
 
 
Achtung: Falls am fff-pi-cd1 der OpenVPN abstürzt baut dort Olsr auf einen anderen Server um. Da dadurch der Ping nach wie vor gelingt, wird die iptables Rule auch nicht entfernt. Man sollte also dafür sorgen das fff-pi-cd1 einen guten 2. Exit hat, falls OpenVPN abstürzt. Dies ist heute passiert und da es keinen guten Exit gab, war nbgland einige Zeit ziemlich lahm.
 
 
 
= Problem nf_conntrack =
 
Bei vielen Clients und vorallem NAT und anderen Iptables kann es passieren das die nf_conntrack auf den Server voll läuft. Wenn dies passiert fängt der Server an Pakete zu verwerfen und ist dann nur noch schwer erreichbar.
 
Zu erkennen ist das auch wenn dmesg unmengen von
 
<pre>
 
nf_conntrack: table full, dropping packet
 
</pre>
 
um sich wirft.
 
 
 
Folgendes sollte man im Auge behalten:
 
 
 
== Ermitteln des conntrack_max ==
 
<pre>
 
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
 
</pre>
 
 
 
Debian9:
 
 
 
<pre>
 
cat /proc/sys/net/nf_conntrack_max
 
</pre>
 
 
 
== Ermitteln des aktuellen conntrack count ==
 
<pre>
 
/sbin/sysctl net.netfilter.nf_conntrack_count
 
</pre>
 
 
 
sollte die aktuell Größe nahe an die maximale Größe kommen, kann diese vergrößert werden:
 
<pre>
 
sysctl -w net.netfilter.nf_conntrack_max=131072
 
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
 
</pre>
 
zu beachten ist, das eine größere conntrack auch mehr Arbeitsspeicher fordert. Unter 4GB sollte sie nicht vergrößert werden. Der hashsize sollte 1/4 des conntrack_max Wertes betragen
 
Der Wert kann auch permamenent angepasst werden:
 
<pre>
 
vi /etc/sysctl.conf  // Am Ende einfügen
 
net.netfilter.nf_conntrack_count = 131072
 
vi /etc/rc.local
 
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
 
</pre>
 
zusätzlich kann das unnötig lange Timeout verringert werden um den conntrack count schon von Grund auf kleiner zu halten:
 
 
 
<pre>
 
vi /etc/sysctl.conf // Am Ende einfügen
 
net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000
 
</pre>
 
bzw. die Werte sofort setzen:
 
<pre>
 
sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=120
 
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
 
</pre>
 
Quelle: [http://doku.fietz.net/index.php?title=Nf_conntrack]
 
 
 
= ARP Cache erhöhen =
 
ACHTUNG: Das ganze ist noch nicht intensiv getestet, bitte bei Änderungen beobachten!
 
Default ist im Linux der Arp Cache relativ klein. Wenn man mehrmals hintereinander die Menge an ARP Einträgen im Cache abfragt (z.b. ip neigh show | wc -l) und man feststellt das der Cache regelmäßig aufgeräumt wird (Zahl springt alle paar Sekunden wieder auf einen deutlich kleineren Wert zurück) sollte man den Wert erhöhen um die Arp Requests im Netz zu verringern. Dies geht über sysctl Variablen:
 
 
 
<pre>
 
sysctl -w net.ipv6.neigh.default.gc_thresh1=128
 
sysctl -w net.ipv6.neigh.default.gc_thresh2=512
 
sysctl -w net.ipv6.neigh.default.gc_thresh3=1024
 
sysctl -w net.ipv4.neigh.default.gc_thresh1=128
 
sysctl -w net.ipv4.neigh.default.gc_thresh2=512
 
sysctl -w net.ipv4.neigh.default.gc_thresh3=1024
 
</pre>
 
 
 
die oben angegeben Werte sind die default Werte. Weitere Infos zu den Werten:
 
https://wiki.manitu.de/index.php/Server:Fehlermeldung_%22kernel:_Neighbour_table_overflow%22
 
 
 
Ich hab z.b. auf nue2gw3 mit ~2400 Clients die Werte auf 2048 4096 8192 gesetzt.
 
 
 
= Port Sperren =
 
Es empfiehlt sich folgende Ports / IPs zu sperren
 
 
 
Ausgehend:
 
* tcp-25
 
* 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/10
 
* 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]]
 

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